Is there anything inherent to the way POV processes isosurfaces (and radiosity
for that matter) that would make the scale of scene objects relevant to the
results, or are any differences in scaling just a matter of floating point
rounding errors?  For SSLT, it does seem that units matter, because there is the
global mm_per_unit setting to tune SSLT.

I have seen suggestions from time to time in the newsgroups about scaling up
isosurface objects if you are having difficulty cleaning up holes, or speeding
up the rendering, but again, is that because of the way isosurfaces are
processed or just the rounding errors?

In my own scenes, I have created macros to declare unit-based sizes, and never
use unit-less declarations any more.  I tend to model scenes I find in the real
world, so I use the units based on my measuring device at the time, and/or known
sizes of real-world instances of those objects.  I grew tired of trying to
remember whether I used metric or English measurements and doing the
conversions, so I created the macros.  In addition, I set things up so I can
change the base unit used when rendering the scene.  By default I work in 1cm =
1 POV unit, but if FP errors are getting in the way, I can easily change it to
meters or millimeters as needed.

-- Chris R.

Post a reply to this message

On 1/31/22 10:50, Chris R wrote:
> Is there anything inherent to the way POV processes isosurfaces (and radiosity
> for that matter) that would make the scale of scene objects relevant to the
> results, or are any differences in scaling just a matter of floating point
> rounding errors?  For SSLT, it does seem that units matter, because there is the
> global mm_per_unit setting to tune SSLT.
> 
> I have seen suggestions from time to time in the newsgroups about scaling up
> isosurface objects if you are having difficulty cleaning up holes, or speeding
> up the rendering, but again, is that because of the way isosurfaces are
> processed or just the rounding errors?
> 
> In my own scenes, I have created macros to declare unit-based sizes, and never
> use unit-less declarations any more.  I tend to model scenes I find in the real
> world, so I use the units based on my measuring device at the time, and/or known
> sizes of real-world instances of those objects.  I grew tired of trying to
> remember whether I used metric or English measurements and doing the
> conversions, so I created the macros.  In addition, I set things up so I can
> change the base unit used when rendering the scene.  By default I work in 1cm =
> 1 POV unit, but if FP errors are getting in the way, I can easily change it to
> meters or millimeters as needed.
> 
> -- Chris R.
> 
> 

:-) Questions like these I find hard to answer. Completely reasonable, 
but the answers go on for as far as I can see!

In all official POV-Ray it's a good idea to keeps everything defined 
within a 1e-2 to 1e+5 numerical space if you can. This just where things 
work best numerically in official POV-Ray today.

The recommendation to scale up, I think has come about over time because 
new users tend to set up symmetrically around 0.0 and POV-Ray's good 
numerical space isn't centered about zero. Scaling up often helps - you 
can get into numerical trouble that way too...

The numerical reality is immensely complicated in a tool like POV-Ray. 
For example, some surfaces, shapes can support a larger numerical range. 
Triangle meshes,  spheres and boxes are effectively low order numerical 
problems and these often work over a larger numerical range. The 
distance rays are traveling between source and intersections matters to 
the resultant numerical accuracy.

There is nothing particular to isosurfaces about centering your scenes 
numerically where POV-Ray generally works best.

What is true about isosurfaces is the accuracy keyword value matters and 
the default (0.001) is often too small for the image size of scenes 
today(1). I start now at 0.0005 and tune if need be. The very best 
accuracy achievable with an isosurface tends to be about 1e-6. This a 
result of the solver technique and practical performance. Performance 
degrades as accuracy goes up. I almost always define isosurfaces 
somewhat closely around the origin for size(2) and scale as needed into 
the scene.

Bill P.

(1) - Most shapes control accuracy internally to some preset value which 
is - almost always - smaller than 1e-3.

(2) - The isosurface shape itself is reasonably centered numerically and 
that accuracy value is a local, solver space, value.

Post a reply to this message

