OgreCollada pre-alpha release

[xavier]

Hi All,

For those interested, I've opened up what I've got so far in OgreCollada. I am listing it as pre-alpha because it's just short of feature-complete (see below), but it's usable in its current form.

You can get the source from https://svn.clashofsteel.net:8445/OgreCollada

I've put up a basic Wiki page on the library:

http://www.ogre3d.org/wiki/index.php/OgreCollada

[Kencho]

Wow, thanks for sharing this, man!

[xavier]

YW -- it's there in the true open-source fashion, that I hope someone finds it useful, and so on.

Any issues anyone has with using the library/code/project-setups (and yes, I know it's still technically "pre-alpha" stage), let me know. I have only had my limited set of art assets to test with, and my known build configuration, so in the interests of making it as widely accessible as possible I'm open to any suggestions and willing to do what I can to fix any issues.

On the bottom that Wiki page, btw, are the known issues.

[Jabberwocky]

Great news, a very useful addition.
So many tools provide Collada support, this will greatly enhance the DCC to Ogre pipeline.

[Wolfmanfx]

Thats really nice are the collada plugins for maya working with maya 2008 version?

[xavier]

The ColladaMaya source builds easily against all versions of Maya (even copies the DLL and MEL scripts to your install location as a post-build step). I don't have 2008 (I only have 6.5) so I can't test it for sure, but it should build fine.

[sinbad]

Nice, if you want a spot in ogreaddons, let me know.

[etsinko]

Thanks for the release!
What did you mean by "Patch FCollada to support the way that SketchUp exports its scene graph" in your TODO list? Does SketchUp export the scene in a specific way different from Collada's?

[xavier]

Yes, SketchUp uses the <library_nodes> library to store its scene nodes, and according to Feeling, they are the only ones (Feeling Software had never heard of any other COLLADA-compliant tool doing things that way, so they had no support for it in FCollada).

From Feeling in their forums:

Google SketchUp is the first one who seems to be using library_nodes, as no-one else really uses them at this point.

We do not intend to make any changes there at this time. If you do decide to tackle this problem yourself, we'd be glad to integrate your fix in FCollada.

[VictorMoran]

library_nodes?
do you mean library_visual_scenes

[xavier]

No, <library_nodes>. SketchUp's COLLADA export sticks everything in <library_nodes> and then instantiates the root node from the visual scene, applying a transform to that root node from the visual scene.

The problem is that FCollada treats <library_nodes> as if it were a visual scene, which loses the connection between that visual_scene transform and the node hierarchy it is transforming. I found this out when trying to load an export from SketchUp here at work; apart from it's Z-up view of the world (which OgreCollada handles), the data was loading on on its side (its root transform could not be applied).

Unfortunately (for me), you see that Feeling doesn't intend to add that support, so it's something I (or any other interested soul) has to do.

[xavier]

Nice, if you want a spot in ogreaddons, let me know.

Thanks Sinbad -- if you don't mind, an OgreCollada forum might be a good start. I'd like to keep the repo in SVN for now, though (I've become quite fond of AnkhSVN lately ).

[VictorMoran]

I think SketchUp is correct, Fcollada is wrong.
library_nodes is the way Collada provides instancing for large scenes with many complex hierarchies.
SketchUp is used to transport huge scenes so they need to support that funtionality.
Why no rectify the error and have Fcollada fix it instead of legitimizing it by supporting an aberration of the specifications

[xavier]

I think SketchUp is correct, Fcollada is wrong.

They agree. I didn't put that part of the post in, but they started off the reply with "yes, this is one of the few areas where FCollada is not compliant".

Why no rectify the error and have Fcollada fix it instead of legitimizing it by supporting an aberration of the specifications

That is what I plan to do, hence that todo -- make a patch for FCollada to work properly with <library_nodes>.

It's starting to sound like you are getting upset about this.

[voxel]

Thanks! Will take a look at this.

Could this be a start of a revolution in OGRE?

[SpaceDude]

Cool! I've been reading bits and bobs about Collada in the past but I'm still a bit misty on what it means in practise.

From what I understand, Collada is designed in theory to be a file format which can be used to transfer game content (meshes, skeletons, animations, shaders, physics shapes, etc...) between any modelling tool and any game engine. Am I right so far?

But what does this mean in practise for say, oh I don't know, somebody developing games with ogre using maya ? (Note: this happens to be what I am doing)

My current process to get an animated character into ogre would be to use the Maya Ogre exporter to export the .mesh and .skeleton files. And then I'll define a material and cg file manually because I want to use shaders. And I'll define my physics ragdoll manually in the code because I have no easy way to define and export that from Maya.

Is the idea that I can scrap the .mesh, .skeleton, .material, .cg(?) files and instead use some Collada file format which contains all this information and is exported directly from a Maya Collada plugin and read directly into my game using the OgreCollada plugin?

[Shadow007]

You get the first part right, but doing the second part would be unoptimal : the COLLADA is an exchange format and not a final one. It's not optimized for performance but for interoperability.

The Idea would that you can take the content from any COLLADA content providing software and export it as a Collada file. The Collada--> Ogre converter would then convert to .mesh, .skeleton etc ... With only one converter, you get "total" compatibility. A single converter means less errors/overhead etc ...

The SAME COLLADA --> Ogre would be used if the content came from 3DSMax. The Content could originate from Maya, saved as a Collada. A shaders editor could load it, allow you to edit the shaders, maybe show the shaded meshes to you, before saving he content back in the COLADA format. An animator could use he's favorite animation software to load the shaded meshes, and output animated shaded meshes, still as COLLADA.

You could also use a COLLADA meshreader to do what you suggest, but that would not be the best performancewise. Still it would allow your artists to preview their work in your game faster.

Finally, after all the content was created, you use the Ogre converter to get the data in an engine-optimized format.

[xavier]

You could also use a COLLADA meshreader to do what you suggest, but that would not be the best performancewise. Still it would allow your artists to preview their work in your game faster.

Finally, after all the content was created, you use the Ogre converter to get the data in an engine-optimized format.

This is the general intent of OgreCollada (at least, it's how I intend to use it at work and on my side project) -- fast iteration on in-game content, and also to be used to create the final binary data format(s) from the COLLADA doc.

The COLLADA book tries to make the case that the COLLADA doc itself is a fine final format, but that argument just doesn't hold up in practice -- FCollada is fast in parsing COLLADA, but it still cannot keep up with slurping in pre-crunched binary data.

[etsinko]

Xavier,
I looked into your ogreCollada and found one thing - you use rotation matrix to normalize document so it has y axis pointing upwards.
Actually FCollada has a function StandardizeUpAxisAndLength() in FCDocumentTools namespace.
Also it has FCDGeometryPolygonsTools namespace with other useful functions, such as Triangulate(), GenerateUniqueIndices().
Hope this helps!

[xavier]

Yeah, I tried the generate-unique-indices function and it turns out that on large data sets it causes memory usage to max out my 2GB RAM (not to mention running in something like N^2 or N^3 time). The algorithm to generate unique indices from the base vertex data isn't that difficult (this is the fourth Ogre exporter/importer I've worked on, so I'm fairly used to it by now ) so it made sense to roll my own on that.

I'll look into the StandardizeUpAxisAndLength() function; missed that one, thanks.

[SpaceDude]

Ok xavier, so basically the intent is to load COLLADA files directly into the given application during development. And once you are ready for a release, the COLLADA files should be converted to Ogre's native file formats.

How much of a burden is this on the programmers though? It seems to me you would need different code for loading data from COLLADA as opposed to from Ogre's native file formats.

Currently I would create an entity like this:

Code: Select all

mSceneMgr()->createEntity("MyEntity", "MyMesh.mesh");

Can I still use the same line of code with OgreCollada even know the mesh is not defined in a file called "MyMesh.mesh" but in some Collada file?

[xavier]

Ok xavier, so basically the intent is to load COLLADA files directly into the given application during development. And once you are ready for a release, the COLLADA files should be converted to Ogre's native file formats.

How much of a burden is this on the programmers though? It seems to me you would need different code for loading data from COLLADA as opposed to from Ogre's native file formats.

You do. It depends on how your data pipeline is set up. At Planet Moon, all data was built to binary form and packed into data files even during dev. At Hyperpia, however, our artists would like a simpler way of "overriding" any existing binary data with COLLADA for faster iteration, so this fits that bill rather well.

The extra work is localized to the same area of the code as the binary loading, so maintenance isn't that much of a burden. OgreCollada does all of the heavy lifting, if you use it.

Currently I would create an entity like this:

Code: Select all

mSceneMgr()->createEntity("MyEntity", "MyMesh.mesh");

Can I still use the same line of code with OgreCollada even know the mesh is not defined in a file called "MyMesh.mesh" but in some Collada file?

Correct, I even just had this discussion with one of our engineers last night.

Ogre uses the mesh filename for the resource name by coincidence (and for convenience), really. The name is just the unique name of the resource (same is true for all resources), so when OgreCollada creates, say, Entity instances based on Mesh objects, it just uses the name directly.

Bear in mind that currently, OgreCollada creates the Entity objects for each mesh -- in the near future I intend to activate the "import flags" to enable the user to tell OgreCollada which Ogre objects it wants created on import. The user will, at that time, also have the option of overriding behaviors in the callback methods as well.

[SpaceDude]

Ok great, that clears things up for me. Thanks for the info xavier. I look forward to the final version

[VictorMoran]

It's starting to sound like you are getting upset about this.

No I am not upset about this, I was just making an observation.

Yes, SketchUp uses the <library_nodes> library to store its scene nodes, and according to Feeling, they are the only ones (Feeling Software had never heard of any other COLLADA-compliant tool doing things that way, so they had no support for it in FCollada).

You seems to be saying that the error becomes the norm, because one major developer is saying so.
I think that if you visit the official Collada forum you will find that developers do use the library_nodes. They are not different the library_geometry, or libray_material, or library_image.
So by only using a subset of the specifications, files produced by your tool will be Collada compliance but your tool will not be compliance since it it will fail reading perfectly valid and ordinary files exported by other tools.
Are you upset that I made the observation?

[xavier]

It's starting to sound like you are getting upset about this.

No I am not upset about this, I was just making an observation.

Yes, SketchUp uses the <library_nodes> library to store its scene nodes, and according to Feeling, they are the only ones (Feeling Software had never heard of any other COLLADA-compliant tool doing things that way, so they had no support for it in FCollada).

You seems to be saying that the error becomes the norm, because one major developer is saying so.

I don't know where you got the idea that I said anything like this. I pointed out that I need to patch FCollada to be compliant -- it fails loading files from SketchUp because of this omission. That's all I said, nothing more, nothing less. I think your inexplicable emotions over all of this are causing you to read stuff into my words that isn't there.

I think that if you visit the official Collada forum you will find that developers do use the library_nodes. They are not different the library_geometry, or libray_material, or library_image.
So by only using a subset of the specifications, files produced by your tool will be Collada compliance but your tool will not be compliance since it it will fail reading perfectly valid and ordinary files exported by other tools.

I think we've covered this ad nauseum.

Are you upset that I made the observation?

Your verbiage was a bit incendiary above.