Archives for: 2007

2007-08-19

Personal Log

Permalink 06:45:51 pm, Categories: Personal Log  

This will probably be my last post before the Google Summer of Code deadline (which is tomorrow). I will still be posting with the same frequency as I did over the summer, as I work on the remaining elements of the COLLADA Conversion System - I just need to make sure I make a clear distinction of what I did before the deadline, and what is being done after the deadline. This post is that distinction. In addition, I won't be committing anything to the repository until next weekend, in order to give the reviewers a chance to look at what was done before the deadline.

That said, there are a number of things that still need to be developed in the COLLADA Conversion System. A list of these things is available at: http://www.crystalspace3d.org/trac/CS/wiki/COLLADA%20Conversion%20System
Please note that the list isn't complete, and a lot of the things currently on the list will be (hopefully) finished by the end of the summer or midway through the fall. I fully intend to keep working on this project throughout the fall and winter.

I'd like to take this opportunity to thank everyone who so graciously helped me this summer, including (but not limited to): Fossi, thebolt, MistaED, res2k, and jorrit. In addition, I am really thankful that the Crystal Space organization gave me this opportunity - it was an excellent experience, and a whole lot of fun! I think that this was the best way for me to begin contributing to the Crystal Space codebase, and I recommend to anyone interested in the same to apply for the Google Summer of Code next year with Crystal Space.

Finally, if you are interested in contributing and/or helping with the future development of the COLLADA conversion system, please feel free to contact me at jaywir3@gmail.com. I will give you up-to-date reports on what I have accomplished since this posting, and help you get acclimated to my coding style.

2007-08-16

Coding Log

Permalink 06:14:24 pm, Categories: Coding Log  

Just a brief update on my progress:

