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]