Le 2022-02-03 à 08:41, William F Pokorny a écrit :
> On 1/31/22 10:50, Chris R wrote:
>> Is there anything inherent to the way POV processes isosurfaces (and 
>> radiosity
>> for that matter) that would make the scale of scene objects relevant 
>> to the
>> results, or are any differences in scaling just a matter of floating 
>> point
>> rounding errors?  For SSLT, it does seem that units matter, because 
>> there is the
>> global mm_per_unit setting to tune SSLT.
>>
>> I have seen suggestions from time to time in the newsgroups about 
>> scaling up
>> isosurface objects if you are having difficulty cleaning up holes, or 
>> speeding
>> up the rendering, but again, is that because of the way isosurfaces are
>> processed or just the rounding errors?
>>
>> In my own scenes, I have created macros to declare unit-based sizes, 
>> and never
>> use unit-less declarations any more.  I tend to model scenes I find in 
>> the real
>> world, so I use the units based on my measuring device at the time, 
>> and/or known
>> sizes of real-world instances of those objects.  I grew tired of 
>> trying to
>> remember whether I used metric or English measurements and doing the
>> conversions, so I created the macros.  In addition, I set things up so 
>> I can
>> change the base unit used when rendering the scene.  By default I work 
>> in 1cm =
>> 1 POV unit, but if FP errors are getting in the way, I can easily 
>> change it to
>> meters or millimeters as needed.
>>
>> -- Chris R.
>>
>>
> 
> :-) Questions like these I find hard to answer. Completely reasonable, 
> but the answers go on for as far as I can see!
> 
> In all official POV-Ray it's a good idea to keeps everything defined 
> within a 1e-2 to 1e+5 numerical space if you can. This just where things 
> work best numerically in official POV-Ray today.
> 
> The recommendation to scale up, I think has come about over time because 
> new users tend to set up symmetrically around 0.0 and POV-Ray's good 
> numerical space isn't centered about zero. Scaling up often helps - you 
> can get into numerical trouble that way too...
> 
> The numerical reality is immensely complicated in a tool like POV-Ray. 
> For example, some surfaces, shapes can support a larger numerical range. 
> Triangle meshes,  spheres and boxes are effectively low order numerical 
> problems and these often work over a larger numerical range. The 
> distance rays are traveling between source and intersections matters to 
> the resultant numerical accuracy.
> 
> There is nothing particular to isosurfaces about centering your scenes 
> numerically where POV-Ray generally works best.
> 
> What is true about isosurfaces is the accuracy keyword value matters and 
> the default (0.001) is often too small for the image size of scenes 
> today(1). I start now at 0.0005 and tune if need be. The very best 
> accuracy achievable with an isosurface tends to be about 1e-6. This a 
> result of the solver technique and practical performance. Performance 
> degrades as accuracy goes up. I almost always define isosurfaces 
> somewhat closely around the origin for size(2) and scale as needed into 
> the scene.
> 
> Bill P.
> 
> (1) - Most shapes control accuracy internally to some preset value which 
> is - almost always - smaller than 1e-3.
> 
> (2) - The isosurface shape itself is reasonably centered numerically and 
> that accuracy value is a local, solver space, value.

One case that I've encountered where scalling up was needed was a scene 
where 1 POV unit represented about 100m, and everything in it was human 
scalled. There was some heavy bleeding in all corners.

Post a reply to this message

On 2/3/22 10:51, Alain Martel wrote:
> One case that I've encountered where scalling up was needed was a scene 
> where 1 POV unit represented about 100m, and everything in it was human 
> scalled. There was some heavy bleeding in all corners.

Thanks for the info. I fully expect there are as many exceptions as 
answers. :-) In the end if scaling up (or down) helps, it helps.

Off the top of my head I can think of a couple scenarios where scaling 
up could help with isosurfaces and radiostiy - somewhat apart from the 
rough numerical region where solvers work well.

--- isosurfaces

I think of isosurfaces as having a far edge problem by nature.

The solver works in a couple stages. The first using the max_gradient to 
sample at some minimum step size within the container until it see the 
backside of the container shape or it's found a certain number of roots.

The max gradient is used to find transitions through the threshold value 
- the roots, which are usually at or very near zero. After the 
transition through a root is seen the accuracy value is used to control 
how closely the root / the surface gets approximated.

Where working with boxes or small far-side shape features with a ray 
approaching over the top, say - meaning a ray just barely catching a far 
corner. In those situations the max gradient also needs to be high(1) 
because that transition through the root value - and back - happens over 
a very small region of space.

I often let the gradient warnings go in such cases (povr has an option 
called 'report' to turn the warnings off by isosurface) and then I let 
AA smooth things as best it can. This a piece of why I've pursued 
certain AA and new jitter options in the povr branch.

Having max gradient warnings isn't necessarily a problem. You can have 
even complete discontinuities in values so long as they happen away from 
the threshold/root values. The max gradient must be large enough - for 
the steps to be small enough - to still see the root transitions. 
Further, the discontinuities cannot change, value wise, in a way that 
indicates a root exists at / near the discontinuity.

Anyhow. It might be that scaling up an isosurface while keeping 
everything else constant effectively made the gradient steps smaller 
with respect to the overall shape - and so solved some corner / fine 
detail resolution issues.

--- radiosity
If you were talking about radiosity bleeding through at room corners or 
similar.

I've recently spent some time in the radiosity code due running down a 
bug therein. While I still consider myself a radiosity amateur as a 
user, it looked to me that after the radiosity samples are deposited on 
surfaces, they are gathered within a region around the current 
intersection while calculating the color/lighting contribution at any 
given intersection. This mechanism is similar to what happens with 
photon samples.

It wasn't clear to me there was any "strong" mechanism for ignoring 
samples which might be on the other side of a surface or from a very 
near unrelated surface. Further, there is the issue that the samples 
which are actually stored to a file format have considerably reduced 
accuracy - they likely drift small amounts after a save/read. Both 
radiosity sample gathering 'exposures' are likely reduced by scaling up 
and / or cranking down on the error values(a).

(a) IIRC these are tangled with actual scene distances.

FWIW.

Bill P.

Post a reply to this message