Am 14.12.2013 19:40, schrieb Roman:
> On 2013-12-13 14:35, Roman wrote:
>
>> Thank you for clarifying this. To work around the problem, I'm currently
>> scaling my whole scene to a size that works for all objects. That's a
>> bit cumbersome though, and I'm worried that such a common error-free
>> scale won't exist in all cases. IMHO this is a serious limitation of
>> POV-Ray that should be fixed, if at all possible.
>
>
> I'm still struggling with this issue. So I've rescaled everything to a
> size that works for sphere_sweep, but now some of my other objects look
> wrong. More precisely, their materials look wrong. I have narrowed it
> down to the minimal scene file below, which shows a sphere with a
> non-zero filter value in the pigment. Different scales result in
> different images. What gives? I'm confused.

The answer is quite simple: As various internal "fudge factors" are set 
to 1e-6, scene details should be a good deal larger than that.

Post a reply to this message

On 2013-12-15 01:56, clipka wrote:
>
> The answer is quite simple: As various internal "fudge factors" are set
> to 1e-6, scene details should be a good deal larger than that.
>

Well, I can live with the fact that s=1e-6 doesn't render anything, 
although I think that POV-Ray should be free of internal absolute fudge 
factors that break scale invariance. If these are really needed, they 
should be relative so they work at any scale, or at least modifiable by 
the user.

The problem is that even quite large scales s>>1e-6 result in different 
images. The stripped-down scene I posted earlier might somewhat conceal 
the severity of my problem. The following closer to what I actually try 
to render: Transparent thin surfaces. Notice the vast difference in 
visual appearance depending on s=1 or s=10. Interestingly, the 
difference vanishes for thicker surfaces (e.g. 1/100 instead of 1/1000).

I'm stumped. Please tell me how I can scale such thin transparent 
surfaces to get an equivalent visual.


// START SCENE FILE

#version 3.7;

#declare s = 10; // try 1 or 10

camera {
	location 0.1*s*z
	look_at 0
}

sphere {
	0, s
	texture {
		pigment { rgb 1 }
		finish { emission 1 diffuse 0 }
	}
}

#declare shell = difference {
	sphere { 0, 1.001 }
	sphere { 0, 1 }
}

union {
	object { shell translate -x/2 }
	object { shell translate x/2 }
	scale s*0.03
	material {
		texture {
			pigment { rgb 0.9 filter 1 }
			finish {
				ambient 0
				diffuse 0
				reflection { 0, 1 }
				conserve_energy
			}
		}
		interior {
			ior 1.61
			fade_power 1001
			fade_distance 6*s
		}
	}
}

// END SCENE FILE

Post a reply to this message

Attachments:
Download 'scale_problem2_1.png' (4 KB) Download 'scale_problem2_10.png' (3 KB)

Preview of image 'scale_problem2_1.png'

Preview of image 'scale_problem2_10.png'

Am 15.12.2013 17:23, schrieb Roman:
> On 2013-12-15 01:56, clipka wrote:
>>
>> The answer is quite simple: As various internal "fudge factors" are set
>> to 1e-6, scene details should be a good deal larger than that.
>
> Well, I can live with the fact that s=1e-6 doesn't render anything,
> although I think that POV-Ray should be free of internal absolute fudge
> factors that break scale invariance. If these are really needed, they
> should be relative so they work at any scale, or at least modifiable by
> the user.

I certainly agree on this; but weeding out those legacy fudge factors 
(they possibly have been around ever since the very first version of 
POV-Ray) needs careful consideration of the mathematical implications, 
which is a task that hasn't been tackled yet.

> The problem is that even quite large scales s>>1e-6 result in different
> images. The stripped-down scene I posted earlier might somewhat conceal
> the severity of my problem. The following closer to what I actually try
> to render: Transparent thin surfaces. Notice the vast difference in
> visual appearance depending on s=1 or s=10. Interestingly, the
> difference vanishes for thicker surfaces (e.g. 1/100 instead of 1/1000).
>
> I'm stumped. Please tell me how I can scale such thin transparent
> surfaces to get an equivalent visual.

Large. Very large.

Note that it is not your s itself that matters, but the size of the 
resulting structures. You're at 3e-5 there (for s=1), which is obviously 
still close enough to 1e-6 to give you problems.

Also note how your scene is unconventionally small anyway, with the 
primary scene content having a size in the order of 0.1 units (again at 
s=1).

I'm sorry to say this, but POV-Ray wasn't designed with this scenario in 
mind. Traditionally, scenes are designed with the primary content having 
a size in the order of 1 unit or above.

Post a reply to this message

