On 9-Feb-06, at 4:02 PM, Joseph J. Strout wrote:
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.
I was under the impression you could get away with using a weighted
average of the normals and not even bother normalizing the result -
there may be minor errors but they should be "normalized enough" (I
admit I haven't done this in a while though).
One thing to note is that for morph animation your vertex normals
must be totally "smoothed" for each frame. That is, they need to be
calculated as the average of all the facet normals of the faces using
vertex, and not exclude faces beyond a certain angle (as would be
done to get sharp seams). So if Meshwork is using an angle limit of
some sort you may have calculate new normals as a pre-processing step
- or change the limit to 0 in Meshwork (if that's possible). The
problem here is that different poses will have different seams, and
result in different numbers of vertexes.
The only way I can get it to work correctly is to set
RenderBackFaces=True
That's odd (?) but I have seen problems with Quesa's internal normal
generation which may be affecting your model somehow. For example, if
Meshwork lets Quesa generate the normals and then regurgitates them
into the 3DMF file then you'll likely get errors, but they may not be
obvious when viewing single frames. Here again the solution would be
to calculate your own normals as a pre-processing step.
As a test, try grabbing RB3D Utility <http://www.miensoftware.com/
files/rb3dutility.zip>, import a frame or two and run the optimize
and generate normals commands (omitting an angle limit). If there's a
visual difference from the original model then the normals were
either not totally smoothed, or they may have been created by Quesa
(and possibly contained errors).
However unlikely, this could also be caused by you're normals not
actually making it to Quesa at all (somehow?), and it's then forced
to generate its own normals each frame - which again, might contain
errors.
Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––
_______________________________________________
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>
|