Horde3D

Hey all,

So I'm getting on with my game, but I'm running across a bit of an issue I thought I would share. My levels are procedurally generated in CityEngine (www.procedural.com) and I'm hitting the upper bounds of what is reasonable with the .DEA format. Basically the colladaconverter is taking maybe 10-30 minutes to convert a mesh with lots of verts (130k or so) to a geom file. So I was wondering if it isnt prudent to add support for another mesh format that maybe has binary data rather than all of the string data and indirections of collada?

I'm thinking maybe .3ds format or some such?

Any thoughts?

Nice program this CityEngine. But I think we don't plan to officially support any other exchange format, because this means always lots of work for maintenance. Several years ago we used VRML for the exchange of 3D data between different programs. It was horrible. Each 3D program produced different output and no program was able to reproduce the original data. I guess this lack of exchange format was also one of the reasons for inventing Collada.

But if you want, we can give you write access to the Community branch and you can add an additional converter to it. Maybe some others in the community can help you then improving and maintaining it.

Parsing (xml + conversion to internal structures) a 33 mb collada file takes about 4 seconds on my machine (release, started without debugger attached). The actual xml parsing is about a second. This number does not include the mesh processing (vertex splitting/merging, data validation, tangent space basis computation, etc.) which you would have with binary source data as well.

I assume that most of your time is spent in the vertex cache optimization. You can disable it with a command line argument. The algorithm is relatively fast in general but if you have a single mesh with tens of thousands of polys it will take its time as it has almost quadratic complexity. It is better to have several meshes with a sane number of polys, also for culling etc.

Out of curiosity I tried integrating rapidxml into ColladaConv. The xml parsing is a lot faster (a fraction of a second for the 33 mb file) but it does not make a big difference in total as the xml parsing time before was just about a second.

Hmm, thats weird, because I'm using a release colladaconv and its taking a lot longer than that. I guess its probably the vertex processing thats taking the longest time, but the time it takes to start actually processing isnt insignificant.

I'll maybe do some timings later and see whats the issue.

CityEngine looks amazing! I can't express enough how important something like that is for things like games! At my last job making a whole city by hand was a crazy effort between many artists! Not to mention the bug count for things like lods/simplified collision boxes/navmesh/etc.

Ok enough exclamations, .obj isn't a binary format but it doesn't seem to take too long to convert between maya and zbrush and back for like 2 million triangles or so so that might be an option, but it only supports the real basics.

_________________
-Alex
Website

BTW zoombapup, does CityEngine create a single mesh for the whole city? In that case you wouldn't have different materials, so I rather doubt that. And what size does your DAE file have? It would be good to know where most of the time is spent so that we can optimize ColladaConv a bit if that is required.

Its got a bunch of options for exporting, it can batch meshes by material and whatnot. I used that option to export with. I'll try the alternative options out this week and let you know if they improve things.

We have checked in a small performance update for ColladaConv. Should make parsing quite a bit faster.

Another update: We officially switched to RapidXml for all our xml parsing.

The ColladaConv parsing speed is really good now. The 33 mb dae file is parsed (pure XML parsing and bringing into internal structures) in clearly less than a second on my machine

If there should be any problems with the new parser please let us know.