PDA

View Full Version : Introducing the AME Ascii Model Export file format (plug)



Morglum
01-12-2003, 02:43 PM
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).]

jwatte
01-13-2003, 03:14 PM
Please take this as constructive criticism based on what I've found useful in my own exporters :-)

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.

Morglum
01-14-2003, 02:03 AM
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).]

Morglum
01-14-2003, 02:11 AM
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.

kieranatwork
01-14-2003, 05:08 AM
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.

Morglum
01-14-2003, 05:14 AM
what ?! Half-life, the game than ran on a 200mhz machine ?! are you sure of this ?

Ysaneya
01-14-2003, 06:05 AM
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.

Morglum
01-14-2003, 08:34 AM
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.

Diapolo
01-14-2003, 10:24 AM
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 Ive got here http://www.opengl.org/discussion_boards/ubb/smile.gif.

Diapolo

jwatte
01-14-2003, 11:08 AM
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.

Ysaneya
01-15-2003, 12:25 AM
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.

Morglum
01-15-2003, 12:40 AM
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' http://www.opengl.org/discussion_boards/ubb/wink.gif

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.

Morglum
01-15-2003, 12:44 AM
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.

Morglum
01-15-2003, 12:46 AM
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).]

Ysaneya
01-15-2003, 03:20 AM
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.

Morglum
01-15-2003, 10:27 AM
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

Morglum
01-15-2003, 10:29 AM
Originally posted by Morglum:
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.

this question remains open...

Ysaneya
01-16-2003, 12:42 AM
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.

jwatte
01-16-2003, 07:38 PM
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

Morglum
01-17-2003, 12:50 AM
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).]

jwatte
01-17-2003, 09:14 AM
Yes, the orthonormal basis is a little bit redundant. But it's usually better to do all that computation once, at export time, than having to do it everytime you load a model.

Oh, and you should split out vertices based on texture coordinates and smoothing groups, too, if you don't already. Another one of those things that should be done in the exporter, once, rather than everytime you load. I think you currently just dump the Max smoothing group and texture triangle information, which means that the model isn't usable without more post-processing.

The algorithm for bounding sphere is fairly well publicized, so writing your own implementation should be a matter of turning text into code :-)

Morglum
01-17-2003, 12:23 PM
thank you jwatte and Ysaneya and kieranatwork for this discussion; I think I know enough now.

Anyway this is an ascii format, so it is not usable for final distribution (too large files) ... so anyway there will be postprocessing, this is inherent to ascii export.

Further, sorting entries is philosophically opposite to the idea of a parser, don't you think so ?

For bounding spheres : it annoys me a bit to copy from gpled code into proprietary software... so that will be done in the postprocessing.

For tangent bases : i'll make them an option of the ascii export

I'll rewrite the whole thing starting from bsenftner's code... so there will be all his cool features like vertex weights. And of course, what was originally my motivation for that stuff, there will be matrix samples for every objects, and no more affine decompositions at all... and the documentation.


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

bsenftner
01-18-2003, 11:03 AM
A bit of history on the ASE problem with normals...

My first version of the "Fixed ASE Exporter" was for Max 2.5. Back then the exporter requested vertex normals from the mesh and wrote those out. Which is fine if your mesh only had one smoothing group. But of your mesh has multiple smoothing groups, then the exporter needs to request the vertex normals from the FACES not the MESH. So I added that to the original ASE exporter... But I noticed that I was getting different shading from my OpenGL renderer than what I saw inside the workspace, preview and render views of MAX. (I also noticed that those three views in MAX did not match either...)

After some mucking about I was able to recreate the correct vertex normals inside my game code (since I needed to recalculate normals when skinned meshes deformed).

So I left the vertex normal logic inside the Fixed ASE Exporter as the version that should have been correct for the final MAX renderer (unique normals for each vertex according to that face's smoothing group.) I emailed discreet with this fix and never heard from them. Later on (MAX 3 or 4, I forget) I noticed that the ASE exporter that shipped with MAX contained the corrected vertex normal logic.

If anyone needs information or tips on working with the ASE exporter or the exporter's source, they can access the email link off my www.PopDigitalTech.com (http://www.PopDigitalTech.com) website.

(For what it's worth, Ive found that working with the animation keys is much simpler than working with animation samples. The memory consumption is much, much lower and the representation lends itself to animation blending.)

Morglum
01-18-2003, 11:32 AM
so that explains the whole stuff about normals. thanx!

jwatte
01-18-2003, 04:22 PM
I needed to recalculate normals when skinned meshes deformed


Why wouldn't you just skin the normals with the same code as you skin the position (minus the translation part)? Did you use scale in your animations?

bsenftner
01-20-2003, 09:10 AM
> Why wouldn't you just skin the normals with the same code as you skin the position (minus the translation part)? Did you use scale in your animations?

Good point. I'm not writing that logic anymore, I would expect that is probably how it is done by now. At the time (two companies back) the logic just tracked which face normals to average and recomputed...

FWIW, our animations consisted of rotations only, except the character's root xform. The root xform was the only one that contained translation animation. Anyway... that's a different topic...