Certainly #1 should be fine. I'm not sure about #2, but it obviously could be made to work. #3 - do you mean loops of the same face? If so, again, I imagine that it could be made to work. If not, then it should be OK; it handles separate faces independently. I don't understand the last. The tesselation process takes planar loops in 3-space, projects them onto an axis-perpendicular plane (chosen intelligently, but I don't recall how), does the tesselation in 2D, then projects back.
My point is that the FLE type *should* provide the capabilities you want; if it doesn't, then we should fix it rather than start over from scratch. Regarding the env var, sure, that can be done by a field attribute. It certainly shouldn't be done the way it is; this way the env var is accessed over and over. Pretty stupid. The saving are real, BTW; I debugged some FLEs that were very large - thousands of loop points and multiply nesting - state boundaries, where states had lakes that had islands that had puddles... A real pain. Looking for intersecting edges (at least naively) is n^2, and it seemed at the time that non-self-intersecting loops were the rule, not the exception. Greg Randall Hopper <[EMAIL PROTECTED]>@opendx.watson.ibm.com on 11/01/2001 01:52:21 PM Please respond to [email protected] Sent by: [EMAIL PROTECTED] To: [email protected] cc: Subject: Re: [opendx-dev] 3D models -> DX: Anyone for polygon support? Gregory D Abram: > What is the difference between the polygons you want and the FLEs? Aren't > FLEs the superset? >From browsing _newtri.c briefly, I thought the answer was no. If FLEs should handle any polygon set, are you saying that (in theory) DX should handle the following with FLE fields: 1) self-intersecting loops (e.g. figure 8) 2) self-overlapping loops (i.e. edges coincident with other edges) 4) different loops intersecting or overlapping each other 5) arbitrary planar loop sets in 3D which have no bearing on 2D topology If so, then I completely agree. I would add that polygons in DX should "just work", without any special user actions. > They are handled as you describe - tesselated in the > renderer into triangles - even the OpenGL renderer. In fact, its this > tesselation that produces the topology error you mention - tessellating > arbitrary loops in floating-point space is *hard*. If there are cases that > result in the topology error message, maybe we should just fix it (in > _newtri.c). BTW, there is an environment variable to set (DX_NESTED_LOOPS) > that supports greater flexibility in the supported topology at the cost of > a less efficient algorithm. The $DX_NESTED_LOOPS trick seems to render some of the polygons I've been working with that were causing problems. So that polygons will "just work", would you have any objections to the addition of a field attribute that performs the function of "export DX_NESTED_LOOPS=1". Say, attribute "polygons" value 1 or something along those lines? I'll volunteer to implement and commit this. Randy P.S. While we're on the subject, attached are a few polys that fill incorrectly w/ or w/o the DX_NESTED_LOOPS trick. Also, I notice that the tessellator gets stuck in an infinite loop when fed arbitrary polygons with DX_NESTED_LOOPS set. If we go with FLEs for general polygons, I can isolate which polys are causing the problem. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
