Category: Design Log

2007-06-02

Design Log Supplemental

Permalink 10:26:48 pm, Categories: Design Log  

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.

Design Log 2 June 2007

Permalink 07:51:55 pm, Categories: Design Log  

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.

2007-05-28

Design Log 28 May 2007

Permalink 10:06:56 pm, Categories: Design Log  

My goals for today are the following:

  • Get iDocument code working correctly
  • Fix UML Class Diagrams
  • Create Use Cases

I began tackling the first item on the list, but ran into a few troubles, which I am still trying to figure out (although the day is not yet gone ;) ).

Basically, what it amounts to is that I have been working to try and get the basic iDocument system figured out. It's actually very easy to understand, and pretty easy to implement, but I am getting a segfault which confounds me. Specifically, I have the following code to load a COLLADA file:

colladaFile = fileSystem->Open(TESTFILE, VFS_FILE_READ);
        if (!colladaFile.IsValid())	
	{
		cout << "Attempting to open: " << TESTDIR << TESTFILE << endl;
		return ReportError("Error: Unable to open COLLADA file on VFS.  Terminating.");
	}

	// This works
	csRef<iDataBuffer> buf = colladaFile->GetAllData();
	//cout << buf->GetData() << endl;
	
	// This does not work
	colladaDocument->Parse(colladaFile);
	//colladaDocument->Parse(buf);

One would think that the colladaDocument->Parse() calls would actually parse the file in question, which happens to be a COLLADA file exported with Blender. Since COLLADA files are XML files, the XMLRead plugin (or the XMLTiny plugin) should be able to at least PARSE the file. Instead, I get a segfault when I attempt to run the program. The lines previous to it (the ones commented with // this works) work fine - the file is clearly read into the data buffer and then output again, if I want it to be. It's the parsing that seems to be a pain.

The second item hasn't yet been accomplished, due to some problems with Java on my current workstation, and thus my inability to use my current UML tool: Visual Paradigm. I intend to get this problem fixed by tomorrow afternoon, but I haven't got the slightest clue why install4j doesn't work. (There were some problems with the system, so I decided to reinstall VP. When I tried to do so, the installer gives me a null pointer exception. Wierd).

I am currently working on the third item on the list, and should be finished by late this afternoon. I will publish an update when I am finished, along with downloadable versions of the Use Case Documents.

2007-05-25

Design Log 25 May 2007

Permalink 10:14:52 pm, Categories: Design Log  

After beginning development of the SCF interface for the COLLADA Conversion Library (which, I believe will be called iColladaConvertor), I have decided that constructing a rudementary Use Case diagram would be beneficial. This will, at least, allow me to visualize what it is I am trying to keep in my brain - that is, what the library will actually DO, and how that will be structured. A diagram is attached:

COLLADA Conversion Library Use Case Diagram

Ideally, the user will be able to interface with the library in multiple ways. I am designing it such that the user could concievable convert COLLADA files to Crystal Space formats 'on-the-fly', although this would be time consuming. I will develop an alternative method, such that instead of calling all of the individual ConvertGeometry(), ConvertRiggingAnimation(), etc... functions, they would be able to do a complete conversion of all COLLADA files before the game starts, (or possibly, as things develop, before a zone is loaded). Of course, the general idea would still be that COLLADA is an interchange format, and thus, most of the conversion should happen offline, before the game ships, this would allow users to support COLLADA formats in-game, for example, with users who wish to use COLLADA formats for modding a game already constructed. At any rate, the idea is to abstract as much as possible, so that it 'just works', but yet allow those users who may only want to display the geometry of a COLLADA file (i.e. for testing purposes) and not anything else (e.g. the shaders, lighting, animation/rigging, etc...) to access individual conversion functions.

2007-05-24

Design Log 23 May 2007

Permalink 03:15:37 am, Categories: Design Log  

I began implementing what will become the COLLADA Conversion Utility. I started out with this piece, because I am working to learn the basics of iDocument/iDocumentNode usage. It's fairly straightforward and simple, but as the program evolves, it will be more complex. Right now, all the application does is open a Crystal Space Window, and associate with a document. It's probably not necessary to have it as a Crystal Space Application, but since I had a template for this, it seemed easiest at the moment. I will probably change it tomorrow so that it's just a standard application utilizing Crystal Space functionality.

Since the SOC hasn't actually started yet, I've been taking it easy and just mainly focusing on research. Thus, my posts until the 28th will probably be fairly brief, but you can expect more detailed log entries after May 28th.

2007-05-22

Design Log 22 May 2007

Permalink 10:54:13 pm, Categories: Design Log  

I have been working on the design aspects of the COLLADA Conversion implementation. My primary goal at this point is to create an overall structure of where I want to go, before beginning actual coding on the 28th. I have constructed a basic (very basic) class diagram. I probably should've created a Use Case Diagram first, but I feel this would be somewhat of a waste of time, as I already am familiar with what the system should do, and how it should interact with the user. In the case of a use case diagram for the library, this might be useful, but I want to design one such that it exhibits the traits necessary for the first iteration. The basic class diagram is attached. The XMLFile class, as well as the Translator (basic class) will more than likely be replaced by iDocument and iDocumentNode classes, which are already present in the CS codebase. I just placed them in for now, so that I have a direction of where to proceed and what I need to implement.

Additionally, I will be looking into researching how the iDocument interfaces work, and how to use them in my implementation, in the next day or two.

COLLADA Conversion Library Initial Class Diagram

2007-05-11

Design Log 10 May 2007

Permalink 12:40:43 am, Categories: Design Log  

I began working on the overall design of the project. I am experienced with UML and formal design processes, so I will be drawing upon that expertise in order to make sure that my project is successful. The package diagram (designed to illustrate which distinct packages, or components of the software need to be developed) is attached.

Package Diagram for COLLADA Conversion Project

The overall goal is to define a library which will transform (either on the fly, or offline) a COLLADA file to a Crystal Space world or library file using an XML translation process. Thus, an XML interpreter will be necessary. The idea is that both COLLADA and CS files are XML files, and should be verifiable. Thus, I might be able to diagnose and eliminate errors before they cause the program to crash or whatnot - if it's not valid XML, throw it out. Also, while the XML interpreter is going to be a class inside of my design schematics, I assume that Crystal Space already has an interpreter, as well as an XML File class.

<< Previous Page ::

July 2014
Mon Tue Wed Thu Fri Sat Sun
 << <   > >>
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Search

Categories

Misc

XML Feeds

What is this?

powered by
b2evolution