On 2013-12-16 02:03, clipka wrote:
> Note that it is not your s itself that matters, but the size of the
> resulting structures. You're at 3e-5 there (for s=1), which is obviously
> still close enough to 1e-6 to give you problems.
>
> Also note how your scene is unconventionally small anyway, with the
> primary scene content having a size in the order of 0.1 units (again at
> s=1).
>
> I'm sorry to say this, but POV-Ray wasn't designed with this scenario in
> mind. Traditionally, scenes are designed with the primary content having
> a size in the order of 1 unit or above.

Thank you for your explanations. So, in order for POV-Ray to work 
properly, the distance between any two geometrical features (such as the 
inner and outer surface of a thin shell) must be well above 1e-6 POV-Ray 
units? This raises a few questions.

1. Is this documented somewhere? I cannot be the only one who is 
affected by this. Again, IMHO, this is a major deficiency in POV-Ray 
that people should know about, or they will get unexpected/wrong 
behavior. For instance, they can't use SI units for a scene involving 
micrometer-scale objects.

2. What about fractals? They certainly range to much smaller scales 
easily, even if the global size is, say, in the order of 1 unit.

3. Could you please, if you can, point me to the location in the source 
code where this constant is set/used?. I'd like to experiment with this 
a bit.

-Roman

Post a reply to this message

Am 16.12.2013 11:32, schrieb Roman:

> 3. Could you please, if you can, point me to the location in the source
> code where this constant is set/used?. I'd like to experiment with this
> a bit.

There are actually multiple such constants; search the source code for 
"1e-" (and possibly also "1.0e-"; I'm not sure if that's used anywhere).

Post a reply to this message

On 16/12/13 10:32, Roman wrote:
[...]
> 1. Is this documented somewhere? I cannot be the only one who is
> affected by this. Again, IMHO, this is a major deficiency in POV-Ray
> that people should know about, or they will get unexpected/wrong
> behavior. For instance, they can't use SI units for a scene involving
> micrometer-scale objects.

I run into the opposite problem; I render astronomical objects, and
routinely run afoul of the maximum draw limit fudge factor where objects
that are a long way away are ignored completely. (My moon pictures, for
example, have to have the sun artifically close or it doesn't show up.)

What's this limit actually for? I can see that the lower limit has some
utility in order to cope sanely with rounding errors, but I can't think
of any reason for an upper limit.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│ "There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs." ---
│ Flon's Axiom

Post a reply to this message

Am 16.12.2013 14:26, schrieb David Given:

> I run into the opposite problem; I render astronomical objects, and
> routinely run afoul of the maximum draw limit fudge factor where objects
> that are a long way away are ignored completely. (My moon pictures, for
> example, have to have the sun artifically close or it doesn't show up.)
>
> What's this limit actually for? I can see that the lower limit has some
> utility in order to cope sanely with rounding errors, but I can't think
> of any reason for an upper limit.

I guess the true reason for the existence of all these limits has been 
lost in the mists of time.

My theory is that the developers back then were not too familiar with 
the numeric limits of the IEEE floating point formats, nor with rounding 
error estimation & handling.

Post a reply to this message

Le 16/12/2013 19:03, clipka nous fit lire :
> Am 16.12.2013 14:26, schrieb David Given:
> 
>> I run into the opposite problem; I render astronomical objects, and
>> routinely run afoul of the maximum draw limit fudge factor where objects
>> that are a long way away are ignored completely. (My moon pictures, for
>> example, have to have the sun artifically close or it doesn't show up.)
>>
>> What's this limit actually for? I can see that the lower limit has some
>> utility in order to cope sanely with rounding errors, but I can't think
>> of any reason for an upper limit.
> 
> I guess the true reason for the existence of all these limits has been
> lost in the mists of time.
> 
> My theory is that the developers back then were not too familiar with
> the numeric limits of the IEEE floating point formats, nor with rounding
> error estimation & handling.
> 
And a time where floating point could be 32 bits... and portability
meant lowest common denominator. (and Ieee-754 was not that common).

Also keep in mind that some solver need squared value, or even a cube,
so 2e+31 (biggest single precision value on 32 bits) introduce a limit
of 1e+15 or 1e+10 if you do not want the square/cube to go through the roof.

The minimal delta that can be stored around 1 is of the order of 1e-7.

With 64 bits floating point value now everywhere, there is less impact
on the top limit (the max is at above 1e+308, so a cube would have issue
after 1e+100), yet the precision only got 30 more bits, that's only
2^30, or 10^9. so 1e-7 should not go further than 1e-16
(and if a square/root is in the process, the 1e-7 became 1e-3 where
1e-16 become a lame 1e-8 or 1e-7)

(I talked of square and cube, but that's also true for any product of 2
or 3 terms)

Post a reply to this message