Support bone joint scale

[zturtleman]

Support bone joint scale

[m-7761]

Foreword: Please read the next post for corrections on this paragraph. A problem faced by this is MM3D's way is to use global coordinates, which I think is actually pretty user-friendly. As a result it doesn't really matter what a joints rotation values say since they're just numbers... I mean the only purpose they serve is to keep track of what the previous rotation was in the Properties panel.

I have a sense that just naively adding nonuniform Scale (which I guess I'm doing right now) will be inadequate. It will work, but it won't be as cut-and-dry as adding it to the points, which have fins. It will be very sensitive to the initial condition of the joint. drawJoints doesn't consider it. The unanimated rotation might need to impact it, but it's global, so that probably doesn't make sense.

Does MD5 assume anything like Z is lengthwise? My sense is Joints will require a new single scalar property that defines a twist around the bone's axis to use as a coordinate system. If so I'm not sure what the twist is relative too other than the math itself. It would have to factored into the final matrix somehow whenever scale is involved.

[m-7761]

Foreword: Sorry about the DELETED post I made in case it got into your inbox.

EDITED: I think now my previous post is incorrect.

I thought I did tests that showed the rotations were global. Admittedly it's kind of hard to work with Maverick because manually inputting values into Rotation is difficult. I assume it works like mine (I haven't broken anything) in which case I can see the rotations aren't global (maybe they should be?)

It's hard to say what they're local to however. I fear it's the worst of all worlds... not global, but not meaningfully relative to anything either. Other than the math.

You linked to this c010973 change "Add bone joint rotation to properties panel in non-animation mode " that I assume must be in my release of Maverick because I can see the Rotate field.

I feel like either the Rotate field should be expressed in global angles, or we need to figure out a more intuitive local representation. The former makes some sense as points and vertices are in global coordinates.

Anyway, I don't want to hijack this issue further.

[m-7761]

Okay, this worries me (a lot) so I've thought about it some. Here is my feeling...

1. I think that (though this is how hierarchical animation works) the bone+joint representation isn't a good one, but I don't want to mess with it either, and I feel like it looks fine in terms of simplicity sake. The problems I see with it is the lines between the bones very much suggest the rotation planes should lie along them. But I don't have a better idea really, maybe someday.

2. I feel like the current state of the Rotate tool doing global rotations but the Properties showing local rotations doesn't make any sense. There is no relationship between the two. You can't use the property to fine tune a change made with the Rotate tool. That's what I feel like should be default. So I feel that it should use global values, ideally lossless ones, but if not, well so be it.

3. Outside of animation mode rotation doesn't actually matter. But it's still a useful transformation option. Probably nothing that can be done about it. Maybe if global rotation is lossy then rotation can be stored differently.

4. The Rotate tool can have two or three different modes. That way the Rotation property can sit tight in the sidebar. Switching modes can show different values in the rotation property. Maybe even it could store rotation as a quaternion really and make that available to change in any representation... but that's not my meaning of "modes"...

By modes I mean, mode (1) can be global. (2) can be local, with a different pivot representation that shows the local axes of rotation. Mode (3) can change the axes. That mode is critical to being able to use nonuniform scaling. If you can't control that then you just have a crap shoot of frustration...

In this way MM3D doesn't have to render the axes like it does for the point objects. I think rendering the axes on skeletons would not look as nice. I think points might look better rendered more like sphere projections by default, and show their axes likewise with the Rotate tool.

Then the Scale tool can likewise show the axes, and maybe it should put the Rotation property into axes mode so you can freely edit it while working the Scale tool, even though you must do it with the sidebar. If you can mouse-wheel the sidebar inputs or use tickers that's pretty easy to do. Something I've added for the 3 scale inputs is holding Shift to drive all of the scale components at once. It's a simple solution that mirrors a feature I've added to pan/rotate/zoom all of the views by holding Shift. (Sometimes rotating all is annoying since it throws all of the top/right/front views into Ortho mode... but I haven't decided on what to do about it.)

[m-7761]

Update:

Current translation is absolute.
Current rotation is relative.
Current scale is?

I'm going to go with relative (local) because it's easier to implement, but absolute (global) seems like it might be more intuitive for scale than rotation.

I think this is a problem that needs a solution. The post before this one has a more ambitious plan to make local/global representation user controllable.

[m-7761]

Update:

I think leaving the Scale in properties to be relative is likely most useful for points and joints, since joints are mostly relative and the Scale property of points should probably correspond to the fins' sizes.

I've implemented this with the scale-tool, but it's not very user-friendly because it works in terms of absolute coordinates like all of the tools do, so the result is it can be very counterintuitive when the axes aren't aligned with the viewport.

Manipulating the properties directly is more intuitive. The current release of Maverick I have doesn't really support direct manipulation. Mine can do it easily, but it generates a lot of undo steps. There should be some kind of timeout resolution solution for rapid undo events.