I apologize for my lack of updates over the last week or two. Having completely finished geometry conversion, I decided to continue the project with COLLADA effects (FX). However, the problem was that the FX section of COLLADA is specifically designed to utilize a shader model, which is still in heavy development in Crystal Space. As such, I have decided (with the advice of res2k and thebolt) that the initial COLLADA conversion system will convert the <library_materials> section, and only convert <effect> elements which utilize <blinn> or <phong> elements - which will be converted to normal surface colorings. Shaders and other effects will be saved for a subsequent release of the COLLADA conversion system. Up to this point, textures are intended to be included in this first release.
Additionally, I have taken another look at the Triangulate3D class. After speaking with Martin Held (author of the FIST algorithm), I was informed that triangulation of polyhedral surfaces is, in some cases, an NP-complete problem. This I didn't realize. However, all is not lost, as he instructed me in ways to utilize heuristics to project 3D polygons onto planar surfaces, thereby converting a 3D polygon triangulation problem into a set of 2D triangulation problems, each of which can be solved in at worst, O(n^2) time, using an ear-clipping approach. I intend to implement this in the coming few days.
Finally, I suspect there are a few minor bugs in the geometry conversion, which I will address as soon as I have time. It is possible, however, that I may not get to them until after the scene conversion is finished. I am, as of yet, still unable to see the exported cs library files using viewmesh. I will post an example cs file output from the collada conversion system in the next day or so, so that others can have a look at it, and perhaps tell me what I am doing wrong that it doesn't appear in viewmesh. The syntax and whatnot appear correct, but perhaps something is just messed up. The viewmesh program doesn't spit out an error - it does seem to load the mesh, it just doesn't appear in the scene.
That's all for today. I'll keep you all posted on further progress as I make it.
My intention today was to get the triangulate3d code written, but unfortunately, it looks like that isn't going to happen. Things have just been going really slow today. Thus, to adapt the schedule, I think I am going to combine the Triangulation and Finishing of Geometry conversion into a single stage. The combination of these two should be done by the time I laid out for Convert Geometry to be done.
The concept I have for the triangulation code is fairly straightforward. I intend to utilize the MakeMonotone algorithm given in deBerg et. al.'s computational geometry book. (I originally intended to use a Delaunay Triangulation, but I don't think that it's necessary to do all that work - we are given a polygon in 3D, so that makes the problem a little easier than a point cloud). Now, the problem I see is that the MakeMonotone algorithm (that is, break the polygon into y-monotone pieces, then triangulate each of these and combine) works on a 2D polygon. Normally, I thought it would be easiest simply to project the 3D polygon onto a 2D plane, but this doesn't work if the polygon wraps over on itself (consider a polygon like the following: http://www.cosy.sbg.ac.at/~held/projects/triang/spiral_01.gif
). Thus, my idea is to perform the following:
The problem will be to determine the mapping (Note: The removal of holes isn't trivial, but I have an algorithm for it somewhere... I just can't remember where it is at the moment. I will find it. So, I'm going to do everything else first, then add it in later.) I thought about an LSCM-unwrap type of algorithm, but that relies on user cuts. The thing is, that if the polygon is some kind of wierd 3D shape that loops back on itself, then it's no longer a polygon, and I probably can just ignore that case.
The code I have been working on today has been mostly to add a test application, so I can visualize the two versions of a polygon. Ideally, I want to create a split window. The top has the un-triangulated polygon, and the bottom has the triangulated one. To begin with, what I want to do is show the polygon in 3D in the top (the original polygon), then show the polygon in 2D after the mapping in the bottom. I am working on this application, which will be called apptri3dtest, as this is being written.
I have run into a problem which I didn't anticipate prior to two minutes ago. Unfortunately, support for <p> elements in Crystal Space is going away (as I understand it, it wasn't especially useful, anyway). This, along with the fact that it didn't previously handle general polygons anyway, presents the following problem:
* Before converting to Crystal Space format, all polygons in COLLADA format which are of type <polygons>, or <polylists>, will need to be triangulated.
So, it appears as though I will be dusting off my Computational Geometry book from last semester and attempting to find out what the best method of utilizing a Delaunay Triangulation is. I am going to look into libraries for this purpose, as I have heard the DT implementation is a nightmare. So, sorry folks, but it doesn't look like there's going to be a commit in the next couple of days.
This includes two of the new objects, csColladaMesh and csColladaAccessor. Both of these objects have, at their core, a Process() function. The Process() function essentially parses the XML document and retrieves the necessary information. The activity diagram of csColladaMesh::Process() follows:
And the activity diagram for csColladaAccessor::Process():
The next stage will be to integrate a listing of polygons into the mesh object. This should be fairly straightforward, as before, and will be composed of yet another class, csColladaPolygon, which will have as sub-classes: csColladaSimplePolygon, csColladaTriangle, csColladaTriangleFan, csColladaTriangleStrip, csColladaLine, and csColladaLineStrip. I hope to have all of these converted and ready by this afternoon.
I have decided to go back and re-think the design of the library itself. In hindsight, I think that to make the code cleaner and more robust, it will be beneficial to add another couple of classes. Namely, what I added was a class representing the mesh itself. Ideally, I want to be able to process the COLLADA file in a single pass, without having to jump around looking for different elements in the document structure multiple times. To this end, I have decided to add a csColladaMesh class, which will effectively represent data stored in a mesh object. As of right now, this consists of just vertices. I will extend it in the near future. A new class diagram, with two new classes, is given below. I am currently working on redesign of the activity diagrams. They should be done tomorrow morning.
I ran into some trouble this weekend within the conversion of triangles and triangle fans. I decided that the method I used previously to convert polygons was somewhat convoluted and much too difficult to interpret in order to effectively re-use. Thus, I have decided to redesign this conversion method, and separate it into several conversion functions:
For the first iteration, only ConvertGeometry() will be implemented, which in turn will call ConvertVertices() and ConvertPolygons(), so both of those will need to be implemented as well. The first iteration will also implement materials and scene conversion functions, at a basic level. I intend to have iteration one finished before July 9.
Unfortunately, I am currently in the middle of battling a migraine headache, and was unable to get much done today. As such, my original plan of committing this evening will have to be postponed until tomorrow or Tuesday. Once I clean up the codebase, and make sure that my implementations are cleaner than they are right now, I will commit the finished ConvertGeometry() code. As of right now, the only un-implemented functionality is the trifans and tristrips elements, however, as I previously said, I am redesigning some of these functions so they follow a more logical pattern.
I spent all of today working on the ConvertGeometry() function. It's a fairly extensive task, and I anticipate it will take me through next week. Since there are a lot of details I need to keep in mind when writing the code for this function, I felt it would be best to design the algorithm for the function first, using UML activity diagrams.
The UML activity diagram for this function, as it stands right now, can be found here. Currently, I have only added functionality that will allow the verticies to be processed and converted to Crystal Space XML format. I am going to develop this function in iterations, and iteration one will be the addition of the <verticies> element of the COLLADA geometry schema. I have added code and begun implementing this function, however, since I am not finished debugging (actually, not even finished testing the first iteration), I have not yet committed to SVN.
Also, I updated the class diagram to account for changed functionality. It can be found here.
Before beginning work on the ConvertGeometry() design, I have begun reading the COLLADA: Sailing the gulf of 3D digital content creation book, in order to better acquaint myself with the esoteric aspects of COLLADA. I have found that the book is quite political, with a large amount of unnecessary historical background and self-justification on the part of the authors. While this is a harsh criticism, I do find that the information in the book is extensive and extraordinarily relevant to the project at hand.
In reading the book, and gaining insight of the COLLADA format from the authors' perspectives, I have come across an interesting design question: Is it necessary to include the <asset> tag in the conversion process from COLLADA to CS? The asset tag seems designed to give credit to the author of the 3D media and to represent what type of software/hardware configuration the media was designed on, as well as for. The dilemma occurs when we consider that there is no symmetric place for this information in the Crystal Space map/library files.
I submit that this information is not necessary to include in the Crystal Space map/library file for two reasons:
Given these two reasons, I will proceed with the intention that the asset tags can be completely removed, and not converted to Crystal Space format. If this is not an acceptable conclusion, I believe the Crystal Space file format would need to be changed. However, I think changing the file format to include this information would be unnecessary and, in fact, wasteful of time and space complexity. After all, the more tags that the engine needs to parse during rendering, the longer it will take per frame, and information about the author isn't going to affect how the frame looks in the end, right?
I will be working tomorrow on design schematics for the ConvertGeometry() operation, and hope to have final versions ready for the design log tomorrow.
I decided to implement a Write() function for the output. I feel that since the cs file being created more than likely going to be written out to a file, rather than used on the fly, it seems appropriate to short-circuit the inevitable getting of the iDocument, then using iDocument's write() function to write it to file. This doesn't seem to me a thing that should be left to the application. It's not necessary. Ideally, once the conversion process is finished, it should be written to a file, if desired.
The problem I see with this is that it places the conversion pipeline under the control of the user. It would be possible, for instance, for the user to do the following:
csRef<iColladaConvertor> colCon = csQueryRegistry<iColladaConvertor> (GetObjectRegistry());
// the idea is that colCon->Convert() would go here
Thus, it is possible that the user could cause the pipeline to become corrupted, due to either a simple error, or possibly a deliberate attempt to mess it up (why, I have no idea...but the chance is there). I have, at the moment, two boolean values indicating whether or not the collada and cs files, respectively, are ready, but they are set to true upon creation of the iDocument which represents these files (i.e. during the Load() functions). I could create additional boolean values, but this seems like somewhat of a hack. It's possible that the user would expect that Convert() be called upon Load() of a collada file, but what happens if a user only wanted to convert say, geometry? Then, the Load() function would go through unnecessary conversion routines, only to be converting a smaller subset. Thus, work is wasted (and this process could take a non-trivial amount of time, so it's worth considering).
Another problem becomes apparent in the code above. The Load() function doesn't really do anything with the path if the type of file being loaded is CS_MAP_FILE or CS_LIBRARY_FILE. This is because Load() assumes that these files are new files (since they are being converted from the COLLADA format), and so chooses to create a new iDocument object to represent them, placing either a <world> or <library> tag, respectively, inside the document. Thus, a path isn't needed. It's somewhat counter-intuitive (from my perspective) to provide a path upon load, but then have to re-provide a path (more than likely the same path) when you choose to Write(). I could simply save the path from the Load() function, but then what if the user wanted to convert from a collada file on-the-fly, and simply have it in memory? Then, the loaded path is wasted. This isn't a major concern, but I am trying to take all possibilities into account.
I am still wrestling with segfaults from the Write() function, but I hope to have them debugged by later today. I will keep the log apprised of my advancements.
On an administrative note, I realize that me placing the date in the title of my log entries is redundant, seeing as the blog system does this automatically. Thus, I am not going to do this anymore. You may think that my titles lack creativity, but I prefer to organize my thoughts this way, rather than continually trying to search through titles which may or may not have relevance to the actual text in the entry.
Anyway, I have updated the class diagram for the COLLADA conversion library. The changes I have made indicate design decisions I made to include the different steps of conversion as functions in a single class, rather than multiple classes. I have no idea why I originally designed it such that I had multiple classes for conversion - it really doesn't make any sense. This new method makes more sense. The diagram for it is shown below.
I am still debating whether or not to make these functions private. In reality, they will probably only be needed internally by the class, but I hesitate to make them private in the interest of supporting applications which may only need to convert COLLADA geometry, or animation, etc... Thus, for now, they will be left as publicly accessible functions, although this may change in the future, depending on input from the community.
:: Next Page >>
|<< <||> >>|