View Full Version : ASE File

helda

01-10-2003, 01:26 AM

Hello guys,

I have a problem with the ASE Format. I need informations, about *NODE_TM, i can't imagine what this should say to me. I hope someone can explain me this.

Thank you for reply

helda

It contains the transformation information.

helda

01-10-2003, 02:21 AM

I need more details because i don't know how to use this information on my Vertex coordinates, on my faces and normals.

Morglum

01-10-2003, 02:51 AM

it contains information about how the object is to be transformed. The data is stored twice : once as a matrix, and once in affine decomposition. But be careful : due to a nasty bug in the ASE exporter, only the matrix is guaranteed to be valid. So you have only to read TM_ROWx, where x=0,1,2,3.

it gives you the modelview (mv) matrix to pass to glMultMatrixd.

here's how it's stored :

TM_ROW0 mv[0] mv[1] mv[2]

TM_ROW1 mv[4] mv[5] mv[6]

TM_ROW2 mv[8] mv[9] mv[10]

TM_ROW3 mv[12] mv[13] mv[4]

note that the 4 remaining coeffs are not written because they are always the same :

mv[3]=mv[7]=mv[11]=0

mv[15]=1

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

I didn't know about that bug.

Am I correct in saying that ASE files already have the transformations applied to the vertices? - the file actually contains the world coords rather than the local coords. I seem to remember this was the case for an ascii format exported from MAX.

Morglum

01-10-2003, 03:06 AM

yes that's right. (at least for the standard ase exporter that comes with 3dsmax).

