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.
|<< <||Current||> >>|