The last few days have been spent doing the grunt work for the ConvertGeometry() function. Most of this is pretty straightforward, as most of the COLLADA geometry converts directly to Crystal Space format. I have been adding functionality, debugging, adding functionality, debugging, etc... for the past 3 or 4 days. Since the function isn't complete until all of the functionality is added, I haven't performed a commit in a little while.
Right now, I am working to finish the <triangle> tag conversion. Once this is completed, I will test it and then begin implementation of triangle fans. This will then complete the polygon and triangle conversions, and I will perform normal coordinate conversion before proceeding to the ConvertTexturesShading() function.
For the near future, I intend to list functionality which needs to be implemented in each iteration. Once completed, I will then begin coding small bits of each conversion function before adding new functionality. I think this stricter iterative process will be better, since all of the conversion functionality depends on each of the other conversion functions.
I also intend to re-design some of the function names, as it's not entirely intuitive. I believe I will remove the ConvertTexturesShading() function, and add two new functions in its place: ConvertMaterials() and ConvertShading(). Similarly, I will also be adding a ConvertScene() function, in order to more intuitively support conversion of items like the camera. I have also toyed with the idea of splitting the Convert() function into two separate functions ConvertLibrary() and ConvertMap(), but I don't know if I am going to do this just yet.
For tomorrow, I plan to do the following:
Testing and debugging will continue through this weekend. I intend to make a commit Sunday night which has a completed ConvertGeometry() function, although if the schedule slips a little, this might not happen right on Sunday. ;)
I was able to get vertex conversion working correctly today. As of right now, the ConvertGeometry() function does the following for each <mesh> object:
This doesn't seem like a lot, but the code for it is actually quite extensive. This actually only converts to a <library>, currently. In order to convert to a <world> type file, I will need to determine how to represent portals. I believe this is going to need to be information either added to the COLLADA file in <extra> elements (as this is really what these are for), or perhaps there will be more information coming in future sections. Right now, my main design concern is to get the geometry (i.e. vertices, lines, polygons) working correctly before proceeding. Since the library element is a prerequisite for the <world>, (e.g. the <world> element often includes library elements outside of its own file), conversion of libraries seemed the logical place to start.
Additionally, I am not quite sure how to convert splines. As far as I can tell right now, splines are not part of the Crystal Space library definition. I could be incorrect, however. It might be possible to convert the splines to a polygonal mesh, similar to what Blender allows a user to do, but this would have to wait until the basics of the conversion system are in place.
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.
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.
Today was quite productive. I was able to setup all of the Load() functionality for loading a COLLADA file. I also added some functions for debugging, specifically reporting debug messages. It doesn't seem like a lot, but slowly, the functions are beginning to come together. Once I am able to get past this housekeeping stuff, I will be able to begin programming the actual COLLADA conversion functionality.
I want to be sure that all of the necessary checks are in place to determine if the file actually is a COLLADA file, and that it obeys certain constraints, before beginning the conversion procedures. It would be a huge frustration if I were to get knee-deep into the Convert() or ConvertGeometry() functionality and then find out that bugs are apparent in the Load() functions. Thus, the remainder of the day is going to be spent testing and updating the Load() functions, with possibly some time devoted to adding additional housekeeping functions.
I will keep the blog updated as I modify the code.
I was able to accomplish a lot today, although it doesn't feel like it. I spent most of the morning (and afternoon) working out how to get the dll generated by the plgcolladaconvertor project to actually load. Thanks to res2k, Rolenun_, and iceeey, I was successful. I didn't realize that the MSVC project files are automatically generated, and that if I create them manually, the needed resource file for embedding the .csplugin file into the dll on compilation is not present. After figuring this out, and fighting to get perl installed so I could do a 'jam msvcgen', I finally was able to get the project files in a reasonable state so I could build everything.
Once this was completed, I ran into another snag: the plugin was having problems initializing. Initially, I learned (again, thanks to res2k) that I had been trying to load the plugin crystalspace.utilities.colladacoverter, as opposted to crystalspace.utilities.colladaconvertor. This simple spelling mistake cost me roughly a hour to find, and I probably would still be at it, if it hadn't been for res. After a number of trial runs, and looking at bugplug.cpp, I was able to determine that the problem was in the Initialize() function returning false.
So, finally, after a lot of work, I have gotten the plugin to load successfully. I also implemented a Report() function, similar to the one found in bugplug.cpp, which takes a variable number of arguments. It's a private function, so it can't be accessed outside of the csColladaConvertor class, but it will be useful to report what's going on while I debug things.
On a more personal note, I ordered the COLLADA Book today (Sailing the seas of digitial concept creation, or something equally exotically titled). I have heard it's a good resource, and while the specification is detailed enough for me to work off of, any additional documentation always comes in handy ;). The wierd thing is, Amazon tells me that they won't be able to ship it for another few days, and they expect the arrival date won't be until June 18.
That's all for today. It was quite a day. :)
I performed the first basic compilations of both the plugin and the application, and they both went without any problems. I am in the process of writing some of the preliminary documentation in the header files (Doxygen style documents).
I have begun writing the Load() functions in the plugin library. I realized this morning that there could be a slight problem - the plugin requires TinyXML, as it needs to be able to write to the iDocument objects. Unfortunately, I am wondering if this will be problematic for a user who wishes to use XMLRead, since XMLRead is faster. In order to overcome what I perceive to be a problem like this, I have the document system used by my plugin to specifically initialize a csTinyDocumentSystem as follows:
bool csColladaConvertor::Initialize (iObjectRegistry* reg)
obj_reg = reg;
// create our own document system, since we will be reading and
// writing to the XML files
docSys = new csTinyDocumentSystem();
I am hoping that this will allow me to utilize the TinyXML document system without interfering with a user's document system of choice, when they initialize the iColladaConvertor plugin.
Today I spent most of the day setting up the skeletal structure of the conversion system, and polishing things up from yesterday. I also added some Doxygen documentation to both collada.h and csColladaConvertor.h. None of the implementation (save for the basic initialization stuff) has been added yet, but I will begin implementing ConvertGeometry() tomorrow.
If you would like to have a look at the work I have done thus far, please feel free to download it using subversion:
At the request of Eric Sunshine, I moved the COLLADA SCF interface file to reside in the ivaria directory. The new information is as follows:
COLLADA Conversion Library: SCF Interface Header File: /include/ivaria/collada.h
I have spent this morning creating Visual Studio projects and determining where in the CS codebase the COLLADA stuff will be located. I have entered most of my skeleton files (placeholders, really) into the CS codebase in the following locations (note that these are in my specific branch of SVN, not the trunk):
COLLADA Conversion Library: SCF Interface: /include/iutil/collada.h SCF Implementation: /plugins/colladaconvert/csColladaConvert.h /plugins/colladaconvert/csColladaConvert.cpp Project File: /mk/msvc71/plgcollada.vcprj COLLADA Conversion Console Application: Header File: /apps/colladaconvertor/appcolladaconvert.h Source File: /apps/colladaconvertor/appcolladaconvert.cpp Project File: /mk/msvc71/appcolladaconvert.vcprj
I wasn't absolutely sure whether the SCF interface file should go into iutil or not, although it seemed like a good choice. It can easily be moved, however, if other people feel it should be placed elsewhere in the codebase. I think that the other choices I made for locations were good, but feel free to comment on this if you feel it should be located elsewhere.
Also, it should be noted that these are simply skeleton files at the moment. They have some basic definitions and such, but are, for the most part, empty of functionality. Since I am still somewhat in the design phase, these will be populated with implementation as things progress. I will guarantee that they compile on my machine (a windows machine - hence the reason I am only populating the MSVC project files at the moment) each time I commit, but it is possible that they may not compile and/or have some difficulties on other platforms. I will rectify as many platforms as I can by the time the project is finished, but in the meantime, if you have a specific concern about it compiling on a platform other than windows while I am developing it, please feel free to comment on this blog, and I will see what I can do to accommodate any requests.
|<< <||> >>|