Normal and texture coordinate conversion (if they are given in the COLLADA file) are now complete, and working in viewmesh. I am currently working on getting blender to export the texture filename (it doesn't seem to want to do this), but once that is complete, I will be able to check my conversion of textures in general.

For the rest of the day, I plan to accomplish the following:

  • Basic scene conversion (translate/rotate/scale objects)
  • Camera/start positioning
  • Basic light conversion (if time permits this evening)

2007-08-09

Coding Log

Permalink 08:02:50 pm, Categories: Coding Log  

I was able to finish coding basic materials. The collada convertor now converts a color to a material, corresponding to the diffuse color of the <phong> or <blinn> shader in the COLLADA file, and then adds a <material> tag to mesh objects which utilize it.

Additionally, with help from thebolt and res2k, I was able to get the object to show up inside viewmesh. Both the material and geometry conversions seem to work quite well.

I have begun work on translating texture coordinates, as well as textures themselves. I anticipate this will be completed by either tomorrow afternoon, or possibly Saturday, depending on how many problems I encounter. I will then work on the world/scene conversions.

2007-08-08

Coding Log

Permalink 02:31:50 am, Categories: Coding Log  

I have nearly completed the basic materials conversion process. What remains, at the moment, is to convert from a csColladaMaterial object, which holds specular, diffuse, and ambient colors (COLLADA treats materials as shaders, which poses a slight problem when shaders aren't being used to their full extent), as well as some supporting information, which will be useful when we move from basic materials to shaders in the future, to the XML needed for the Crystal Space document. I expect this conversion should be finished tomorrow, at which time I will begin debugging the materials conversion process, and adding what needs to be added to make it sound.

Following this, I intend to work on the scene conversion, which will only be applicable for Crystal Space map files. I expect this will be fully finished and ready for use by August 20. Unfortunately, I think that the COLLADA Physics, advanced effects, and rigging/animation conversions will not be completed by the GSoC deadline of August 20. I believe that I will be able to get most of the rigging/animation, as well as possibly, the FX conversion, completed by the time school starts again. Of course, progress will slow once school starts, but I fully intend to continue working on this project even after I return to classes.

Some good news, on the other hand, is that I have almost finished the algorithm for 3D polygon surface triangulation, with some help from Dr. Martin Held. I am going to put this up in UML activity diagrams, and then post it, so folks have a chance to look it over, and give me their feedback, before implementing it. I will also be modifying the 2D triangulation conversion slightly, so that it works will polygons with holes. This won't happen until after the initial 3D triangulation algorithm is in place, however, so my initial COLLADA conversion code will not support polygons with holes - that is the <ph> tags.

2007-07-23

Design Log

Permalink 08:48:48 pm, Categories: Design Log  

I apologize for my lack of updates over the last week or two. Having completely finished geometry conversion, I decided to continue the project with COLLADA effects (FX). However, the problem was that the FX section of COLLADA is specifically designed to utilize a shader model, which is still in heavy development in Crystal Space. As such, I have decided (with the advice of res2k and thebolt) that the initial COLLADA conversion system will convert the <library_materials> section, and only convert <effect> elements which utilize <blinn> or <phong> elements - which will be converted to normal surface colorings. Shaders and other effects will be saved for a subsequent release of the COLLADA conversion system. Up to this point, textures are intended to be included in this first release.

Additionally, I have taken another look at the Triangulate3D class. After speaking with Martin Held (author of the FIST algorithm), I was informed that triangulation of polyhedral surfaces is, in some cases, an NP-complete problem. This I didn't realize. However, all is not lost, as he instructed me in ways to utilize heuristics to project 3D polygons onto planar surfaces, thereby converting a 3D polygon triangulation problem into a set of 2D triangulation problems, each of which can be solved in at worst, O(n^2) time, using an ear-clipping approach. I intend to implement this in the coming few days.

Finally, I suspect there are a few minor bugs in the geometry conversion, which I will address as soon as I have time. It is possible, however, that I may not get to them until after the scene conversion is finished. I am, as of yet, still unable to see the exported cs library files using viewmesh. I will post an example cs file output from the collada conversion system in the next day or so, so that others can have a look at it, and perhaps tell me what I am doing wrong that it doesn't appear in viewmesh. The syntax and whatnot appear correct, but perhaps something is just messed up. The viewmesh program doesn't spit out an error - it does seem to load the mesh, it just doesn't appear in the scene.

That's all for today. I'll keep you all posted on further progress as I make it.

2007-07-15

Coding Log

Permalink 04:08:08 am, Categories: Coding Log  

After some arduous coding this afternoon and evening, I was able to get started on the materials section of the code. I was also able to finish writing the implementation of the general polygon conversion case (the triangulate method doesn't work still, but the code is in place for when it does work correctly).

I added a method to csTriangleMesh called AddTriangleMesh(const csTriangleMesh&), which merges an existing triangle mesh with the current one. Essentially, what it does is add all of the vertices of the parameter mesh, as well as all of the triangles to the current csTriangleMesh. This was necessary for the polygon implementation, as I had a bunch of csTriangleMeshes floating around, and I wanted exactly one of them. I figured this fit best inside the csTriangleMesh class itself, although this is open for debate. Also open for debate is whether the name of the function should be something more descriptive, such as "MergeInto()" or the like.

I haven't made a commit today, because there are still things that I want to test before committing it to the branch. (e.g. I haven't fully tested the AddTriangleMesh() function yet, and I don't want to commit without knowing it works 100%).

Finally, I want to state that I have been placing warning messages into the code for items in the collada convertor which aren't implemented yet. (e.g. the general polygon case, as well as polygons with holes, triangle strips, and triangle fans). It will now warn a user if a case is encountered that isn't fully implemented yet. Also, I'm not sure how to handle the <lines> element, because as we have moved fully to triangles, how are lines displayed in CS?

2007-07-13

Coding Log

Permalink 08:14:37 pm, Categories: Coding Log  

After finishing the triangle geometry conversion, I have restarted looking at the Triangulate3D function. For some crazy reason, I still can't figure out why IsConvex() doesn't work quite right. Or rather, I know why it doesn't work right, but I am unsure how to fix it. The problem lies in the situation where when I am inserting consecutive points into a csPlane3 object, sometimes the resulting plane is defined counter clockwise, and sometimes it is defined clockwise. e.g. if one considers the polygon defined by the points:

(0, 10, 10)
(0, -10, 10)
(0, -10, -10)
(20, 5, -10)
(10, 0, -10)
(0, 10, -10)

Point number 4 (that is (10, 0, -10)) should be convex. However, what happens is that since the polygon loops back around, the plane defined by points 4, 5, and 3 is defined counter-clockwise, resulting in an incorrect result for the IsConvex() test. I am not quite sure how to fix this. Anyone who thinks they can provide some insight, feel free to look at my code. It's available in the libcrystalspace project (in MSVC) under the files triangulate3d.h and triangulate3d.cpp. It's been placed in the csgeom file, if you are not using msvc.

As a result of this problem, I am going to continue with the collada conversion by next moving to materials conversion. The fact that the collada conversion system doesn't currently support any polygons other than triangles isn't immediately a problem, since COLLADA exporting from Blender allows the user to export only triangles, which can then be used to test the collada system. I will look into the materials conversion today, and hopefully have it coded in the next few days, at which time I will re-investigate the triangulation function.

2007-07-10

Coding Log Supplemental

Permalink 11:19:12 pm, Categories: Coding Log  

I edited the code to make sure that xml tag parameters were all lowercase (e.g. 'meshfact' instead of 'meshFact'). Also, I added a plugin tag so that it could be viewable in a scene once exported. It appears that the viewability still isn't there, though, as exported XML files can be imported into viewmesh using 'Import Lib', but the triangles don't show up. There aren't any errors, just no triangles. I wonder if there are other things that I need in the XML file (e.g. materials) before it will display.

Coding Log

Permalink 09:22:28 pm, Categories: Coding Log  

I was able to get the triangle conversion working completely today. It doesn't yet convert vertex normals from COLLADA format to CS. What it *does* do, however, is read in all of the vertices from the COLLADA file, add them to a triangle mesh, then construct triangles from the given vertices, and index the vertices accordingly. Once completed, the triangles are retrieved from the csTriangleMesh object, and written to the CS XML document in the correct format.

For the remainder of the day, I am going to be working on Triangulate3D(), as this is still not completed. Tomorrow, I hope to be finishing general polygon conversion.

2007-07-07

Coding Log

Permalink 09:00:55 am, Categories: Coding Log  

I've redesigned the triangulation routine, at the recommendation of thebolt, to utilize an ear clipping algorithm. As of right now, I have got the function working, but there are a few bugs still left in the code. Namely, the triangulation routine is returning a triangle for each vertex in the polygon, which of course is not correct. I'm fairly certain I know where in the code the bug lies.

I intend to have this bug fixed tomorrow, at which time I will extend the code to work with polygons that have holes.

I am going to postpone testing of the triangulation function until after I have the rest of the geometry code finished. I feel like I am slipping further and further behind, and I need to make sure I get the XML conversion completed, as the convertor will be near useless without it. ;)

2007-07-03

Design Log

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

My intention today was to get the triangulate3d code written, but unfortunately, it looks like that isn't going to happen. Things have just been going really slow today. Thus, to adapt the schedule, I think I am going to combine the Triangulation and Finishing of Geometry conversion into a single stage. The combination of these two should be done by the time I laid out for Convert Geometry to be done.

The concept I have for the triangulation code is fairly straightforward. I intend to utilize the MakeMonotone algorithm given in deBerg et. al.'s computational geometry book. (I originally intended to use a Delaunay Triangulation, but I don't think that it's necessary to do all that work - we are given a polygon in 3D, so that makes the problem a little easier than a point cloud). Now, the problem I see is that the MakeMonotone algorithm (that is, break the polygon into y-monotone pieces, then triangulate each of these and combine) works on a 2D polygon. Normally, I thought it would be easiest simply to project the 3D polygon onto a 2D plane, but this doesn't work if the polygon wraps over on itself (consider a polygon like the following: http://www.cosy.sbg.ac.at/~held/projects/triang/spiral_01.gif
). Thus, my idea is to perform the following:

  1. Map from 3D to 2D in some manner

  2. Break polygon with holes into separate polygons without holes

  3. Triangulate each polygon according to algorithm in deBerg et. al.

  4. Re-construct original 2D polygon with holes

  5. Revert to original 3D polygon by un-doing mapping

The problem will be to determine the mapping (Note: The removal of holes isn't trivial, but I have an algorithm for it somewhere... I just can't remember where it is at the moment. I will find it. So, I'm going to do everything else first, then add it in later.) I thought about an LSCM-unwrap type of algorithm, but that relies on user cuts. The thing is, that if the polygon is some kind of wierd 3D shape that loops back on itself, then it's no longer a polygon, and I probably can just ignore that case.

The code I have been working on today has been mostly to add a test application, so I can visualize the two versions of a polygon. Ideally, I want to create a split window. The top has the un-triangulated polygon, and the bottom has the triangulated one. To begin with, what I want to do is show the polygon in 3D in the top (the original polygon), then show the polygon in 2D after the mapping in the bottom. I am working on this application, which will be called apptri3dtest, as this is being written.

2007-07-02

Personal Log

Permalink 03:47:18 am, Categories: Personal Log  

I have been mulling over the concept of Triangulations, and I feel that I have come up with a good solution to the triangulation problem. First, I think that the class csTriangulate2 will suffice for most of what I need in the COLLADA conversion. However, I will need to adapt it to handle general polygons, including those with holes. I figured since I will be performing this, it might be a good idea to make sure that the triangulation class conforms to the SCF system, and give it an interface - say something like iTriangulator. Thus, the inheritance will look like:

               iTriangulator
                     ^
                     |
                     |
       -------------------------------
      |                               |
csTriangulate2                csTriangulate3 (new)

I realize that my schedule has slipped a little bit, but in order to get things back on track, I plan the following re-vamped schedule for the remainder of the summer:

Triangulation: July 2 - July 3
Finish Geometry Conversion: July 4 - July 13
Materials and Texture Conversion: July 14 - July 28
Lighting/Scene Conversion: July 29 - July 31
Physics Conversion: August 1 - August 10
Animation/Rigging Conversion: August 11 - August 20

2007-06-27

Design Log Supplemental

Permalink 02:05:58 am, Categories: Design Log  

I have run into a problem which I didn't anticipate prior to two minutes ago. Unfortunately, support for <p> elements in Crystal Space is going away (as I understand it, it wasn't especially useful, anyway). This, along with the fact that it didn't previously handle general polygons anyway, presents the following problem:

* Before converting to Crystal Space format, all polygons in COLLADA format which are of type <polygons>, or <polylists>, will need to be triangulated.

So, it appears as though I will be dusting off my Computational Geometry book from last semester and attempting to find out what the best method of utilizing a Delaunay Triangulation is. I am going to look into libraries for this purpose, as I have heard the DT implementation is a nightmare. So, sorry folks, but it doesn't look like there's going to be a commit in the next couple of days.

2007-06-26

Coding/Design Log

Permalink 08:49:57 pm, Categories: Design Log, Coding Log  

I have managed to get the code working for the new design. The following is the new activity diagram for ConvertGeometry().


This includes two of the new objects, csColladaMesh and csColladaAccessor. Both of these objects have, at their core, a Process() function. The Process() function essentially parses the XML document and retrieves the necessary information. The activity diagram of csColladaMesh::Process() follows:



And the activity diagram for csColladaAccessor::Process():



The next stage will be to integrate a listing of polygons into the mesh object. This should be fairly straightforward, as before, and will be composed of yet another class, csColladaPolygon, which will have as sub-classes: csColladaSimplePolygon, csColladaTriangle, csColladaTriangleFan, csColladaTriangleStrip, csColladaLine, and csColladaLineStrip. I hope to have all of these converted and ready by this afternoon.

Design Log

Permalink 05:22:07 am, Categories: Design Log  

I have decided to go back and re-think the design of the library itself. In hindsight, I think that to make the code cleaner and more robust, it will be beneficial to add another couple of classes. Namely, what I added was a class representing the mesh itself. Ideally, I want to be able to process the COLLADA file in a single pass, without having to jump around looking for different elements in the document structure multiple times. To this end, I have decided to add a csColladaMesh class, which will effectively represent data stored in a mesh object. As of right now, this consists of just vertices. I will extend it in the near future. A new class diagram, with two new classes, is given below. I am currently working on redesign of the activity diagrams. They should be done tomorrow morning.

Note that I don't anticipate that this redesign will affect my schedule. I am merely doing this for my own ease of use.

COLLADA Conversion Library Class Diagram rev3

2007-06-25

Design Log

Permalink 02:06:28 am, Categories: Design Log  

I ran into some trouble this weekend within the conversion of triangles and triangle fans. I decided that the method I used previously to convert polygons was somewhat convoluted and much too difficult to interpret in order to effectively re-use. Thus, I have decided to redesign this conversion method, and separate it into several conversion functions:

  • ConvertGeometry() - Main Function (public)
  • ConvertVertices() - Sub-function for conversion of vertex arrays (private)
  • ConvertPolygons() - Sub-function for conversion of <polygons> and <polylist> elements (private)
  • ConvertTriangles() - Sub-function for conversion of <triangles>, <trifans>, and <tristrips> elements (private)
  • ConvertLines() - Sub-function for conversion of <lines>, <linestrips> elements (private)

For the first iteration, only ConvertGeometry() will be implemented, which in turn will call ConvertVertices() and ConvertPolygons(), so both of those will need to be implemented as well. The first iteration will also implement materials and scene conversion functions, at a basic level. I intend to have iteration one finished before July 9.

Unfortunately, I am currently in the middle of battling a migraine headache, and was unable to get much done today. As such, my original plan of committing this evening will have to be postponed until tomorrow or Tuesday. Once I clean up the codebase, and make sure that my implementations are cleaner than they are right now, I will commit the finished ConvertGeometry() code. As of right now, the only un-implemented functionality is the trifans and tristrips elements, however, as I previously said, I am redesigning some of these functions so they follow a more logical pattern.

2007-06-22

Coding Log

Permalink 04:10:42 am, Categories: Coding Log  

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:

  • Implement <triangle> conversion
  • Implement <trifan> conversion
  • Implement normal conversion
  • Test and debug ConvertGeometry()

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. ;)

2007-06-17

Coding Log

Permalink 03:36:30 am, Categories: Coding Log  

I was able to get vertex conversion working correctly today. As of right now, the ConvertGeometry() function does the following for each <mesh> object:

  • Retrieves the array of vertices from the <source> element specified .
  • Converts this array of vertices from string format to float.
  • Stores this array of vertices as <v> elements under a meshFact object with a name the same as the id attribute specified in the collada <source> element.

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.

2007-06-16

Personal Log

Permalink 06:05:17 am, Categories: Personal Log  

I didn't realize that I was supposted to update history.txt in the docs folder after each change I made to the code. Unfortunately, over the past 2 weeks or so, I have neglected to do this. I updated the history.txt file to give a brief overview of what I have done to date, but it is a very general overview. If anyone would like a more comprehensive annotation, please see either the SVN log, or this log.

For future reference, I will be updating history.txt before each commit. I apologize for any problems this may cause, and will update the history file to add more depth if folks feel the addition I have given (June 2, I believe) isn't sufficient to describe my work over the past 2 weeks. Note that this currently only affects my SVN branch, not the CS main branch.

Design Log

Permalink 05:55:34 am, Categories: Design Log, Coding Log  

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.

2007-06-14

Design Log

Permalink 01:48:07 am, Categories: Design Log  

Before beginning work on the ConvertGeometry() design, I have begun reading the COLLADA: Sailing the gulf of 3D digital content creation book, in order to better acquaint myself with the esoteric aspects of COLLADA. I have found that the book is quite political, with a large amount of unnecessary historical background and self-justification on the part of the authors. While this is a harsh criticism, I do find that the information in the book is extensive and extraordinarily relevant to the project at hand.

In reading the book, and gaining insight of the COLLADA format from the authors' perspectives, I have come across an interesting design question: Is it necessary to include the <asset> tag in the conversion process from COLLADA to CS? The asset tag seems designed to give credit to the author of the 3D media and to represent what type of software/hardware configuration the media was designed on, as well as for. The dilemma occurs when we consider that there is no symmetric place for this information in the Crystal Space map/library files.

I submit that this information is not necessary to include in the Crystal Space map/library file for two reasons:

  1. Crystal Space digital media files, while an open standard, are proprietary to the Crystal Space project. I mean this in that, the files are not restrictive of licenses and/or copyrights, but that the files are specific to the Crystal Space engine. An artist would not use a Crystal Space map file for a map designed to run on the Unreal engine. Because of this, COLLADA files are likely to be the file of choice for artists and media contributors to store/backup/retain their files in, assuming they will be converting from COLLADA to Crystal Space. This last bit is important - if someone intends to use the COLLADA conversion system, it is likely (not guaranteed) that they will want to use COLLADA as their storage format, and Crystal Space as their runtime format.

  2. Information about which tool was used to produce the media is unneccessary, provided it works inside the Crystal Space engine. Does it matter whether Maya or Blender was used to produce a model, if it looks the same in Crystal Space? I argue no.

Given these two reasons, I will proceed with the intention that the asset tags can be completely removed, and not converted to Crystal Space format. If this is not an acceptable conclusion, I believe the Crystal Space file format would need to be changed. However, I think changing the file format to include this information would be unnecessary and, in fact, wasteful of time and space complexity. After all, the more tags that the engine needs to parse during rendering, the longer it will take per frame, and information about the author isn't going to affect how the frame looks in the end, right?

I will be working tomorrow on design schematics for the ConvertGeometry() operation, and hope to have final versions ready for the design log tomorrow.

2007-06-12

Design Log

Permalink 06:21:25 pm, Categories: Design Log, Coding Log  

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());
colCon->Load("/colladafiles/something.dae", CS_COLLADA_FILE);
colCon->Load("/colladafiles/output.xml", CS_MAP_FILE);
// the idea is that colCon->Convert() would go here
colCon->Write("/colladafiles/output.xml");

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.

