View Full Version : ASE texture coord clarification please.
12-15-2000, 01:49 PM
This post is for someone who has succesfully parsed the ASE format (including texture coordinates) for loading models in OpenGL.
I've got my ASE loader reading in and using the texture coords provided in my ASE format. This all works just fine. I'm having a little trouble interpreting where exactly the material id index is stored (So I can determine what texture to use at the right time).
I thought it was here:
*MESH_FACE 0: A: 0 B: 14 C: 8 AB: 1 BC: 1 CA: 0 *MESH_SMOOTHING 1 *MESH_MTLID 1
I use the last part *MESH_MTLID as the number of the index in my texture array (in this case it would be 1).
This works just fine for some objects. However, when I export certain objects this number is way too high (I opened the ASE file to look for problems).
In other words, lets say I build a model in max that uses 3 different textures. When I export the model, the *MESH_MTLID number will sometimes range from 0 to 10 instead of what it should be (0 to 2 for 3 textures).
So when my loader reads this value it tries to load textures from an array index that isn't even there or it maps the wrong picture at the wrong place...
Does all this make sense?
Could this be an exporting issue? Some models work just fine...others don't. Anyone have a suggestion?
Don't know what *MESH_MTLID is, but I think you should use *MATERIAL_REF as material reference instead. It's located in the end of each mesh desciptor.
12-17-2000, 10:23 AM
I have never looked at the ASE format, but could it be possible that the MESH_MTLID is returning MAX's ID for the material? For instance if you have a scene with 3 materials/textures and you are using the materials numbered 2, 4, 10 from the MAX Material browser, could it be using those instead of 0-2?
Anyway, just a thought.
the meaning of the MESH_MTLID token changes with the context of a material.
MESH_MTLID and MATERIAL_REF must come always toghether, since this couple can identify uniquely any material.
suppose you built a cube in MAX.
you convert it to a mesh, then you assign a material to the whole mesh.
the exporte .ase will hold 1 material and one mesh, and the material reference of the mesh will be 0.
in this case, the MESH_MTLID token will be PROBABLY equal to 0, but it don't care since you don't have to take it into account.
each face in the mesh is of material 0.
now, suppose you modify your cube, by selecting some faces and assigning to them another material.
the .ase will then contain 1 material WITH 2 SUBMATERIALS, and then the MTLID token will be significant, since it will index the submaterial.
not that at this point, the material assigned to the object in max has changed from standard to multi/submaterial.
so, to recap, the MATERIAL_REF token identifies the material, and the MESH_MTLID token identifies the submaterial.
i think this is your problem now, since when i had to consider materials when parsing .ase files, i had to face this too.
Hi dmy !
Well, although I did *not* fully implement the submaterials in ASE files, I did a bit of research on them and came to the same conclusion as you...
But this morning, when reading this thread, I thought: "OK, let's implement it now!". Then, I had the idea of creating a cube with a simple material and export it (actually the idea you explain here !)...
The result is not 0 for all MESH_MTLID (as you and I would have thought) !!!! Actually, it goes from 0 to 5 depending on the face...
Well, as you said, they are useless for a cube but what that means is that if your count of sub-materials in the material is less than what MESH_MTLID says, you should ignore MESH_MTLID ! Otherwise, crashes are not too far !!!!
Just thought I would mention that....
12-18-2000, 09:31 AM
Thank you all for responding. I may be missing the answer to my problem. Perhaps it's the way I am exporting my models.
For instance, if I export a simple cube, my MESH_MTLID number will range from 0 to 5 and my Material_Ref will be 0. Well, in this case I could ignore all numbers other that 1 minus the the number of materials (which would be 1 - 1 or 0 in this case).
When I build my models, I do all that I am going to do to all parts, then I apply an "edit mesh" modifier to one peice. I then "attach list" to all of the other peices of my model. o my model is one unit only. When I export my model all my faces, tvert, vertices, etc.. are in one group.
This "seems" to solve the problem. Each part will have a unique MESH_MTLID. If I had three boxes (each with a different texture), then each box would have a different number for all faces in the box. (I have a list of 0's, then a list of 1's, then a list of 2's).
But it does not work for a simple anything (One item by itself).
So what do you think? Is this the answer? Or did I miss the punchline?
the fact is that MATERIAL_REF is up one level of hierarchy than MESH_MTLID.
something like, to say, materials are directories, submaterials are subdirectories.
MATERIAL_REF selects a material, wich may contain or not submaterials.
MESH_MTLID selects the submaterial, and only this.
so, if the material indexed by MATERIAL_REF does not contain submaterials, then MESH_MTLID is meaningless, and the object's faces are all made of MATERIAL_REF material.
otherwise, if the material has submaterials, then in this case MESH_MTLID becames important, and every face in the object is made of submaterials.
so, if MATERIAL_REF material has submaterials, it won't be used anywhere.
it seemed to me that in MAX any mesh object is of one material (specified by MATERIAL_REF) and if you set some faces of the mesh to be of a different material, the mesh is STILL made out of a single material, but the material has changed from standard to multi/sub.
MAX meshes are not face-oriented (as one probably could think in the first place) but still object-oriented...
i implemented all this thoughts into a .ase scene loader class: it loads all the scene, without the need of merging into a single object all objects.
materials are treated perfectly so far, and i tested it with various objects downloaded from 3Dcafe.
it is a redesign of a previous parser, wich had problems with materials... actually it don't store texture coordinates since it don't know those tokens.
the structure is all there.
i'll publish the sources and a demo on the web.
let me reorder things a bit...
ace_man, can you send me the .max file wich, when exported, behaves the way you found and told in your first post?
eric: hi man, maybe there's a connection between our minds: are you a member of the borg collectivity?
[This message has been edited by dmy (edited 12-19-2000).]
[This message has been edited by dmy (edited 12-19-2000).]
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.