RE: [Plib-devel] [Fwd: Model / 3D Object format that is easy to use, yet powerful? (fwd)]

[Dave M. <dp...@ef...>]

> Having worked on a couple projects that made extensive use of the .ASE
> format, I personally wouldn't choose to use that format for anything
again.
>
actual mileage may differ
i've also worked on a couple projects that made extensive use of the
.ASE format and i've been able to easily get what i need:
- vertex coordinates
- vertex colours
- texture mapping coordinates
- transform animation (absolute position,relative quats for rotation,and
scale vectors)
- mesh animation (just another definition of the mesh. could be used for
LOD. worked nicely on a shark i had to bend back and forth)
- object names
- parent heirarchy
- material properties (amb,diff,spec,shine,transparency,sub
materials,tiling,offset,textures)
sheesh. what more can you ask for?

> The problems we ran into mainly stemmed from the fact that
> the .ase exporter is just a sample plugin, and wasn't intended as a real
> file format.  As such, it is ridden with bugs, and completely unsupported.
>
perhaps, but you get the source code with the MAX SDK and the ASE exporter
works very well.  haven't encounted many bugs

> Anyways, here are the main problems we ran into:
> 1) transformations - .ase has the transformations stored in a full matrix,
>    plus the components of the matrix (rotation, scale, etc.)
>    which just happen to not match up.
>    (One of them is just totally wrong - and I don't remember which)>
>
there is a NODE_TM for each object which has a 4x4 matrix. i ignore it.
the transformation keys (TM_ANIMATION) are not stored as 4x4 matricies.

> 2) no documentation - there are several completely unintuitive things
>    about the 3ds max architecture that you become exposed to but using
.ase.
>    For example:
>    2a) normals - normals are sometimes in world space, and sometimes in
object space,
>        and the space they're in is determined by whether they're being
animated,
>        whether their parent transforms are being animated, etc.
>
the normals do seem odd.  i ignore them.  i only needed face normals which
are easy enough to compute.  i suppose you could compute vertex normals too.

>    2b) ignore rotation flags - there are a couple flags on each matrix
>        that specify whether or not to inherit its parent's
rotation/scale/translation,
>        which is awkward for the programmer, albeit useful for the artist.
>        The problem is, the flag means exactly the opposite of what it's
named.
>        (inheritRotation true -> don't inherit parent's rotation)
>
thanks for the tip.  i'm currently implementing parent heirarchy with
animation now.

> 3) animation - keyframes for mesh animation and transform animation aren't
> sync'ed, so if you have an animation with both, you need to untransform
all the
> mesh animations at each transform animation keyframes, which requires you
to exactly
> mimic the interpolation going on within max - which isn't trivial for TCB
> interpolated quaternions. ;)
>    (We were able to do this last only after bugging the developers for
their
> 3dsmax TCB interpolation code - Ugh - most of the comments in the batch of
10
> files were commented out code, and the one classic: "However, I
> think this code is incorrect.")
>
in the ASE dialog window, you can tell max to force a sample every frame so
it should be easy to mimic transform animation.  also, in the case of mesh
and transform animation, you could just do the mesh animation and put the
transform animation on a skeleton and link them together.  that is how i've
seen it done (ie: bones)

> I might suggest the .obj file format,
> for which there are free exporters available from max,
> although, of course, it won't export animation or skeletons.
> It's trivial to read, but again, it's probably not
> as fully functional as you may need.
>
yes.  obj is very nice and clean.  glTron uses obj format.
no animation or vertex colours -- ouch!

> The best alternative is, given the time and motivation,
> is to write a plugin that exports the data you want,
> but even this isn't foolproof, given the bug in max
> that causes IK to be unavailable to any plugin.
>
who wants to write a plugin?
perhaps a hack to the ASE "sample" plugin to fix bugs would be useful.
the best alternative to that is to use ASE with work-arounds.
ASE is the most complete and flexible ascii format that MAX exports
i'm sticking with ASE.

> Oops, my coworked just corrected my list of problems.
> The normals problem is actually part of a larger one:
>
> transforms and vertices are in global space,
> normals are usually in local space, unless they're below a space warp,
> (which isn't written into the .ase file, so there's no way to know this)
> in which case they're also in global space.
>
> mesh keyframes are in local space,
> transformation keyframes are in global space,
> and rotational transformation keyframes are in global space,
> but every keyframe except the first is a relative keyframe.
> (all other keyframes (mesh and non-rotational transformation) are
absolute.
>
i would agree except that i have found mesh keyframes to be in global space.
so... everything except normals is in global space.

> So, I'd suggest using .obj (and .mtl) if you can,
> and if not, seriously consider spending the time
> writing a 3dsmax plugin. (or a Maya plugin, or whatever)
>
yes. if your requirements are simple then use .obj (and .mtl)
otherwise, stick with .ase since it is the best thing around
short of writing your own 3dsmax plugin (yuck!).

besides, any plugin of your own design would just be
yet another format to upgrade and fix when 3ds decides
to upgrade max.  at best, it would be as good as .ase
with a few bug fixes.  just send a patch to 3ds for the
"sample" .ase code in the SDK.

-- Dave McClurg
dav...@dy...