Misc : A return to 3d Studio 3ds files

[tgraupmann]

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.

http://tgraupmann.hypermart.net/3danimation/debug_cyborg4.jpg

The lower leg and foot are now moving together. Can you see why the upper leg and lower leg aren't pivoting together?

[tgraupmann]

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???

[Ls3D]

Woah,..

I got a headache just looking at this post!

So you have asnwered you own question and all is good in 3D land.

-Shea
www.Ls3D.com

:applause:

[EricChadwick]

Hmm, have you tried posting on the Discreet Sparks forum? It would seem to be most logical place for these queries, since it is the official SDK forum.

BTW, the 3ds format is ancient, IMO not well designed, and certainly not well documented. You may have better luck with one the other major formats, like OBJ or FBX or MDL or VRML.

[tgraupmann]

Actually yes, I've made posts in the discreet forum. But your right, the 3ds format is ancient and I doubt anyone is still left over from Autodesk @ Discreet who has any faint idea about the format of .3ds files.

What would be the fun in switching to another format, huh? Besides, I'm nearly complete. The 3ds loader I'm working on can support 50+ of the DarkBasic/DarkMatter models that use a linked object hierarchy.

The reason I post on an artists forum, is to try to get an idea about what the expected behavior should be when objects are linked. Like should they move together or independently. Should a child inherit the animation keys of their parent or not. Questions like that.

I'll be making a community post in a short while that will include my source code that supports loading the .3ds format.

[EricChadwick]

Hmm. In your first post you talk about a difference in hierarchical animation between a Grouped parent and an Object parent. Visually in 3ds max there is no difference between the two. A Group in max is basically just linking one or more objects to a dummy (the group is the dummy).

So the behavior is the same. In a traditional forward-kinematic hierarchy, children are translated by the animation applied to their parents.

Vertices have nothing to do with it, unless there's a particular type of controller added to an object, like for example the Surface Constraint.

However pivots do. The parent rotates/scales about its pivot, and if the children have their own r/s keys then they do so about their own pivots.

Hope that helps.

[tgraupmann]

Originally posted by posm

The parent rotates/scales about its pivot, and if the children have their own r/s keys then they do so about their own pivots.



... about their own pivots.

Let's ellaborate on that.

If children have their own /r/s keys then aren't their parents r/s keys applied first, followed by their own r/s?

So in what cases are the traslations of the apparents applied in this logic?

[EricChadwick]

In a forward-kinematic hierarchy, with no special controllers or locks applied, the translations of a parent are always applied to all of its children. Optionally, children can have their own translations, but these are always applied in addition to the parent's translation.

When I flex my bicep, my forearm and hand are pulled towards me. I can flip someone off while I do so, but my hand is still pulled inwards by my bicep, regardless of what the middle finger is up to.

[tgraupmann]

Special controllers
Locks

Please explain these. What are they?

[EricChadwick]

Awww, man. Read the help file. I only have so much time in life...

getting older... getting older... :drool:

[tgraupmann]

Which help file are you referring to? Where can I download it? I don't have it already.

[EricChadwick]

Oh, thought you had 3ds max. It has an extensive help file.

Here's some stuff from the file...
I hope this isn't violating my user agreement.

==========
Locks Rollout

Make a selection. > Hierarchy panel > Link Info button > Locks rollout
The Locks rollout contains controls that prevent transforms along particular axes.
X, Y, Z—Turn on any axis in the Move, Rotate, or Scale group box to lock the axis. For example, if Rotate > X and Y are turned on, you'll be able to rotate the object only around the Z axis. All locks are relative to an object's local coordinate system.
==========
Inherit Rollout

Make a selection. > Hierarchy panel > Link Info button > Inherit rollout
The Inherit rollout constrains the links between a selected object and its parent for any axis of position, rotation, or scale.
X, Y, Z—Turn off any axis in the Move, Rotate, or Scale group boxes to prevent inheritance.
When you turn on an axis, transform information passes from the parent to the child for that axis. When you turn off an axis, transform information on that axis is ignored by the child.
==========
Animation Constraints

Animation constraints are used to help automate the animation process. They can be used to control an object’s position, rotation, or scale through a binding relationship with another object.
A constraint requires one object and at least one target object. The target imposes specific limits on the constrained object.
For example, if you want to quickly animate an airplane flying a predefined path, you could use a path constraint to restrict the airplane’s motion to a spline path.
The constraint’s binding relationship with its targets can be animated on or off over a period of time.

