Actually, I found csTriangulate2, which might work for me. The collada specification allows for holes, but I could extend this to handle this case.
~Scott Scott Johnson wrote: > I noticed that csTriangleMeshTools doesn't have a Triangulate() > function. Would this be something useful to add? > > ~Scott > > > Jorrit Tyberghein wrote: > >> Quick answer: csPolygonMeshTools is indeed deprecated (and clearly >> marked that way as well in the api docs). csTriangleMeshTools is the >> new one. >> >> Greetings, >> >> On 6/28/07, Scott Johnson <[EMAIL PROTECTED]> wrote: >> >> >>> Hi Everyone. >>> >>> Sorry, this is somewhat of a long email, but I wanted to poll the CS >>> user community. >>> >>> I learned yesterday that the <p> tag inside the Crystal Space file >>> format is going to be going away, and that <t> (triangles) are soon >>> going to be the only way to place polygons into a CS file. This isn't a >>> big problem, but it did send me for somewhat of a loop with the COLLADA >>> conversion stuff. The problem I'm encountering is that there is a >>> general <p> tag inside COLLADA. Thus, any polygons using this tag would >>> need to be triangulated before converting to CS format. Again, this >>> isn't a major problem- I'm well versed in the magic of Delaunay >>> Triangulations ;). The problem I'm having is deciding HOW I should >>> attack this. I have come up with probably three somewhat different >>> solutions: >>> >>> 1. Create a separate interface, iTriangulator, and implement the >>> triangulation method within this (either using an external LGPL-covered >>> library, or implement my own). The problem with this approach is the >>> data structure. Typically, Delaunay Triangulation algorithms are run on >>> a data structure called a DCEL (Doubly-Connected Edge List), which is >>> essentially a set of linked lists over the vertices and edges of a >>> polygon. Unfortunately, as I can tell, CS doesn't really implement this >>> (unless I just didn't see it in my looking over the API) - at least not >>> directly (it might be implemented inside some class somewhere, but not >>> that I saw on looking over the API). I could add this data structure as >>> either an internal data structure to iTriangulator, or possibly as an >>> external interface, iDCEL. This might get too low-level, though, and >>> possibly might not be useful to the general public. >>> >>> 2. Write an internal routine into the COLLADA convertor that utilizes a >>> data structure, and then just converts for the sake of the COLLADA >>> conversion library. This is probably the quickest method, but my >>> intuition tells me that a triangulation system, once written, might be >>> useful to others. Thus the reason I thought maybe I should separate it >>> into another library, so others can use it. >>> >>> 3. Attempt to convert polygons to an existing internal CS data >>> structure, such as csPolygonMeshTools, and then use the existing >>> Triangulate() function on it. This, at first glance, appears to be the >>> best method, but when I last checked, it said something about being >>> deprecated (which I can't seem to find now - I may have been half >>> asleep), which makes me nervous. I bring this up because I don't know >>> enough about this interface to know whether or not it's going to go away >>> in the near future (as I found out about <p> hehe - although in all >>> consolation, it wouldn't have worked, anyway...so it was good to know. >>> Thanks, res!) >>> >>> So, this leads us to my major question - which of these methods (or >>> possibly a method I didn't list) would be the best approach? Once I get >>> started, I think I could probably implement this in a matter of 2-3 >>> days, so I don't anticipate that this will set my schedule back too >>> terribly much. One thing that concerns me, however, is the >>> implementation. I would rather use an existing implementation, since >>> it's a known algorithm, and I've heard there are a lot of little demons >>> to contend with when implementing DT. Thus, it would probably be better >>> in this case not to re-invent the wheel (although I am fond of doing >>> that ;) ). In addition, I don't want to add a lot of bloat to the CS >>> engine by creating additional data structures which already exist in >>> another form. >>> >>> Thanks for any suggestions/comments/questions you can relate on this issue! >>> >>> ~Scott >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> _______________________________________________ >>> Crystal-main mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/crystal-main >>> Unsubscribe: mailto:[EMAIL PROTECTED] >>> >>> >>> >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Crystal-main mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/crystal-main > Unsubscribe: mailto:[EMAIL PROTECTED] > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[EMAIL PROTECTED]
