Thomas de Groot wrote:
> "Bill Pragnell" <bil### [at] hotmailcom> schreef in bericht
> news:web.4362127eca18a3ea731f01d10@news.povray.org...
>>Firstly, Thomas, do you see the same thing with your Ring?
>>Secondly, can anyone clarify what exactly is happening here? Is it a
>>precision problem, or something else?
>>
> 
> 
> Yes, Bill. The same happens with my Ring. If I lower my camera towards the
> surface I get exactly the same artifacts.
> 
> Thomas

I've run into problems like this before.  POVRay is designed for 
rendering scenes of "normal" sizes where "normal" is in the range of 
arount 100,000 units from the origin.

When using floating point numbers, you can't test for exactly 0 because 
floats are always slightly inaccurate.  Instead, you have to test for 
numbers smaller than some epsilon value.

There's a value called EPSILON (see frame.h) which defines a small value 
and anything smaller would be considered 0 in some of the calculations. 
  This value is set to 1e-10 which is dangerously close in magnitude to 
1 / 90,000,000 (the scale of Ringworld).

To solve this problem, you may have to try decreasing the epsilon value 
and recompiling POVRay.  You may still run into problems, though, 
because doubles may not have enough precision to handle the 
calculations.  You may come up with calculations like

	90,000,000.00000012 - 90,000,000.0000001

The correct answer should be 0.00000002, but the numbers just can't 
represent 90,000,000.00000012 accurately.  That's the nature of limited 
precision floating point calculations. It's bad news for people trying 
to render Ringworld, though.

Hope this helps
David Buck

Post a reply to this message

"David Buck" <dav### [at] simberoncom> schreef in bericht
news:43635ed8$1@news.povray.org...

>
> I've run into problems like this before.  POVRay is designed for
> rendering scenes of "normal" sizes where "normal" is in the range of
> arount 100,000 units from the origin.
>

Would more scaling down help? My model has currently a radius of 95,000 pov
units, but also translated 95,000 units to keep the camera near the origin.
It is possible to scale everything down more of course, without changing the
aspect of the scene...

Thomas

Post a reply to this message

Thomas de Groot wrote:
> "David Buck" <dav### [at] simberoncom> schreef in bericht
> news:43635ed8$1@news.povray.org...
> 
> 
>>I've run into problems like this before.  POVRay is designed for
>>rendering scenes of "normal" sizes where "normal" is in the range of
>>arount 100,000 units from the origin.
>>
> 
> 
> Would more scaling down help? My model has currently a radius of 95,000 pov
> units, but also translated 95,000 units to keep the camera near the origin.
> It is possible to scale everything down more of course, without changing the
> aspect of the scene...
> 
> Thomas
> 

That's one possibility but it might not work.  The problem may be the 
relative scales of the scene.  If you scale it down to 95,000 pov units 
you'll want scale the camera position as well which may cause the same 
problems in calculations.  I suspect the problem is having a camera so 
close to a relatively huge object no matter what the scale is.  You may 
have the same problem with an ordinary scene and moving the camera to 
0.00000001 pov units from an object.

Keep in mind, this is educated speculation since I haven't actually 
tested this particular scenario, but I suspect it's causing a problem. 
Try scaling down the world and see what happens, but I suspect you'll 
have the same problem.  Changing EPSILON may be the only realistic answer.

David Buck

Post a reply to this message

David Buck wrote:

>> Would more scaling down help? My model has currently a radius of 
>> 95,000 pov
>> units, but also translated 95,000 units to keep the camera near the 
>> origin.
>> It is possible to scale everything down more of course, without 
>> changing the
>> aspect of the scene...
>>
>> Thomas
>>
> 
> That's one possibility but it might not work.  The problem may be the 
> relative scales of the scene.  If you scale it down to 95,000 pov units 
> you'll want scale the camera position as well which may cause the same 
> problems in calculations.  I suspect the problem is having a camera so 
> close to a relatively huge object no matter what the scale is.  You may 
> have the same problem with an ordinary scene and moving the camera to 
> 0.00000001 pov units from an object.
> 
> Keep in mind, this is educated speculation since I haven't actually 
> tested this particular scenario, but I suspect it's causing a problem. 
> Try scaling down the world and see what happens, but I suspect you'll 
> have the same problem.  Changing EPSILON may be the only realistic answer.
> 
> David Buck

I just tried it - scaling the scene has no effect on the problem.

David

Post a reply to this message

Wasn't it Thomas de Groot who wrote:
>
>Would more scaling down help? My model has currently a radius of 95,000 pov
>units, but also translated 95,000 units to keep the camera near the origin.
>It is possible to scale everything down more of course, without changing the
>aspect of the scene...

That was the first thing I tried when Bill posted the example scene.
It's easy to do, just reduce all those numbers by a factor of 1000 or
100000. But the result stays exactly the same in this case.

It look's like it's not the absolute size of the values that causes the
effect in this particular case, but the loss of precision.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Mike Williams nous apporta ses lumieres en ce 2005-10-29 09:56:
> Wasn't it Thomas de Groot who wrote:
> 
>>Would more scaling down help? My model has currently a radius of 95,000 pov
>>units, but also translated 95,000 units to keep the camera near the origin.
>>It is possible to scale everything down more of course, without changing the
>>aspect of the scene...
> 
> 
> That was the first thing I tried when Bill posted the example scene.
> It's easy to do, just reduce all those numbers by a factor of 1000 or
> 100000. But the result stays exactly the same in this case.
> 
> It look's like it's not the absolute size of the values that causes the
> effect in this particular case, but the loss of precision.
> 
You need 128 bit FPU! Now, they are 64 bits. In this case, double precision is just
not enough, you 
need quadruple precision (or more!). It can be emulated, but it will take a LOT more
time to do the 
maths, leading to proebitive render time.

