Introducing the AME Ascii Model Export file format (plug)

I’ve fixed a variant of the ASE file format, which I’ve called the AME format. It’s only for isolated models, not scenes (the S in ASE). Although not thoroughly different, I think it has interesting features, among which :

  1. rather extensive documentation

  2. very easy-to-read, bug-free animations

  3. other bugfixes and improvements taken from bsenftner’s corrected ASE exporter.

The AME home page is here : http://www.eleves.ens.fr/home/jacob/ame.html

I would like to see your comments, if anyone is interested.

EDIT
Silly me - I forgot to mention that a AME plugin for 3ds max5 is available from the AME homepage (source & binary).

[This message has been edited by Morglum (edited 01-13-2003).]

Please take this as constructive criticism based on what I’ve found useful in my own exporters :slight_smile:

I looked at your documentation. I think you’re wrong in saying normals in 3dsmax are redundant, as users can edit normals so they’re different from the defaults; at least in newer versions of 3dsmax (this may have been missing in version 3).

I also think that a good exporter should export tangent bases for each texture channel, at least as an option. That’s really useful information to have in a model file format.

Last, for animations to be really meaningful on skinned meshes, you’d have to export the bone assignments and weights for each bone for each vertex in the mesh.

It’s also useful to have control about what gets exported and not by using user props, or naming convetions, or both.

thanks jwatte for your feedback.

For the normals, ok, I’ll make them available as an option.
EDIT
as soon as someone solves the bug about normal vectors in the ase exporter. I just can’t see in the source what’s wrong, but the output sure is.
RE-EDIT
as mentionned below, i’ve found the bug in the ase exporter sources.

For ‘tangent bases’, I’m very sorry, but I don’t know what you’re talking about. Colud you please elaborate ?

[This message has been edited by Morglum (edited 01-14-2003).]

[This message has been edited by Morglum (edited 01-14-2003).]

Concerning skinned meshes :
does anyone care anyway ? I’m considering not supporting them at all. They’re too slow to render on nowadays hardware… the rendering code is damn complicated too… i have no idea what it looks like, and in how many years it’ll be feasible in real-time.

Skinned meshes are too slow to render?
Skeletal animation is too futuristic for you?
Tell that to the makers of half life 4 years ago.

what ?! Half-life, the game than ran on a 200mhz machine ?! are you sure of this ?

I agree with the tangent space thing, that’s one important thing missing from the current ASE format. On the other hand i never experienced any problem with the normals.

And yeah, skinned meshes are pretty standard now…

Y.

ok I didn’t know for skinned meshes… i’ll look into it. thanks for mentionning it.

for normals, it’s not very difficult to see bugs… the most easily reproductible (but not the most annoying) is at the poles of a sphere.
by thinking about it, I think i’ve found the bug in the ase exporter, so there’ll probably be normals in ame.

for ‘the tangent space thing’… could you please be more explicit ? I really dunno what you’re talking about.

Originally posted by Morglum:
what ?! Half-life, the game than ran on a 200mhz machine ?! are you sure of this ?

HL had a Skeletal Animation System!
I read that on the old HL Box, that I´ve got here .

Diapolo

Half Life used a skeletal animation system where each vertex was weighted 100% to a single joint. It’s better than a poke in the eye with a sharp stick, and runs pretty fast on a Pentium 200 and up.

More modern systems use more joint/weight pairs per vertex, to make it look better. Depending on how many characters you want to put on screen; how complex they each are; and what your minimum spec is (CPU + frame rate); this may range from 2 to 8 or so.

(technical specs about There avatar skinning deleted)

For systems that can assume vertex program support in hardware, pushing the skeletal pose and skinning to the card can give you nice parallelism, and you can easily do three or four weight/index pairs per vert, all in hardware. Although on GF3 level cards, you might not be able to fit your entire skeleton into the set of available registers, and thus have to split it in a few pieces.

A tangent base is what you use to transform a normal read out of a normal map into object space, so that you can do per-pixel lighting calculations. Basically, it consists of your normal, plus two more vectors (tangent and binormal) which tell you in what direction the texture’s S and T coordinates grow, in model space. Thus, a tangent base is a per-vertex 3x3 rotation matrix, expressed as three basis vectors.

for normals, it’s not very difficult to see bugs… the most easily reproductible (but not the most annoying) is at the poles of a sphere.

I’m sorry to say this, but i’ve been working on complex, static scenes with the ASE format for some time now, and i never experienced any problem with the normals. Including spheres.

Are you 100% sure there is a bug ? How does it appear ? Do you have a max and an ase file demonstrating this ?

Y.

For skeletal anim : thank you, I’ve got it. I’ve seen that bsenftner’s ase exporter had it, so i’ll simply copy-paste… anyway bsenftner is already in my ‘aboutbox’

For tangent bases, i’ve also got it, thanks jwatte. just one question : what happens if the texcoords have been modified by the artist ? Can I ignore it ?

And can you confirm that such a base has not to be orthogonal ? I mean, the s and t directions have not to. So the term ‘binormal’ is a bit worrying me. And also the fact that you told that it was a ‘rotation’ matrix. (which implies that the 3 vectors are orthogonal). I’m a bit confused here.

Ysaneya,

i think you can reproduce the bug by just drawing a not-too-highly tesselated sphere, exporting it to ase and having a look at the poles.

I’m not 100% sure of what i’ve said above about the sphere (i can’t test it at home, i don’t have 3dsmax of course) but i’m 100% sure that there is a bug with normal vectors somewhere and by seeing the code I suspect that a sphere could be wrongly exported. And I have already seen ill-exported spheres.

[This message has been edited by Morglum (edited 01-15-2003).]

I exported a sphere and displayed the normals in green:
http://www.fl-tw.com/opengl/aseNormals.jpg

I still don’t see any problem…

Y.

looks fine, you’re right…

I’ve looked into the code again, and it looks fine…
i don’t understand why there are so many people claiming there are wrong normals then… and why i was certain to have myself… see http://www.solosnake.fsnet.co.uk/main/app/dlase.htm

Originally posted by Morglum:
[b]For tangent bases, i’ve also got it, thanks jwatte. just one question : what happens if the texcoords have been modified by the artist ? Can I ignore it ?

And can you confirm that such a base has not to be orthogonal ? I mean, the s and t directions have not to. So the term ‘binormal’ is a bit worrying me. And also the fact that you told that it was a ‘rotation’ matrix. (which implies that the 3 vectors are orthogonal). I’m a bit confused here.[/b]

this question remains open…

i don’t understand why there are so many people claiming there are wrong normals then… and why i was certain to have myself… see http://www.solosnake.fsnet.co.uk/main/app/dlase.htm

They’re speaking of a bug in boolean operations. I did a few tests with them and didn’t see any problem either, but i must admit most of my work scenes are not using boolean operations, so i might as well haven’t met it. If it’s a “rare” bug…

Y.

Morglum,

You have to use the texture coordinates as modified by your artists.

You have to orthonormalize the basis before you can use it; the most convenient place to do that would be in the exporter. To orthonormalize something based on Normal, S_Vector and T_Vector, do something like this:

T_Norm = normalize( Normal X S_Vector )
S_Norm = T_Norm X Normal

So must I compute S_vector from the texcoords ? I agree that this is easy, but isn’t it a redundant information then ?

PS : would bounding spheres for each object be a useful addition ? I’ve got a good GPLed code for bounding spheres and i was wondering whether it was possible to use it together with the maxsdk, which is proprietary software.

[This message has been edited by Morglum (edited 01-17-2003).]