At 12:23 PM -0800 2/9/06, Jeff Quan wrote:
The morph code is simple:
1. The vector difference is calculated between target poses,
2. multiplied by a percentage, and
3. added to the current trimesh in the RB3Dspace (this is done for
both vertices and their normals).
You can't interpolate the normals that way; at a minimum, you'd need
to normalize the normals, but I'm not sure that they would be right
even then. Try that first, and if it's still not working, then you
may need to recalculate the normals from first principles (e.g., by
averaging the normals of all triangles it's involved in, and then
normalizing) on each frame.
If there's some more efficient trick I've forgotten, I bet that Frank
or somebody else will chime in.
The target poses were generated in Meshwork from the exact same
file, so I hope that there isn't a problem with vertices being saved
at different locations in a Trimesh's vertex list or having
different triangle lists.
No, Meshwork is guaranteed to spit out exactly the same model, except
for the vertex positions, when all you've done is change the pose.
The only way I can get it to work correctly is to set
RenderBackFaces=True, which seems more work than necessary. It
appears to me as if the triangle normals aren't updating. Is there a
way to do this?
Hmm. Aha. Oh dear.
Are you seeing triangles actually disappear on some frames? If so,
then that implies that it's the triangle normals that are wrong, not
the vertex normals (as you just said). I'm hoping that's not what it
is, though, because I don't think you have any access to those --
they're usually computed internally.
But if it's not the triangle normals, then I can't imagine what
RenderBackFaces would have to do with it. On the other hand, we have
morphing models in Renegades (e.g. the boss bot at the end), where we
twiddle the vertex positions and normals, and that seems to work
fine, without worrying about triangle normals. So I wonder what's
different about what you're doing?
I suppose the best next step, if simply normalizing the interpolated
normals doesn't solve it, would be to try to reproduce the problem in
a simple example. If you can do that, I'll look at it, and maybe we
can drag Frank into it too, and I bet we can come up with a solution.
Best,
- Joe
--
Joseph J. Strout
joe at strout dot net
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|