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
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).]
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 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.)
> 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…
