Hi Again Everyone -
Haven't posted in a while, so I thought I would give an update on how things have progressed on the COLLADA convertor. Between Mike Gist and myself, we've been able to get just about everything working. The only holdup - the surface triangulator - has been implemented, and appears to be working as expected. Currently, the surface triangulator needs some testing, though, as I've only tested it with basic models. So, if you have a chance, I'd really appreciate it if all of you folks out there with COLLADA models could give it a try. Here's what we're looking at testing:
- COLLADA Conversion of Geometry from .dae (COLLADA 1.4) to Crystal Space
- Surface Triangulation (iTriangulate3D and corresponding csTriangulate3D). This triangulation routine will NOT handle holes, but should handle any other 3D polygon of arbitrary size and planarity (i.e. either planar or non-planar polygons). I'm still working on getting it working with holes, but this isn't extremely pressing, as they are pretty rare.
- Camera and Scene conversion and proper viewing angles, etc...
- Basic material conversion (color, image texture, etc...)
The most recent addition, in terms of features, to the system is the last one - the materials. Since we're not 100% sure how we're going to handle shaders from COLLADA to CS (if at all), the materials area of the converter may be a little sparse. And, it's also somewhat volatile.
Also, we need testers on the following systems (as I don't have access to them):
- Mac OSX
On the first day of sessions (Saturday), one of the sessions I attended was that of managing content in open source games. There was a previous session on open source games in general, which I will cover in a later post. A very important question in open source games is how we can develop games with high-quality content, but still manage artists who are not familiar with open source development procedures?
The folks from Battle for Wesnoth began talking about their problems in getting content for their game. Originally, they stated, they had a system that had fairly bad graphics. Over time, it has become a much more aesthetically appealing system, with animated sprites and high-quality artwork. Over time, they were able to find a good artist to place in the position of lead artist. The lead artist is the person who signs off on all the artwork in the game, whether it be textures, conceptual artwork, or sprites and animations.
One thing Battle for Wesnoth developers had to deal with is younger artists. They were able to get artwork from a number of teenagers, but this artwork was fairly low-quality, due to the lack of experience of the artists. So, at times, it was necessary to just tell people that their artwork wasn't of the quality necessary in Battle for Wesnoth. On the other hand, they admitted that they accepted artwork from a number of artists who weren't initially very good, but improved over time.
Worldforge is another project that had representatives present in this session. Worldforge isn't exactly a game, really, but rather an open source world-building application. The requirements for this application are incredibly massive, and a method is needed for developing a method of accepting, rating, and storing assets. The representatives from Worldforge stated that they have begun building an application that takes assets from artists, and stores and presents it for evaluation from an administrator. Ideally, it would be nice to have a system that can rank assets, present it for approval to an administrator, then if approved, commit it to the asset version control system. The application they presented is called Wombat, and they are asking for help from open source developers to evaluate and improve this application.
BZFlag also spoke about their asset-management system. A primary problem they encounter is that artists don't understand licensing. One of the things they had to place into their application was an option for "I stole this" for artists submitting content.
One of the things that I find more difficult about content in games is finding artists. I realize that expecting artists to commit assets into an svn server is probably not going to work, but how does one come upon artists to begin with? I think this is a very important question, as both groups brought up the idea that artists aren't as familiar with open source software development as computer scientists are. Thus, they aren't as exposed to the different groups as we are, and don't have any idea that they can get experience with an open source software group. Some of the questions that I have are, "How can we advertise in a more effective method, to minimize budget constraints, to get artists more interested in our projects?", "How can we keep artists around, once they've developed a single piece of artwork?", "How can we help improve a mediocre artists' skills?", and "How can we express to an artist what we need done, and have them actually do the necessary work, rather than what they want to do?".
More pictures and posts to come!
So, I just got back to Roseville from Mountain View, CA. It was pretty nice there, so it's not quite so wonderful to return to 34 degree (F) weather here in Minnesota, but home is home, and I'm glad to be back.
It was a great trip. It was my first time attending the mentor summit (as this is the first time I was a mentor for gsoc), and I had a great time. I learned a ton, and had the opportunity to meet a large number of very interesting people. In addition, I learned quite a bit about open source management, as well as game development in general. I intend to share all of these things with you over the next few days, but I need to get some sleep right now, so I will leave you with the next best thing: pictures! (more to come, I promise)
So - back to work on COLLADA conversion. I'm still reworking the 3d surface triangulation algorithm I originally wrote last summer, but with all the changes to the rendermanager and such, I've mostly been getting caught up with setting up a good testing environment. In order to isolate and identify bugs in the code I wrote, I am attempting to visualize the 3D surface triangulation using a csSimpleRenderMesh. So, once triangulated, the csTriangleMesh is converted to a csSimpleRenderMesh, and then visualized. I am having difficulty right now trying to visualize this. I can't seem to get the csSimpleRenderMesh to appear on the screen. Part of the situation was in getting the render manager set up and working, but now that seems to be finished.
I have the following code setup to perform the rendering of what (I believe) is a simple triangle:
// we want to draw result
verts.Set (0, 0, 0);
verts.Set (10.0, 0, 0);
verts.Set(0, 10.0, 0);
cols.Set(1.0, 0.0, 0.0, 1.0);
cols.Set(1.0, 0.0, 0.0, 1.0);
cols.Set(1.0, 0.0, 0.0, 1.0);
rendMesh.vertices = verts;
rendMesh.vertexCount = 3;
rendMesh.colors = cols;
rendMesh.meshtype = CS_MESHTYPE_TRIANGLES;
alf.alphaType = alf.alphaSmooth;
alf.autoAlphaMode = false;
rendMesh.alphaType = alf;
g3d->BeginDraw(engine->GetBeginDrawFlags() | CSDRAW_3DGRAPHICS);
However, all I get is a black screen. I should say that a bit ago, I got a black screen. Now, I added the line
view->Draw() and get a segfault. This was due (in part) to the rendermanager not being set correctly. This problem has been corrected, but I am rebuilding the Crystal Space core library at the moment, as I was previously getting a number of weird errors with walktest. Walktest displayed, but not like it did previously, without the new rendermanager code in the trunk. The level seems to be full of errors now. I thought perhaps it could be my platform, along with some weirdness in incremental linking with the msvc compiler, so I am rebuilding things just to be sure. Once this is complete, I will see if the new 3D triangulation test visualization works.
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 email@example.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.
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)
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.
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.
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.
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?