Simple, solid Collada parsing

OpenGL Development
#1

3D model file loading seems to be the worst part of making an engine, from my experience and what im reading about it. Specifications are rarely met, every vendor does things his own way, there are a million things that can go wrong. Still, it can’t be this hard to get a .dae file working in my engine.

I’ve got a parser set up, and it works with some files, and with some it doesn’t, then some models are extremely distorted (Adobe Mixamo exports for example), while others work perfectly fine. Isn’t there a simple, it-just-works-tier library i can add to my project and be done with it?

I realize that when some people say “Collada loader”, what they really mean is the full infrastructure required for animating, rendering and so on, but i really mean just that, parsing a file, having its information there to be dealt with by the engine.

I’ve also read that the professional way of “asset pipelining” is to never actually load filetypes like Collada, FBX, MD5 and so on, and instead creating a custom file format for the engine, and then converting those filetypes into the proprietary custom format with some external application. Is that a good way to go about it? And what would be the best application for those conversions?

If anyone is interested in at least a sometimes-working collada parser, i can upload the code, it’s not very large. The data structure i use looks like this:

Models:



# Model
- MeshData
- JointsData

# MeshData
- float[] vertices
- float[] textureCoords
- float[] normals
- int[] indices
- int[] jointIds
- float[] vertexWeights
- float furthestPoint

# JointsData
- int jointCount
- JointData headJoint

# JointData
- int index
- String name
- Matrix4f bindLocalTransform
- List<JointData> children

Animations:



# AnimationData
- float lengthSeconds
- KeyFrameData[] keyFrames

# KeyFrameData
- float time
- List<JointTransformData> jointTransformData

# JointTransformData
- String jointNameId
- Matrix4f jointLocalTransform
#2

There is Assimp, You could try the lwjgl binding or the full port I am doing here (althought collada is not yet complete)

Anyway, you are totally right about the specifications, like agent also said, it’s a mess. That’s why I am primary aiming to stick to assimp and then maybe fix some bug only if needed (like one affecting binary ply).

Exactly.

That’s the most efficient way, you shape your loader on your needs. But it’s also the most time-consuming and less-flexible option. It’s up to you and it depends if you really need the best performances or not. If you load assets offline, in general is not worth.

#3

Thank you for the reply. I’ve read about Assimp. Is it good? And flexible enough to adjust it to the data structure i’ve got? Im still on LWJGL 2, so i’d have to migrate to 3 before trying the bindings. Right now my Blender / 3DS Max to Game “pipeline” is a horrible nightmare with 20 possible places for errors and too many variables, is Assimp the rigid, established library i wish it to be?

Is it possible to run Assimp completely standalone, without any bindings, just to load Colladas and output them into my custom format? Or alternatively, can i read somewhere about the data structure assimp uses? Im trying to find the established standards and best practice to deal with animations, so maybe my structure isn’t very smart in the first place.

Your port looks interesting, on the status page it says that Collada is supported with extentions. Whatever that means: Is it viable for use right now, or is something else missing?

#4

I’ve written a .blend file I/O library, if you are actually going for Blender (http://homac.cakelab.org/projects/JavaBlend/).

You get access to the full blender data model (including animations etc.).

#5

There is also http://xith.org/javadoc/jagatoo/index.html?org/jagatoo/loaders/models/collada/COLLADALoader.html. I think it is not widely used and outdated, but it’s standalone and might be able to serve as a converter.

#6

Yep, it’s really good actually and they are really active and supporting developers, imho.

The coolest thing about Assimp is that it represents a common unique interface between your program and the 40+ formats out there. Usually, each format is first parsed in one intermediate structure (sometimes called dom) and then loaded into assimp format. That is: whatever format you read, you know Assimp is going to present it to you in the same well-known structure.

Yes, that’s absolutely possible.

You can read about Assimp structure here. It’s a single module of a big opengl tutorial series. I find it quite good and I hope you will find it exhaustive for your questions.

One thing I am confident about is that, since those guys are used to deal with so many different standards, they surely must have gotten the best (or at least one of the best) format structure out there.

Extension support means nothing else than supporting files with extensions. Because in theory you can try to load a .dae file without the .dae extension. At first Assimp will try to determine the extension, if not possible, it will loop through all the importers format you specified (all, by default), read a chunk of the header and try to determine which format it is. But you made a good point, maybe I should make that clearer…

About collada status, the porting is almost ready, parser is done while loader is ~80%. Other than that “only” testing & debugging remains. If you want to try that out before it gets into release, you shall clone the project :stuck_out_tongue:

#7

Can you upload code of you collada parser?

#8
#9

Hi

JogAmp’s Ardor3D Continuation has a good Collada importer (tested with lots of models, fully supporting skeletal animation), it supports several other formats and it has an OBJ exporter, JMonkeyEngine 3 has some excellent importers too, Unlicense supports numerous formats including FBX and Blender.