I am developing a workflow where the building geometry originates as obj files.
What are the pros/cons of using ngons versus triangles to describe co-planar faces within radiance?
I have been able to automate merging co-planar triangles to form ngons, though holes in the ngon are not well described by the faces as per the invisible seams and clockwise order of the vertices. Currently the face is described as all counter-clockwise ignoring for the moment that the holes are totally inside the overall surface.
The first figure shows the triangulated test surface:
Image 2 is the merged triangles surface:
Note the boundary above the two holes is a single edge not 3 separate edges
From a purist view point my additional workflows would prefer the ngons, as long as I can find the edge boundaries (ie remove seams).
Which is the radiance’s preferred description for these non illum surfaces (triangles or a triangles merged into a single polygon)?
Kind regards
Terrance McMinn
With the exception of light sources (as you allude to in your post), polygons vs. triangles won’t make a big difference to rendering times, unless the triangles end up being long and skinny. In that case, they end up in rather more of the intersection tests than a combined polygon would, potentially increasing rendering time. The other effect is on memory, where a single, combined polygon takes up less RAM during rendering. This is not an issue for most models, but it’s something to bear in mind. The most efficient representation, memory-wise, is of course the Radiance triangle mesh, which you can use via obj2mesh. You don’t really need this until you’re in the range of millions of polygons, however.
Thanks for the confirmation Greg. This confirms my understanding of the process.
Looks like I should continue to improve my merge routine and breakdown lines with intersections so I am more able to define seams from edges for my additional workflow.
From my experimentation, it would seem that so far radiance handles the malformed ngon (with holes) as a continuous counterclockwise boundary without fuss. That is holes in the polygon not being clockwise ordered.
Kind regards
Terrance McMinn
The seams can cross over the holes and be all out of order and it shouldn’t matter for the intersection routines, as far as I know.
Most of the Radiance intersection testing uses scanlines, so the winding order of holes does not matter. The exception is for a few Radiance programs that use triangulation (most importantly rfluxmtx, but also some less-used ones such as eplus_adduvf) where the winding order of holes needs to be opposite the winding order of the outer polygon loop.