@177
Elites: 219
 |
|
GFX Forums > Skills and Techniques [ST] > A return to 3d Studio 3ds files
Back to forum overview
Back to topics
1 
| A return to 3d Studio 3ds files |
|
|---|---|
 tgraupmann | 04/15/2003 @841
|  edit post
|
|
With all the information at: http://lib3ds.sourceforge.net http://www.wotsit.org http://www.gametutorials.com/Tutorials/opengl/OpenGL_Pg5.htm http://www.gametutorials.com/forum/topic.asp?TOPIC_ID=5281 I can't find any information on the object track hierachy. Does anyone know how the animation tracks should be applied to a child object when the parent is an object? Applying parent to child was straightforward when the parent is a group and the child is an object because you just apply the position, rotation, and scale tracks from the group to the object. But what do you do if the parent is an object and the child is an object? Does that even make sense (how could an object be a parent)? The only thing I can think of is that by having a parent object you get the effect that the objects are linked. In that case what should be done? Find a common vertex between the two and pivot on that? Any ideas? |
| Re: A return to 3d Studio 3ds files |
|
|---|---|
|
tgraupmann | 04/19/2003 @859
| edit post
|
|
|
Here is a better way to look at the problem: The green sphere at the bottom is 0,0,0 for each object. All objects have a common 0,0,0 apparently? The red spheres are each objects vertex[0] point.  The lower leg and foot are now moving together. Can you see why the upper leg and lower leg aren't pivoting together? |
| Re: A return to 3d Studio 3ds files |
|
|---|---|
|
tgraupmann | 04/30/2003 @291
| edit post
|
|
|
The solution *IS* for this model: Read the position keys, but skip subtracting position[0] and the pivot from each vertex. After the hierarchy is read, search for linked object hierarchies (any object that has a parent object). Subtract position[0] and the pivot from each vertex for all objects the lack parents. Don't do this for linked objects or groups. Call animate model recursively, so that the upper most parent is animated first working downward from parent to child until the node being displayed is animated. The animated routine is a little different. If a linked object is detected then operate using the following conditions: { - If a node lacks a parent, translate by vertex[1]. - If a node has a parent, and its parent lacks a parent, translate by vertex[last]. - If a node has a parent, and its parent has a parent, translate by vertex[1]. } If the node is not a group, translate by position[x]. Scale by master scale. Rotate by rotation[x]. If a linked object was detected then operate using the following conditions: { - If a node lacks a parent, translate by -vertex[1]. - If a node has a parent, and its parent lacks a parent, translate by -vertex[last]. - If a node has a parent, and its parent has a parent, translate by -vertex[1]. } And that's all the is to it. Now the strange part is that depending on the model the logic changes. To display the DarkBasic H-Hound model, it uses the following conditions { - If a node lacks a parent, translate by -vertex[1]. - If a node has a parent, and its parent lacks a parent, translate by -vertex[1]. - If a node has a parent, and its parent has a parent, translate by -vertex[1]. } The only thing that makes these models different is the number of verteces in the nodes that this logic is applied to. Would it be correct to switch between the two implementations of this logic depending on the number of verteces in each node? Here is some info about the two models: H-Cyborg ====== LF_Thigh: 39 verteces LF_Calf: 44 verteces LF_Foot: 38 verteces H-Hound ======= LF_Thigh: 28 verteces LF_Calf: 24 verteces LF_Foot: 12 verteces So the number of verteces is different, is this cause enough to vary the animation algorithm??? |
View profile
Visit website
