LWJGL Models

[princec]

I'm working on a LWJGL 3d model thing at the moment in the new-and-upcoming org.lwjgl.util subpackages.

It's got bones and animation in it, and will come with example renderer and example loader from XML format. Some of the code will no doubt be heavily influenced by Elias' TT code coz he's helping me write it

Should come in handy methinks. The only snag is exporting from the various tools out there.

Cas

[vrm]

We use a .obj loader, you will keep it open for new formats ?

org.lwjgl.utils, it's new ? how heavy it's going to be ?  

[karatemarkel]

Sounds interesting, I take it this is your own custom format then?

Games published by our own members! Check 'em out!

[Morgrog]

ohhh fun

any ETA on that? (well the alpha version or smthg)
I'd love to mess around with models (w/o paying for a modeler or learning Blender)

[princec]

The difference here being that the Model class I am designing is format agnostic. It's just an internal way to represent an animated boned skinned 3d model.

The clever part, as I say, is in the implementation of a Loader and Renderer. I'm going to write an XML Loader and hopefully tweak an existing 3ds exporter to output the correct XML. And I shall also write a "trivial" low-performance renderer as example code.

Cas

[cfmdobbie]

Feature set?  Is it a quick-and-dirty list of triangles, or are you making it a general-purpose NURBS/voxels/IK description?

Would you mind posting your current thoughts on the contents of the XML file, just so we have an idea of where you're headed?

[princec]

