Re-2: [Radiance-general] ecotect export - missing surfaces

[Greg Ward]

Well, I'm somewhat familiar with the code, and I can't even tell  
you.  I know there are places where formatting limits the number of  
significant figures produced in the scene files, but xform at least  
tries not to lose too much.  I also know that a frozen octree  
converts the 64-bit floating point value to a 32-bit mantissa (with  
sign bit) and an 8-bit exponent, which maintains about 9 significant  
decimal digits.  If what matters to you is in the 8th or 9th decimal  
place, you're in dangerous territory.  (By comparison, a 64-bit IEEE  
double has about 15 significant digits.)

So, I agree with Erwin's recommendation of applying xform in cases  
where you are starting to strain your significant digits,  
particularly if you are putting your scene into a frozen octree.  It  
is also a good idea to work in world units that don't make your  
coordinate values too large or too small (large being on the order of  
10^8 and small being on the order of 10^-4).

-Greg

> From: "Lars O. Grobe" <grobe at gmx.net>
> Date: February 20, 2008 4:21:50 AM PST
>
>> When your model ist that far away from 0,0,0 you have to expect
>> problems. For instance running an interactive 'rview/rvu' session it
>> will be hard to fine tune your view-point/direction settings because
>> (from memory) if you have a 6 digit number like the y coord above
>> rview will cut off everything after the 6 digits. Am I making sense?
>
> Is this really true? I would expected the bounding cube determination
> and octree structure to solve that?