Common uses for constraints:
Linking one object to another over a period of time, such as a character’s hand picking up a baseball bat
Linking an object’s position or rotation to one or several objects
Keeping an object’s position between two or more objects
Constraining an object along a path or between multiple paths
Constraining an object along a surface
Making an object point toward another object’s pivot point
Controlling the “look at” direction of a character’s eyes
Keeping an object’s orientation in relation to another

There are seven types of constraints:
Attachment constraint attaches an object’s position to a face on another object
Surface constraint restricts an object’s position along the surface of another object
Path constraint restricts an object’s movement along a path
Position constraint causes the constrained object to follow the position of another object
Link constraint links the constrained object from one object to another
Look-At constraint constrains an object’s orientation so that it’s always looking at another object
Orientation constraint causes the rotation of the constrained object to follow the rotation of another object

Using Constraints with Bones
Constraints can be applied to bones as long as an IK controller is not controlling the bones. If the bones have an assigned IK controller, you can only constrain the root of the hierarchy or chain.
==========
PRJ and 3DS Files

PRJ is the 3D Studio R4 (for DOS) project-file format and 3DS is the 3D Studio R4 mesh-file format. You can import both these types of files into the software (as well as DXF and SHP files). You can export 3DS files (and DXF files).

The following rules determine what is exported to the 3DS format:
Position, Rotation, and Scale animation. If the controller is a TCB controller, the TCB, Ease In, and Ease Out values are also saved. If the controller is any other type of key controller, the keys are saved but the tangent information is lost. If the controller is not a key controller, only the object's transformation at frame 0 is saved.
Basic material color/parameters from the Standard material.
Single maps with their amount, offsets, scales, etc.
Composite and procedural maps don't export.
Auto-cubics and Mirrors export.
UV mapping coordinates can be exported.
UV mapping coordinates are exported if the toggle Preserve MAX's Texture Coordinates is turned on in the Export Scene to .3DS File dialog. See Exporting to 3DS.
A vertex in a 3DS file can have only one texture coordinate. If a vertex in the 3ds max file has multiple mapping coordinates, it is split into multiple 3DS vertices on export, to preserve the mapping.
Grouped object transformations don't export to the 3D Editor because there's no concept of group hierarchy in the 3D Editor. Groups do export to the Keyframer because the Keyframer understands hierarchies.
Target cameras, target spotlights and omni lights.
Most "static" parameters for cameras and lights, and animation tracks for Roll, Falloff, Hotspot, and FOV are exported. Global shadow parameters are not exported.
All non-mesh geometry, such as procedural primitives and patches, are collapsed to meshes before export.
Objects are exported as they exist on the frame that displays at export time. If you want to output morph targets, go to each frame and export the target to a different file name.
Meshes are saved with edge display information and smoothing groups.
Instances are saved as Keyframer instances.
Modifier and morph animation is frozen at the current frame, collapsed, and exported as a simple mesh.
==========

[tgraupmann]

This is very helpful thank you. I definitely earn a degree of difficulty that is caused by not owning a $3000 copy of 3d Studio Max. I have been using purchased and free models to test with, for fun.

:banghead:

[tgraupmann]

Great News! http://www.gametutorials.com posted my 3ds animation source code. You know what this means. Beta tests are on. Test your models and send me bugs reports. Download the source here: http://www.gametutorials.com/download/CodeDump/3DSAnimation2_MOD.tar.gz.

-Tim Graupmann
tgraupmann@yahoo.com
http://tgraupmann.hypermart.net

[tgraupmann]

2003-05-12 Ported to Linux/GLX.

Additionally, I figured out how to read lock information from the keyframer.

[EricChadwick]

It sounds like you're not getting many people to send their models. I would guess it's because 3ds is such an unloved format.

Verts cannot have more than one UV. Doesn't support deformable skin via bones (well it does support morphs, but they tie up the bus bandwidth whereas bones do not). All bitmaps must be named in 8.3. Etc.

It is probably a good format for you to learn, since it can be so difficult and quirky, forcing you to come to grips with it. But serious game developers don't use it anymore, too many limitations.

You might have better luck with one of the other 3d game formats like Quake or Unreal. Not sure about the open source issues though.

[tgraupmann]

I'm thinking for my next phase, I'll make the application read 3ds files and convert to .md2 or .md3 on the fly.

I don't like limitations that's for sure.

I'm using the 3ds format as an educational tool.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.