-- 
Alain
-------------------------------------------------
E=MC^2.. I'm not fat! I'm energetic!

Post a reply to this message

Wasn't it Alain who wrote:
>Mike Williams nous apporta ses lumieres en ce 2005-10-29 09:56:
>> Wasn't it Thomas de Groot who wrote:
>> 
>>>Would more scaling down help? My model has currently a radius of 95,000 pov
>>>units, but also translated 95,000 units to keep the camera near the origin.
>>>It is possible to scale everything down more of course, without changing the
>>>aspect of the scene...
>> 
>> 
>> That was the first thing I tried when Bill posted the example scene.
>> It's easy to do, just reduce all those numbers by a factor of 1000 or
>> 100000. But the result stays exactly the same in this case.
>> 
>> It look's like it's not the absolute size of the values that causes the
>> effect in this particular case, but the loss of precision.
>> 
>You need 128 bit FPU! Now, they are 64 bits. In this case, double precision is 
>just not enough, you 
>need quadruple precision (or more!). It can be emulated, but it will take a LOT 
>more time to do the 
>maths, leading to proebitive render time.
>

However, the code that calculates the intersection of a ray with a box
is first order, rather than second order, so it can be performed
accurately with less precision.

It's possible to patch the hole in the cylinder with a box that's a
million miles square. I reckon that the difference between where the box
is and where the cylinder should be, is less than the precision errors
incurred in tracing the cylinder.

#include "colors.inc"
camera { location <0, 0.0001, 0>
         up <0, 1, 0>
         right <4/3, 0, 0>
         //direction <0, 0, FoV_75>
         look_at <-1000, 0, 0> }

#declare Ring = union {
  light_source { <0, 0, 0> color White }
  union {
     cylinder { <0, 0, -500000>, <0, 0, 500000>, 90000000 open hollow }
     box{<-500000,-90000001,-500000><500000,-90000000,500000>}
             pigment { color SkyBlue }
             finish { ambient 0.5 } } }

object { Ring translate <0, 90000000, 0> }

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Alain wrote:
> You need 128 bit FPU! Now, they are 64 bits. In this case, double 
> precision is just not enough, you need quadruple precision (or more!). 
> It can be emulated, but it will take a LOT more time to do the maths, 
> leading to proebitive render time.

You know, back in the day, you needed a Cray supercomputer just to even 
think about being able to do what you can do in under a minute on a 
modern desktop.  I'd like to see an actual time-cost of doing things 
'the hard way' with software handling the precision out to whatever's 
sufficient to remove precision-related artifacts, all I've seen is 
people insisting that it's too long to be of any use.

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Tim Cook nous apporta ses lumieres en ce 2005-10-29 17:37:
> Alain wrote:
> 
>> You need 128 bit FPU! Now, they are 64 bits. In this case, double 
>> precision is just not enough, you need quadruple precision (or more!). 
>> It can be emulated, but it will take a LOT more time to do the maths, 
>> leading to proebitive render time.
> 
> 
> You know, back in the day, you needed a Cray supercomputer just to even 
> think about being able to do what you can do in under a minute on a 
> modern desktop.  I'd like to see an actual time-cost of doing things 
> 'the hard way' with software handling the precision out to whatever's 
> sufficient to remove precision-related artifacts, all I've seen is 
> people insisting that it's too long to be of any use.
> 
About 18 years ago, my brother used autocad on a 286 with and without a mathematical
coprocessor. 
Acording to him, it was MORE than twice as fast with the coprocessor than without. The
machine 
without the coprocessor had a faster CPU and more RAM!

-- 
Alain
-------------------------------------------------
Rastafarianism: Let's smoke this shit!

Post a reply to this message

Alain wrote:
>
> You need 128 bit FPU!

Or 256-bit fixed point.  The Java3D docs have the interesting
observation that practically all interesting physical dimensions
can be expressed in 256-bit fixed point with the fixed "decimal"
point right at bit 128.

Table 4-1 Java 3D High-Resolution Coordinates
2n Meters 	Units
87.29	Universe (20 billion light years)
69.68	Galaxy (100,000 light years)
53.07	Light year
43.43	Solar system diameter
23.60	Earth diameter
10.65	Mile
9.97	Kilometer
0.00	Meter
-19.93	Micron
-33.22	Angstrom
-115.57	Planck length

> It can be emulated, but it will take a LOT more time to do the maths, 
> leading to proebitive render time.

What Java3D does is makes only the bottom-most node in the scene graph
use this (slow but accurate) 256-bit fixed-point representation, and
all sub-branches in the scene graph use something small-and-fast
(floats? doubles?).

When doing math between objects within the same sub-graph of the
whole scene, it never needs to touch the slow-256-bit-fixed-point
matrices; so speed is unaffected. When doing math across
scene subgraphs rooted on two different 256-bit root nodes
I think they had clever ways of still doing most of the math
in floating point and minimizing the big integer match while
retaining precision.

I don't know if these tricks would make any sense in a ray tracer, though.

Post a reply to this message