Ya, that's what the angle limit does but of course you'll need to
know the original angle limit for this to be useful, and not all
normal generating algorithms are equal, so the depending on how the
originals were made you may see differences. Also keep in mind that
the transforms in 3DMF Workshop always work around an origin of
0,0,0 (hmmm, just like Quaternion.Transform) so you'll need to
translate the vertexes back to their proper location. Depending on
how you're data is setup, you may need to translate to 0,0,0 first
as well. So on second thought, Quaternion.Transform might work just
fine, combined with one or two translations as needed... sorry for
the confusion!
Well that's how objects are stored (with origin 0,0,0). So if I grab
a vertex data from a Quesa object, that point will always be relative
to the origin. Adding rb's Object3D.position to a vertex's position
should give the correct world position.
So it looks like all you do is:
- Multiply by scale value
- Rotate it around the origin (with the stored yaw and pitch values;
yaw first then pitch)
- Add the position stored in RB's position property
It looks like it works now. Thanks.
That's correct - the only time you need to recalculate normals from
scratch is when the relative angles of the faces change, as they
would for a non-uniform scale or deformations that involve vertex
animation. I suppose I could do this for certain operations in 3DMF
workshop as well, but it just feels "safer" to recreate them from
scratch (plus I don't have to keep the original normals around). In
a real-time app I'd definitely avoid recalculating normals whenever
possible however...
Great! I was afraid of losing the existing vertex normals.
_______________________________________________
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>
|