Coding Log

Permalink 02:12:07 am, Categories: Coding Log  

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.

2007-06-08

Coding Log

Permalink 04:18:13 am, Categories: Coding Log  

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. :)

2007-06-05

Coding Log Supplemental

Permalink 11:55:02 pm, Categories: Coding Log  

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();

return true;
}

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.

Coding Log

Permalink 04:53:16 am, Categories: Coding Log  

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:


svn co https://crystal.svn.sourceforge.net/svnroot/crystal/CS/branches/soc2007/collada/

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

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.

2007-05-03

Summer of Code to Begin

Permalink 12:27:22 am, Categories: Personal Log  

Ok, well I intend to keep a daily log here of my work on the COLLADA conversion utility/library for GSoC. I probably will be posting off and on until around May 20, but after that, it will be a daily (perhaps more than daily) log. I am really excited to begin working on this project. I have been looking forward to it for the remainder of this semester - thinking 'man...if I just get through these next couple of weeks, then I get to do cool stuff' Hehe. Anyway, for those of you who I have never met, my name is Scott Johnson. I'm a PhD student at the University of Minnesota. I have worked with Crystal Space for about a year and a half now, but this is the first time I am going to get the opportunity to really get my hands dirty with the engine itself (rather than applications that use it). I hope this will be a jump off point for me to start working continuously on different parts of the CS engine.

Say hi if you get a chance - my nick on irc is jwir3, and I'm always willing to chat over email. scottj {at} cs.umn.edu - I love meeting new people, especially those that share my interests, so don't feel shy to drop me an email!

2007
 << Current>>
Jan Feb Mar Apr
May Jun Jul Aug
Sep Oct Nov Dec

Search

Categories

Misc

XML Feeds

What is this?

powered by
b2evolution