2007-06-04

Coding Log

Permalink 12:09:46 am, Categories: Coding Log  

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

2007-06-03

Design Log

Permalink 09:56:14 pm, Categories: Design Log  

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.


COLLADA Conversion Library Class Diagram rev2

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.

Coding Log 3 June 2007

Permalink 08:32:26 pm, Categories: Coding Log  

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.

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-29

Personal Log 28 May 2007

Permalink 03:34:59 am, Categories: Personal Log  

I will be traveling from Grand Forks to Minneapolis for the better part of the day tomorrow. As such, I probably won't be making a log entry for 29 May 2007. I will be addressing the following issues when I get back home to Minneapolis:

  • Determine problems with parsing of XML files using current setup
  • Make UML class diagrams more concise and readable
  • Develop Use Case documents
  • Finish basic application and parsing of a simply XML file

Once these items are finished, I will begin working on the geometry conversion functionality in the COLLADA conversion library.

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

<< Previous Page :: Next Page >>

November 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

Search

Categories

Misc

XML Feeds

What is this?

powered by
b2evolution