Re-2: ecotect export - missing surfaces

You're welcome, I'm glad my guess was correct. Btw, I often get geometry - esp. from landscape or road planning departments - and they always use the local coordinate system. That means you would have X/Y/Z like 82045.5708,235594.1030,587.4538.

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?

Anyway, I dont have time (nor experience) to analyze the radiance code but somewhere in the source tree you would find certain #define statements that determine the limitations of all geometry coordinates.
My workaround is to 'move' the whole model (close) to 0,0,0 either in the CAD program proir to export or with the xform -t $x $y $z tool within Radiance.

HTH,
Erwin

···

-------- Original Message --------
Subject: Re: [Radiance-general] ecotect export - missing surfaces (19-Feb-2008 17:05)
From: Nick Doylend <[email protected]>
To: [email protected]

Thanks very much Erwin. That seems to have been the problem.
Ecotect's Radiance output assumes the model dimensions are in
millimetres and by default scales everything it exports by 0.001. Turns
out I was modelling in metres. Oops.

Nick

On Tue, 19 Feb 2008 13:16:10 +0000, "Erwin Zierler" > <[email protected]> said:
> Hello Nick,
>
> I downloaded your files and from looking at your geometry briefly I would
> say that Ecotect i.e. you created some very small polygons (0.0001 meters
> on one side) that Radiance considers zero-area polygons. When I run oconv
> or getbbox on your scene file I get 28 warnings like this one:
>
> getbbox: warning - zero area for polygon "zone02.rad00000"
>
> Looking at polygon zone02.rad00000 I find a valid polygon description but
> I guess Radiance has some limitation with regards to geometry. Are you
> sure you are modelling in the correct scale?
>
> Regards,
> Erwin
>
> -------- Original Message --------
> Subject: [Radiance-general] ecotect export - missing surfaces
> (18-Feb-2008 16:31)
> From: Nick Doylend <[email protected]>
> To: [email protected]
>
> >
> > I'm having some problems exporting geometry from Ecotect - I'm trying to
> > model some external shades. I've tried to build them up as 3D surfaces
> > but when I export and render only the two side pieces are visible, the
> > small top, bottom, back and front faces do not appear. What am I doing
> > wrong?
> >
> > http://ndoylend.fastmail.fm/temp/test_c.png
> >
> > The rest of the Radiance/Ecotect files are in the same directory if
> > anyone wants to take a look.
> >
> > Thanks for your help,
> >
> > Nick
> >
> > _______________________________________________
> > Radiance-general mailing list
> > [email protected]
> > http://www.radiance-online.org/mailman/listinfo/radiance-general
> >
> > To: [email protected]
>
>
>
> _______________________________________________
> Radiance-general mailing list
> [email protected]
> http://www.radiance-online.org/mailman/listinfo/radiance-general

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

To: [email protected]

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?

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" <[email protected]>
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?