Search

[Katazuro]

Hello,
I've had trouble overall with using the helper dummy bones that the SMD importer utilizes. I'm using a decompiled HL2 human biped skeleton and have had no issues fitting the skeleton to a new mesh, but I've hit a wall when it came to fitting the fingers to the skeleton.

I want to rotate the main finger bone (Finger0) so that it "reaches" in a different direction but retain its distance from the hand bone:


But when I go to do this, it rotates the desired bone in a strange manner:


Ideally I want it to rotate the way the move tool does it, but it moves the entire bone hand hierarchy:


tl;dr I am very confused on how to get the desired effect that rotating standard 3ds max bones have:

[wallworm]

Welcome to the WW forums :)

I'm a little confused about the issues. The images aren't self-explanatory to me.

There isn't anything special about the bones. They are simply BoneGeometry() nodes, like those you can make via the Max create tab. Because they are part of a hierarchy, moving the child node inherently forces the parent to rotate to look at the child. And any transforms to a parent automatically translate to a child.

There are a couple things to help manipulating bones easier:

1) Change the current Coordinate System in the main toolbar to Parent. This will align the transform gizmo to the object's parent coordinate system, which is usually what you want when animating bones.

2) For easier set of bones in a hierarchy, open the Max Bone Tools floater in Animation > Bone Tools and then click the Bone Edit Mode: this will allow you to move a child bone without limitations.

3) Enable the Axis Constraints Snap option if your transforms go in more axis than you expect.

I'm not sure this solves the issue, but I have a feeling that they will help you.

[Katazuro]

Hey Shawn,

Thanks for the speedy response!

I've experimented with your suggestions and I understand I might have been a little vague. Your suggestions are extremely helpful though; these are things I never knew.
But to clarify: in the last image, the standard 3ds max bone rotates where the WWMT bone's parent would be at. Ideally I want the parent bone (for the bones that WWMT uses) to carry along all its children.

The non-helper-dummy bones seem to behave differently. I'll do my best to describe this because I'm not so great at explaining

The bone "Finger0" is the first segment of the finger in the hand. The root/origin of the Finger0 bone using the non-helper bones would be where the hand node is (of the WWMT bones), shown in the last image. The root/origin of the bone nodes in WWMT's helper bones are at the very end of where the non-helper bones would be at, pretty much the opposite end.

[wallworm]

I've been out all day working on a car, so my brain is a little sluggish. So I'm not 100% certain about the issue, but I think I understand. It may be the way that these bones are being displayed.

Here is a function to take any current selection of bones and make them display in the format you might expect:

Code Select Expand



function wallworm_set_bone_display length:1 width:1 height:1 bns:selection = (
for bn in (selection as array) WHERE classof bn == BoneGeometry do (
bn.showLinks = off
bn.showLinksOnly = off
bn.width = width
bn.height = height
bn.length = length
)
)


Execute that code in the MAXScript listener then select all the bones and execute this in the MAXScript listener:

Code Select Expand

wallworm_set_bone_display()

Now the bones will not show links back to their parent bones and probably look more like you are used to. I will update the importer to use this method with the length matching that you'd get if making the bones manually. If I'm understanding your clarification, this is the confusion. Of course, maybe I'm still tired and not grasping it entirely.

Unrelated but for reference: There are still some problems with the SMD importer relating to animated models... if the sequence SMD is missing a bone in a hierarchy that is defined in the main model, the bone missing from the sequence SMD will be thrown off in the sequences missing it. It's something to be aware of. At this point, you can either remove those sequences from the QC importing them, or manually fix those sequences after import.

[Katazuro]

Thank you Shawn, this is exactly what I needed. There is no rush, I totally understand your business!

For your understanding, yes, the script you provided addresses  the confusion. I am looking forward to seeing the implementation into the importer with the proper length displayed, it will be very useful. :)

It may be trivial to tell you and that I might sound very picky, I apologize, but the bone format used in the importer currently has been very confusing to work with (before you wrote up that script) and slightly discouraged me from migrating from Max 2012 + the Cannonfodder tools. I had no option since Max 2012's plethora of issues put a stop to my work.

I don't want to come off as rude and urge you to implement that function immediately, but it's been a very big issue for me so far. I very much hope to see it put in the tools, WWMT has been very helpful.

Thank you for your time, Shawn.

[wallworm]

Well, basically, the issue at hand is that this is a little more complex than it sounds. I can make the bone display as solid easy enough, but chose to use the native SHOWLINKS setting on the bones because it is a native function in Max that calculates immediately. When you create a bone chain manually, the length of each bone is forced by the fact that you have only one child bone possible during creation--which makes the length easy.

With the importer, the length is not actually something that can be automated in logical fashion. The reason is that any bone can have an arbitrary number of child bones--and they could be at any position and distance. What that means is that which child to point at and use as the length of a bone is arbitrary. The easiest programmatically is to pick the first child... but this could be just as confusing visually as any other method unless the first bone happens to be aligned to the bone's current axis.

The other issue is that the original bones might not be aligned to a child. This again creates a problem for forcing an alignment and length based on that. This is, again, another reason I chose to use the native showLinks function.

I may only be able to show the geometry and not add the visual length display because of this. Until I figure out the best logic for it, I will have to leave it up to the user to just use the script above and update the display if needed. If you paste it into the MAXScript Editor and then select it all, you can drag it to your toolbar to make it a button. EDIT: To make a button, you need the function AND the function call to work as a button (so both sections of code above).

[Katazuro]

Thanks again, the button made it a million times easier.

Excuse me as I don't know much about scripting in Max works, but regardless of the number of child bones, couldn't the bones be created one after another instead of all at once? (Starting from the parent)

Afaik, I might be wrong, but I believe this is how Cannonfodder's importer worked.

[wallworm]

Well the bones and their orientations should be defined in the SMD files, so the direction should generally be fine. The problem is the length. Think of a hand, for example. The parent (wrist) has five children (fingers). Which one determines the length of the wrist bone? The hand isn't so challenging because the fingers are all close in distance. But not all models and bone systems are going to be structured like that. What about an alien hand where two fingers start three inches from the wrist but two more fingers start 6 inches away, and a fifth starts a foot away? In that case, you cannot assume that starting at the parent you can choose the length by going to the child because you have so many children to choose from. So even if Cannonfodder's make a length you expect, it is still arbitrary because of this scenario. The easiest thing is to pick the first child (or to make the bone fire out a ray and calculate which bone is closest to the axis of the bone... but that is extra calculations that can be slow).

And because the only thing that actually matters about a bone is it's pivot, I think it's not as important as it might seem. In any event, I'll try to think of the best solution and release an update after some of my other WW Pro updates going on right now.

[wallworm]

The updated importer now displays the bones as solid elements. I chose to keep the links to parents visible, but I think that the newest display will be much more to your satisfaction.