The bug appears when an object has been applied a 'mirror symmetry' (or whatsoever it's being called in 3dsmax).

This transformation is of determinant -1, which, in affine decomposition, can only be obtained by using negative scale factors (since rotations have always det=1). But 3dsmax still exports positive scale factors, which is wrong. That results in objects that are displayed upside down.

***EDIT***

this last statement is false of course.

The correct statement is :

That results in objects that are displayed with normal vectors upside down.

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

helda

01-10-2003, 03:07 AM

that means, when i want to draw my triangles i must do the following:

glPushMatrix()

load the exportet matrix;

draw the Szene

glPopMatrix()

helda

Morglum

01-10-2003, 03:13 AM

exactly.

careful, as said above, the vertices are already transformed. So you have to transform them back before doing that : or else the transfo will be applied twice. For that you invert the matrix, and you multiply the vecs by the inverted matrix.

Morglum

01-10-2003, 03:16 AM

a simpler option (valid only if you don't have anims) is to apply the matrix directly to the normals. Then you're done.

helda

01-10-2003, 03:19 AM

Thank you i think this will help me!

helda

Morglum

01-10-2003, 03:29 AM

hehe I remember I was exactly in your situation 1 year ago. These hints were given to me by Eric...

by the way i'm developing a variant of the ASE format (which I call AME like ascii model export) which is especially fit for single models (no cameras, no lights).

It would be bug free and would have animations stored in matrix form (hence easy to read, as opposed to ASE's inextricable pos+rot+scale).

If anyone is interested, I can already give the 3dsmax .AME exporter.

I'm now working on a .AME loader that would convert .AME into a real, usable format (which would include strippified, state-sorted geometry).

helda

01-10-2003, 04:34 AM

Yes i'm very intrested, because it won't do as it should!

helda

helda

01-10-2003, 04:52 AM

first i want to do the easier solution, i want to apply the matrix to the normal.

i make it like this

glPushMatrix();

glMultMatrixf(transformation);

glNormal3f(..,..,..)

glPopMatrix()

i do this for every normal, but it had no effect.

helda

Processing only occurs with a call to glVertex (or a similar command that begins vertex processing). Modifying and then restoring the matrix without first calling glVertex will have no effect.

helda

01-10-2003, 05:10 AM

How will it then be possible?

helda

Morglum

01-10-2003, 05:15 AM

Just compute directly, without ogl calls,

matrix * normal.

Here is the rule to multiply a matrix by a vector :

newvector [i] = mat [i] * oldvector [0] + mat [i+4] * oldvector [1] + mat [i+8] * oldvector [2] + mat [i+12] * oldvector [3];

PS i'll upload the .AME exporter ASAP. But I first have to write the documentation, or it's useless.

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

helda

01-13-2003, 12:27 AM

sorry, i hope this is my last question.

How must i handle the ROW3? in the moment i have a 4x4 Matrix and a vector with 3 elements(normal). And what is exactly in this row of the matrix?

helda

Morglum

01-13-2003, 12:34 AM

good question !

you've got a 4x4-matrix m4 and a 3-vector v3, so that doesn't fit.

Answer :

float v4 [4];

v4[0] = v3[0];

v4[1] = v3[1];

v4[2] = v3[2];

v4[3] = 1.0; //add new 4th component equal to 1.0

v4 = m4 * v4; //do the multiplication

v3[0] = v4[0] / v4[3]; //retrieve the multiplied v3

v3[1] = v4[1] / v4[3];

v3[2] = v4[2] / v4[3];

hope that helps

PS this time you can have the AME plugin + doc. I've posted a thread on this forum.

Morglum

01-13-2003, 12:36 AM

This 'row' of the matrix (in fact it should have been named a column) represents the position, ie, it's a vector by which you translate your object.

The translation is implicitly being done in the matrix multiplication.

helda

01-13-2003, 01:07 AM

I think this is OK! but when i do this, my sphere looks like a disc. And the Illumination of the sphere is in all driangles the same.

I have done it before with the 3x3 Matrix (row 0,1,2) and this looks better. But there when i have test it with a cube, there are only 2 sides in light.

helda

Morglum

01-13-2003, 03:09 AM

yes !

I had forgotten that you were transforming normal vectors, and not vertices ! So you must not apply the translation to them, so the 3x3 matrix is what you need !

That's fine : apply only the 3x3 matrix obtained from TM_ROW0,1,2 to the normal vectors. TM_ROW3 has nothing to do with normal vectors : it's only for vertices.

>But there when i have test it with a cube, there are only 2 sides in light.

this is not necessarily a bug, that depends of where you place your light. have you tried other positions/directions for your light ?

helda

01-13-2003, 03:53 AM

I have found my bug, i have make a mistake by reading the transformation. Now it is correct.

Thank you for all.

helda

What I do when loading an ASE file is invert the given Matrix and apply it to the vertices. Then I get them in local coords. When displaying, I use glLoadMatrix and issue the glNormal/glVertex with the values I get (i.e. for the normals, straight from the ASE and for the vertices, the ones obtained after the multiplication described above).

If you do not want to transform vertices back to local coords but instead apply the matrix to the normals, I think there is one thing you should read:

http://ask.ii.uib.no/ebt-bin/nph-dweb/dy...html;pt=37451#X (http://ask.ii.uib.no/ebt-bin/nph-dweb/dynaweb/SGI_Developer/OpenGL_PG/@Generic__BookTextView/37451;cs=fullhtml;pt=37451#X)

This basically explains that normals are transformed by the inverse transpose of the transformation that transforms vertices.

Hence, I am wondering whether you'd get the proper result if you multiplied the normals by the matrix given in the ASE file...

Regards,

Eric

P.S.: Morglum, I tried to find a link to these hints you mentioned. If I remember correctly, I sent them to you by e-mail after I flamed you for posting a question about "sscanf". I found this topic and had quite a good laugh http://www.opengl.org/discussion_boards/ubb/wink.gif !

Morglum

01-13-2003, 07:13 AM

I know what you're talking about http://www.opengl.org/discussion_boards/ubb/wink.gif

Also thanks for the interesting link. Interesting to see that the concept of a tangent plane to a surface is more appropriate to do lighting computations than the concept of a normal vector. I'm sure that CG is going to absorb more and more riemannian geometry.

Powered by vBulletin® Version 4.2.3 Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.