I finished the basic SCF interface for the Collada Conversion Library. It looks like the following:
struct iColladaConvertor : public virtual iBase
SCF_INTERFACE(iColladaConvertor, 1, 0, 0);
virtual const char* Load(const char *str, csColladaFileType typeEnum) = 0;
virtual const char* Load(iString *str, csColladaFileType typeEnum) = 0;
virtual const char* Load(iFile *file, csColladaFileType typeEnum) = 0;
virtual const char* Load(iDataBuffer *db, csColladaFileType typeEnum) = 0;
virtual const char* Convert() = 0;
virtual bool ConvertGeometry(iDocumentNode *geometrySection) = 0;
virtual bool ConvertLighting(iDocumentNode *lightingSection) = 0;
virtual bool ConvertTextureShading(iDocumentNode *textureSection) = 0;
virtual bool ConvertRiggingAnimation(iDocumentNode *riggingSection) = 0;
virtual bool ConvertPhysics(iDocumentNode *physicsSection) = 0;
An implementation has been started, but there are a few bugs yet to work out. In particular, I haven't yet decided whether I want a specific Write() function or not. If I include one, this function will force a write to the disk (i.e. allowing for a user of the library to immediately write converted files to the hard drive). The reason I'm not sure if I want this is because essentially the library should do the conversion in memory, and then give the results back to the client. It is the client's job to determine if they want to write the results to disk, or use them on the fly. On the other hand, it might encapsulate things better if a Write() function were added, because then it would be a self-contained collada conversion system.
This is something I will have to discuss and ponder over the next few days.
I have been able to get the iDocument stuff working, which I was having trouble with previously. It turns out it was merely a situation where I was confusing an iDocument* pointer with a csRef<iDocument> variable. Once found, this error was easy to correct.
I have been working on developing Use Cases for the COLLADA conversion, as I feel this will help me better understand exactly what needs to be done during each conversion step. Additionally, I modified the class diagram to contain a single class, that of iColladaConvertor, (along with an implementation), and having each individual conversion step be a separate function, rather than a separate class. I am not sure why I originally designed it to have multiple classes, but this definitely seems like overkill, and would cause the system to become bloated and possibly slow. (Not to mention being a pain with memory management. The revised class diagram is shown below.
The documentation for the use cases can be downloaded from here. I created it using a program called Use Case Maker, which is actually pretty elegant. I don't know what some of the items are, though, so there is somewhat of a lot of useless information. Sorry to those of you who get frustrated with that kind of stuff - I don't know how to turn it off. Anyway, the information which is valid right now is mainly the convert geometry use case, as that will be the one I am working on first. I've started the implementation of this particular function, and I will be updating this log on the progress of it as the day continues.
|<< <||Current||> >>|