something like:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55   56   57   58   59   60   61   62   63   64   65   66   67   68   69   70   71   72   73   74   75   76   77   78   79   80   81   82   83   84   85   86   87

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> <!--       LWJGL model format template --> <!DOCTYPE model [       <!ELEMENT model (vertex+, triangle+, animation+)>       <!ATTLIST model material CDATA #REQUIRED>       <!ATTLIST model bones CDATA #REQUIRED>       <!ELEMENT vertex (skin+)>       <!ATTLIST vertex x CDATA #REQUIRED>       <!ATTLIST vertex y CDATA #REQUIRED>       <!ATTLIST vertex z CDATA #REQUIRED>       <!ATTLIST vertex u CDATA #REQUIRED>       <!ATTLIST vertex v CDATA #REQUIRED>       <!ATTLIST vertex nx CDATA #REQUIRED>       <!ATTLIST vertex ny CDATA #REQUIRED>       <!ATTLIST vertex nz CDATA #REQUIRED>             <!ELEMENT skin EMPTY>       <!ATTLIST skin bone CDATA #REQUIRED>       <!ATTLIST skin weight CDATA #REQUIRED>       <!ELEMENT triangle EMPTY>       <!ATTLIST triangle a CDATA #REQUIRED>       <!ATTLIST triangle b CDATA #REQUIRED>       <!ATTLIST triangle c CDATA #REQUIRED>             <!ELEMENT animation (frame+)>       <!ATTLIST animation name CDATA #REQUIRED>             <!ELEMENT frame (bone+)>       <!ATTLIST frame time CDATA>             <!ELEMENT bone EMPTY>       <!ATTLIST bone m00 CDATA #REQUIRED>       <!ATTLIST bone m01 CDATA #REQUIRED>       <!ATTLIST bone m02 CDATA #REQUIRED>       <!ATTLIST bone m03 CDATA #REQUIRED>       <!ATTLIST bone m10 CDATA #REQUIRED>       <!ATTLIST bone m11 CDATA #REQUIRED>       <!ATTLIST bone m12 CDATA #REQUIRED>       <!ATTLIST bone m13 CDATA #REQUIRED>       <!ATTLIST bone m20 CDATA #REQUIRED>       <!ATTLIST bone m21 CDATA #REQUIRED>       <!ATTLIST bone m22 CDATA #REQUIRED>       <!ATTLIST bone m23 CDATA #REQUIRED>       <!ATTLIST bone m30 CDATA #REQUIRED>       <!ATTLIST bone m31 CDATA #REQUIRED>       <!ATTLIST bone m32 CDATA #REQUIRED>       <!ATTLIST bone m33 CDATA #REQUIRED>       ]> <!--       The model can be made of one material only, given an arbitrary name.       The number of bones must be specified here.             If you need models made of multiple materials or multiple parts, then       what you really need is multiple models. --> <model material="arbitrary_name" bones="numbones">       <!--             Any number of vertices. The order of the vertices determines their index number             which is used by the triangle definitions.       -->       <vertex x="" y="" z="" u="" v="" nx="" ny="" nz="">             <!-- Any number of skin elements, describing how bones weight the vertex position -->             <skin bone="0" weight="1.0" />       </vertex>       <!-- Any number of discrete triangles. -->       <triangle a="0" b="1" c="2" />             <!-- Any number of animation frames, referenced by name for easy reference -->       <animation name="animation_name">             <!-- Any number of animation frames, with timing information -->             <frame time="0.0">                   <!-- All bones need to be specified -->                   <bone m00="" m01="" m02="" m03="" m10="" m11="" m12="" m13="" m20="" m21="" m22="" m23="" m30="" m31="" m32="" m33="" />             </frame>       </animation> </model>

Cas

[princec]

In other words, bones-triangles-animation, and not much else. See how it spreads the problem out into other areas?

Cas

[princec]

Ok, the model package now contains two kinds of model - mesh animated models, where the whole mesh is respecified every frame, and bone animated models, where only bones are updated every frame.

The base Model class is composed of a set of triangle index definitions, a skin of UV coordinates, and a map of animations.

The loader can load both from XML.

Comments please?

Now on to a trivial renderer.

Cas

[Chman]

Hehe, I've just taken a look to the model source code and it seems that you've made an amazing work once again !!!
Keep this up ! (and include it into lwjgl 1.0 ?)

I've just a question (it's not the good place to ask it but I don't want to make a specific thread for it) : when will be released the full 0.9 version ? because it still an alpha release...

Thanks for the great work ! I love lwjgl, it's an impressive lib

Chman

Games published by our own members! Check 'em out!

[cfmdobbie]

Here's a few questions/comments for you:

• Is there a specified format for the material name, a URL for example, or is it a logical name that the app should understand?
  
  
• It's not exactly how I like to see XML written - I prefer <bone> elements to be in a <bones> section etc, but that's personal preference.
  
  
• Is it worth putting an id on repeated elements?  It'd be easier to use if the numbers used by e.g. triangle definitions are present in the file - not for the computer, but for the user.  You'd have to change things to not work on file order but on id number instead - probably not a big change.
  
  
• I don't know anything about bone animation - I trust that the system presented both works and will be implementable in many different modellers!  I've always seen bones described as having length, but I guess that's just a visual aid.
  
  
• You have a bone count field, but not a vertex, triangle or animation count.  Why?
  
  
• What are nx, ny and nz?  Ah, normals.  Gotcha.
  
  
• What is the timing information - specified units or application-interpreted?
  
  
• Do you have updated XML fragments for us?  I don't see any examples in CVS.
  
  
• Loader.loadBone(): if you're making m3* optional, shouldn't you make m*3 optional as well?
  
  
• Might vertex colours be worth considering, for non-textured worlds?

Edit - added more items, 12:08, 12:13.

[cfmdobbie]

I've just a question (it's not the good place to ask it but I don't want to make a specific thread for it) : when will be released the full 0.9 version ? because it still an alpha release...

0.9 is the "full" 0.9 version.  The "Alpha" designation has been used for all releases so far because the API is still subject to change.  "Alpha" will go away by 1.0.  (Oh, and ignore the "pre-0.9" version string - that's a typo!)

[oNyx]

Sounds pretty nice so far.

How big will these xmls be (in compressed form) compared to 3ds? (no big difference right?)

[Chman]

0.9 is the "full" 0.9 version.  The "Alpha" designation has been used for all releases so far because the API is still subject to change.  "Alpha" will go away by 1.0.  (Oh, and ignore the "pre-0.9" version string - that's a typo!)

Thanks Once again I asked a stupid question
Ok, so when do you plan to release the 1.0 ? lol I know that the 0.9 version has just been released, but I'm very *impatient*

Chman

[princec]

Is there a specified format for the material name, a URL for example, or is it a logical name that the app should understand?

No specific format - it's a string which identifies some other thing. Use a URL or whatever you like. The only thing it has to do is help whatever renderer you are using to determine how to draw the triangles. It could, for example, just be a colour "r,g,b,a", or it could be the name of a texture. The reference implementation renderer is going to use it to lookup something that is Renderable in a Map and call render() on it before drawing driangles.

It's not exactly how I like to see XML written - I prefer <bone> elements to be in a <bones> section etc, but that's personal preference.

I might add surrounding tags but they're almost redundant, and I so hate redundancy

Is it worth putting an id on repeated elements?  It'd be easier to use if the numbers used by e.g. triangle definitions are present in the file - not for the computer, but for the user.  You'd have to change things to not work on file order but on id number instead - probably not a big change.

No, not really worth it. The order of the elements in the XML file is significant, so why not use the implicit ordering? Besides - this XML is almost 100% certain to be machine generated anyway.

I don't know anything about bone animation - I trust that the system presented both works and will be implementable in many different modellers!  I've always seen bones described as having length, but I guess that's just a visual aid.

Neither do I Elias is hopefully going to help me here. A bone is apparently just a matrix which transforms a vertex. In the 3d modeller it will be represented probably with actual "bones" with length and so on, but when they are exported they just boil down to a matrix.

You have a bone count field, but not a vertex, triangle or animation count.  Why?

The bone count and vertex counts (there's a vertex count in cvs too) are used as sanity checks to check the triangle indicies and ensure that the animation frames and skin specify the correct number of elements. The triangle count need not be checked against anything so it's not specified.

What is the timing information - specified units or application-interpreted?

Application-interpreted floats. So probably "seconds" to most apps.

Do you have updated XML fragments for us?  I don't see any examples in CVS.

Later tonight.

Loader.loadBone(): if you're making m3* optional, shouldn't you make m*3 optional as well?

You need to learn more maths The last row in the matrix should pretty much always be 0,0,0,1 or some really freaky things happen. That's why they're optional, and if not specified, default to 0,0,0,1. The right hand column, on the other hand, specifies a translation.

Might vertex colours be worth considering, for non-textured worlds?

I considered it and then thought - no-one ever uses vertex colours in a real game! Leastways, not specified in the actual model data. But seeing as you've asked for them, I'll add them in the skin as optional data.

Note that the model provides for no animation of texture coordinates, nor will it provide for animation of colours, nor will it provide compound models. Although I have some ideas to create a compound model class.

Here's what I will do tonight then:

1. Wrap tags around the data sets to make Charlie happy

2. Create 2 example XML files

3. Play Morrowind a bit more.

4. Add colours.

5. Play Morrowind a bit more.

6. Do a little bit more on the simple Renderer implementation

Cas

[princec]

If we get some help on the Mac port, documentation, examples, and util code, we'll get 1.0 out for JavaOne. Otherwise it might be some time in the summer...

The util packages are independent of the releases.

Would anybody like to volunteer to write some exporters to the LWJGL XML model format? Or converters?

Cas

[cfmdobbie]

The bone count and vertex counts (there's a vertex count in cvs too) are used as sanity checks [...]

Hmm.  I'm rather tempted to say that that's the loader's problem, not the data file.  An element count is easy to do from the loader side, so putting the value in the data as well adds little.  *shrug*

You need to learn more maths The last row in the matrix should pretty much always be 0,0,0,1 or some really freaky things happen. That's why they're optional, and if not specified, default to 0,0,0,1. The right hand column, on the other hand, specifies a translation.

Ah, heh.  Yep, absolutely right.  Totally the wrong end of the stick.  Move along...

I considered it and then thought - no-one ever uses vertex colours in a real game! Leastways, not specified in the actual model data. But seeing as you've asked for them, I'll add them in the skin as optional data.

Cheers!

1. Wrap tags around the data sets to make Charlie happy

Ooh, no.  It's your baby, don't change something like that because of one comment.

3. Play Morrowind a bit more.
5. Play Morrowind a bit more.

An excellent choice!

[tom]

I considered it and then thought - no-one ever uses vertex colours in a real game!

Maybe not on animated geometry like skinned meshes. But static meshes that don't move can use vertex colors for lighting. In quake3 vertex colors is used instead of lightmaps on some meshes. Is this a general format or only designed for animations?

Is the format going to support multiple sets of texture coords. Is nice to have when you wan't to add normal maps and other shader data.

How big will these xmls be (in compressed form) compared to 3ds? (no big difference right?)

I'm guessing it's going to be a bit bigger than a 3ds file. The uncompressed files will be huge and slow to parse compared to a binary file. If you wan't to use it in a game I suggest you convert it into a binary format first.

[tom]

Btw. I did something similar a couple of years ago. Made a maya script that exported skeleton animation to a text file. Also had a importer and java 3d viewer.

I could try modifying it to confirm to your xml format. It is slow as hell though. Takes several minutes to export 100 frames of animation

I might take a look at it when you get the viewer up.

[ap_kelly]

Check out my post in Game News regarding the announcement of a universal 3d file format.

Hopefully in the future we'll only need one loader!

Andy.

[princec]

Hah! A likely story. I live in the present, and right now, we've already got a file format that works after just a couple evenings' work!

Loads more stuff checked in last night, awaiting comment.

Cas

[blahblahblahh]

I might add surrounding tags but they're almost redundant, and I so hate redundancy

Technically, yes.

However, it's a practical issue; fire up an XML editor for a file with 100 identical tags (different contents) e.g. 100 bones. Then try a file that organizes all the bones into a "bones" tag and see the difference .

If XML editors were a LOT better and implemented intelligent heuristic-based folding (i.e. implying a "bones" tag where none existed) this wouldn't be necessary. But they're still a long way off.

[princec]

blah^3 is right, it'll be a pain to open the files in an editor if I don't put some tags around the groups.

Cas

[Orangy Tang]

Assuming I can recover my HD data, and assuming I'm still sane, I can probably whip up a Milkshape->XML file converter without a problem when I get some free time.

[princec]

Cheers, but I'd worry about recovering your final year project first if I were you...

Cas

[cfmdobbie]

Have you got any example XML files yet?  I can't see them in CVS, but may be looking in the wrong place...

The loader and model format look fine to me, but the actual data in the XML file is what drives everything.  That's the bit that I like to see!

Is this is going to eventually reside in a supplementary lwjgl_util.jar, not in the main distro?

[Matzon]

Is this is going to eventually reside in a supplementary lwjgl_util.jar, not in the main distro?

afaik, it will go in a lwjgl_util.jar package, but will in the main binary distribution.

[cfmdobbie]

Just a thought - how about a "static" model type, in addition to "bones" ("boned"?) and "meshed"?  No animation section, just:

1   2   3   4   5   6   7   8   9   10

<model material="arbitrary_name" type="static">   <vertices>     <vertex x="0.0f" y="0.0f" z="0.0f" u="1.0f" v="1.0f" nx="0.0f" ny="0.0f" nz="1.0f"/>     ...   </vertices>   <triangles>     <triangle a="0" b="1" c="2" />     ...   </triangles> </model>

Seems silly to require either a single frame with noop bones or a one-frame mesh, just to get a model that doesn't have any animation - animated models are the exception rather than the norm, aren't they?

If this is worth considering, maybe it's time to bite the bullet and turn this into three separate documents - model-static, model-boned and model-meshed.  You can then use tightly-defined DTDs, as the document structure won't depend on the value of a CDATA field.

If you like the single-root approach, maybe model could support a single child element, either meshed, boned or static, which then contains the relevant data?


A second thought - face normals as an alternative to vertex normals.  Cuts down on duplicated <vertex> elements, if your normals are constant on each face.  Not valid for meshed models, of course!


A third thought - maybe we should run with what we've got for now and see where it goes, then worry about a "2.0" after stimulating some interest and getting more than a handful of people's requirements?

[blahblahblahh]

You can then use tightly-defined DTDs, as the document structure won't depend on the value of a CDATA field.

Cas quoted a DTD too. Is there any reason why it can't use schemas, which are so much easier to understand ?

[cfmdobbie]

Cas quoted a DTD too.

Yes, but the "tightly defined" bit is the important one.  There's no way in a DTD to specify that models with a type of "meshed" don't define vertex elements inside a vertices element, but inside frame elements, for instance.

Is there any reason why it can't use schemas, which are so much easier to understand ?

DTDs are pretty damn easy to understand!  But a little inflexible...

Not played with Schemas much myself.  Aren't they a little overengineered for this kind of thing?  Great for ensuring that character data is in the correct format, but that's what NumberFormatExceptions are for, hey?