3DS Max BVH Exporter beta8

I got a little side-tracked for a while with Fourier transforms. And a few other things.

I got to playing with QAvimator today. I was all like, "Man, working exclusively in gimbal sucks. I wish I had other spaces for those funky angles that I just can't easily get with gimbal. Wait... I got my 3DS Max thing."

So I whipped out 3DS Max and got to playing with my BVH exporter. I had been playing with MaxScript intermittenly so I could get the feel for how it deals with rotations and quats. Thankfully all of it finally started to gel together when I started digging in again.

(I can learn pretty much any programming or scripting language fairly quickly, but nuances can really suck.)

Did a lot of playing around and settled on a different plan of attack.

The basic idea is to create a temporary object to hold the rotations. Do a few things to it, then output the rotations.

Load the beta8 template scene, do junk to it, and run the beta8 script.

- Seems to work dandy with FK as is.

- Also seems to work dandy with IK and other tricks, but bake the trajectories first! However, there doesn't seem to be a need to delete IK after baking. Just bake and export.

- I'm pretty sure I got the hips right this time in both position and rotation.

- Legs fixed from what I've tested. In the old script, the legs were seriously messed up.

- Hierarchy is inconsequencial, so you shouldn't have to worry about that all. The temporary box created to hold the rotations handles this regardless of the hierarchy of the skeleton and rig.

- FPS is no longer fixed. It should change with the parameters in Max. However, the initial T-pose is still hardcoded and the FPS might be off by a notch. Shouldn't cause any visual differences, or you can hack the BVH post-output if you feel the need. I'll fix this one of these days with an option on output.

That's about all I can think of right now.

I haven't done much testing at all, but it's really looking good so far.

Rigging tricks and curves. Woohoo!

My brain needs a break. Maybe in a week or two I'll start looking to hack a rig with actual bone objects. If I get the gumption, I might even try to hack Mr. Comet's rig. Or whatever.

Oh man. Two quick little notes.

I did IK on the legs and left the feet FK. Seems to make the feet want to rotate differently than what the gizmo is telling you. If you change the rotation of the feet to XYZ, should be good. IK and non-XYZ don't seem to want to play nice, but still looks okay so far.

SL doesn't like the output straight out of Max. I ran some output through QAvimator and SL took that just fine. And it looked good.

Now I'm gearing up for a real acid test. Some custom fitted two-handed spear animations for my jungle boy avatar. If I can pull this off, it's so gonna rock.

Hi Abu Nasu,

Thanks for this! I hope you iron it all out....will take a look at it soon...

I looked soooo long for something like this, but due to the asinine fact that these forums won't let you search for three letter words (like 3ds , max, or bvh) I wasn't able to discover whether anything already existed and had started working on my own

This is cool Abu, thanks for sharing! I still want to do my own just as a learning experience, but it's very cool to have one already made. I'll send you any feedback I can after I get to play with it a bit.

Nice one! I just quickly tested this out and it looks good so far.

I set up a quick rig with IK on one side, linked the legs and arms to the bones, and did a little animation test. I used Martin Breidt's collapse script (mbCollapse.ms <http://www.breidt.net/scripts/index.html#mbCollapse> to bake the animations (and your bvh script naturally) and then checked it in Qavimatior.

No flipping or weird rotation offsets! Woo hoo! When I get some time I'll set up a full rig and take it for a walk and see what happens. This looks promising though.

Thanks Abu!

Okay, I think I figured out how to make it SL friendly straight out of the export. I think one of the problems was type-casting. Why does type-casting have to be so weird in MS? Quite a few things in MS are weird. Once again, those nuances.

If you want to fix the bulk of the type-casting yourself, just tack on 'as float' at the end of every rotation line.

na = in coordsys gimbal mybox.rotation.x_rotation as float
nb = in coordsys gimbal mybox.rotation.z_rotation as float
nc = in coordsys gimbal mybox.rotation.y_rotation as float

I did try to explicitly type-cast floats, but that didn't seem to work.

One funny thing I noticed is that I forgot the \n at the very end. If you look at the script, you will see a bunch of comments reminding me not to forget the \n. Guess what? I forget. Heh.

At the end of '--rfoot', add the \n right before the closing quote like so:

format "% % % \n" na nb nc to:output_file -- don't forget \n

See the comment reminding me not to forget? Argh!

With both of those fixes, export should be pretty close to SL friendly. If you don't feel like doing those yourself, here is beta8b. Please beer in mind that I haven't checked the newer output to see if it is SL friendly.

I've started looking into VisualMS. If it works the way I think it does, the next incarnation should have some options. For example, Open on Export and T-Pose First Frame. Maybe frame ranges and zeroing the hips (pos and/or rot).

Not too shabby for a first MS project. Why, I've managed to impress myself.

Seems like I had a few other things to toss out, but they escape me right now. So, I'm off to tear into VMS.

edit:

Okay, I just successfully uploaded a BVH straight out of Max to beta grid using beta8b.
Coolios.

That rocks

I've got a great deal of it fingered out. Have a little floater with roll-outs and stuff. I know what I need to know and it's just a matter of cobbling.

However, there are a few things that I'm kind of wrestling with.

One thing is an option to position the hips to zero throughout the animation. I vaguely remember someone saying that hip.pos=(0,0,0) does make a difference when layering gesture type stuff. Does zeroing the hips to (0,0,0) make a difference? If it does, what is the difference?

Another thing I'm wrestling with is Not Zero (!Zero) as mentioned by Dave Bellman. It's something that I have been thinking about, but Dave beat me to the punch so it's !Zero as he calls it. Which is really cool because I honestly don't know what I would call it. I would have probably come up with something not so cool sounding like Almost Zero But Not Quite. Heh.

Anyways, I'm not sure how to implement !Zero. Should !Zero be global or joint-by-joint? I'm thinking global option, but I'm not entirely sure about the implications either way.

Thoughts?

I'm gonna think out loud for a few minutes.

It all started when I made my first studio. I did a few poses. The biggest problem I was having was that I was forgetting the neck, wrists, and ankles. Strange appendage fits ruining an otherwise perfectly good shot.

Turns out that those joints were getting dropped due to not having a rotation. The zero rotation meant that those joints were free to move around from lower priority animations.

Go back, toss in a small rotation value, upload again, and all is well. No more headspaz.

With the reading that I've done since I've been looking into my own animations, it seems to me that frame drop seems to happen on a per frame basis. If a rotation value is small enough, it is disregarded. The tolerance seems to be small enough to be largely unnoticable, but sometimes they do seem to cause a problem.

Let's say that the tolerance value is 5. That is, a rotation value of 5 is completely ignored. This adds up over time because the rotations are offsets from the previous frame (relative).

Rotation series:
10, 8, 5, 7

SL ends up doing this:
10, 8, 0, 7

The 5 got dropped. Over time, those fives can add up considerably.

But this seems to cause a problem with subtle movement in a hurry.

So, what I'm thinking is, keep those dropped values and eventually add them back in when the tolerance is exceded.

Rotation series:
10, 8, 5, 7

Becomes:
10, 8, 0, 13

Does that sound right? Will this possibly make animations a bit better?

That is an interesting idea... You can find the client source responsible for this to get at least a general idea of the "tolerances" that are used. As to whether it will work, I can't say, but it sounds well worth trying

If nothing else, perhaps you could create a log file (named the same as the bvh with a .log extension?) or in some other way notify the user when the exporter discovers that part of the animation is likely to be dropped by SL? Might at least save a few upload fees

.

Okay, I'm starting to rig this baby up. I'm building a bone based rig scaled to the rotation points of the template right now. After it's built I'll link the structure of Abu's rig to it. I'm sort of building it to my personal preferences at the moment.

I've got legs set to IK with a foot roll attribute right now. I plan on doing the arms so they can be IK FK switchable. I was originally going to do a spline based spine that isolated the orientation of the various body parts, but I realized that for SL animations it might be better to leave it as a FK setup so you have direct control over the rotations.

Does anyone have any requests for how to rig this up?

Abu, I'm not sure what zeroing the hips would do other than allow other animations to play regardless of the priority. I don't do enough SL animations to have a feel for when it would be beneficial to have your root joint be at the mercy of another animation than the one you are making. It's possible, no, likely that I don't fully understand what you are asking.

As to the rotation key dropping, does any of your reading indicate that the zeroing of rotations could cause lower priority animations to take over in the middle of a supposedly overriding animation? I've have a couple of animations I've done that start off fine then seemingly get usurped by other animation layers as they loop. Some keys that break the dropout threshold would be a very nice thing in this case.

Edit: upon further reflection I've decided to go back to a more pose based rig with isolated orientations. If folks want rotation by rotation based control they can use the basic template! duh.

Okay, I'm going to leave the hip.pos=[0,0,0] thing out for now.

And I'm going to leave the !Zero thing mostly alone for the time. I will put in checkboxes on a joint-by-joint basis, but going to leave the bigger problem alone. I do think that when an animated joint hits zero, animations in the lower priority does take over (even if briefly). There is a speed hack that I will eventually be implementing, which will also lay the ground work for a complete !Zero fix.

All because I was forgetting the neck, wrist, and ankle joints - my, how deep the rabbit hole has become.


Anything you do above and beyond is cool with me. If you do a complete FK/IK blend, I will be your bestest friend in the whole widest world forever an ever.

Just!
ugh...

Turns out that using a temporary object to hold rotations is a bad idea. The rotations eventually get out of control, which leads to more problems. Nothing like trying to implement !Z when rotations are well over 500. I did try several different fixes, but quat drift is too much for me to deal with.

Gonna go back to hosing the hierarchy.

I've already rewritten the rotation output code I couldn't tell you how many times. Now I have to do it all over again. Then hack in the options and hope I don't mess up the legs *yet* *again*. By the time I get to the legs, I'm rather cross-eyed every time.

But the good news is that I realized I'm an idiot. Was soaking in the tub with my feline (yes, he takes baths in the bathtub), and I realized that !Z is not what I was thinking it was. For some reason I was thinking that it was relative over time, when in fact it is only relative to the parent. OMG noob. What's the matter? Getting your dimensions mixed up again? No wonder rotations confuse you. Yeah yeah yeah.

So, the big question about !Z: is it by channel or by joint? I'm thinking by joint. If I'm wrong, then rewritting the rotation output code will be old hat by the time I get that far.

I adore coding to no end, but it sure can be frustrating. Grrr! Rawrrrr! But getting over the frustration with a few well placed epiphanies sure is grand. And no matter how daunting the tedium gets, the hours just fly by. It's gotta be true love. Gotta be.

Hopefully I'll be back tomorrow with a working v1.

Looks like I'm in for a world of hurt, then

I've been working on my own rig, just so I can learn about how such things are done, and I haven't even started trying to get rotation information yet. I've got IK/FK blending and snapping in place, and I think I've got something almost serviceable, but I didn't expect the rotations to be so difficult.

Well, keep at it, it's a great project and I'm sure that some people will really love the final result!!! I know I'm looking forward to hearing more of your progress


.

I don't really understand what you mean by the !Zero stuff, so maybe I'm misunderstanding the issue entirely, but does this help?

http://www.comet-cartoons.com/3dfiles/CometCartoons-zeroOut.mcr


.

Rotations are just the beginning. Gotta make sure your pivots are properly aligned and that you get the rots in the proper order. Rotation order XYZ is a far cry from ZXY. What will really mess with your head is that the rotation order listed in the BVH files is not the same as the rotation orders set in Max. And the real brain bender is that Max likes XYZ for IK and things. And that's not even getting into coord space. Gimbal? Parent? Ugh!

How do you change the rotation order without changing the solution? Quats. Well, sort of quats, but quats are at the heart of it.

Speaking of quats, the crazy rotations that I was getting earlier are all gone. I think this was just a case of pushing Max too hard for too long. I did a warm boot and everything was fine.

Now I'm having a hard time with how MaxScript does conditionals. But I could have a logic-bomb, which will be hard to find since I don't know much about how MS flows. Sometimes short-hand conditionals work and sometimes they don't. Did I scramble Max's brain like I suspect I did with the quats? Or did I do something in the code itself?

Then there is dealing with the IDE. Lost more than a few hours to the IDE. I was left patching together previous versions that I saved outside of my Max folders. Started saving outside of Max when I realized that the IDE does a few weird things.

Time to take a break. Maul things over and internalize.

But I am attaching Beta9b as a MacroScript. Drop it in UI/MacroScripts, fire up Max, and then hit Customize. You should be able to find it in Category: Second Life. Drop it in as a menu item or whatever.

Two really big things:

- Start Frame and End Frame are not error-checked. I still don't have a solid grip on how MS flows, so I'm not sure how to implement a check for this. If End Frame is lower than Start Frame, don't be surprised if Max does bad things.

- The !Zero checkboxes kind of work and kind of don't. Getting these to work is the fight that I'm having with conditionals. The way they are firing is just plain odd.


Speaking of !Zero...

!Zero is what Dave Bellman calls something that SL does so animations can be layered. Actually, it's what you do to prevent animations from layering. Something like that.

A simple example would be a 1 frame modeling pose with priority 4. Say you make one of these and upload it. Everything is fine, but then you suddenly get head spaz. What happened? You forgot to give the neck some rotation. Because the neck has no rotation, it is free to be influenced by other animations. The trick is to give the neck joint just enough rotation so that other animations won't get through. With just enough rotation, the neck will stay almost perfectly straight and you won't get head spaz.

I do a lot of such poses for my own uses. I'm notorious for forgetting the neck, wrist, and ankle joints.

Okay, break time for this jungle boy. Then maybe later I'll start the commotion.

Still working on a traditonal bone based rig. A project I thought was done at work actually had more stuff that had to be done, but no one bothered to tell us it was pending. Stupid work making me do work.

In the meantime I've attached the quicky Biped based rig I've cobbled together. This was done in Max 8, and should work in any version after that.

Right now it has planted keys on the hands and feet, so you can move the ctrl objects around and get IK like response, or you can just delete the keys and grab limbs and go at it FK like. The big ring around the middle is the root for the bip so you don't have to dig around for it buried in the hip or keep opening up the selection menu. The red square on the XY is the root for everything. All the controls are shapes so you can use the selection filter to pick them out quickly. I also highly recommend Jim Jagger's Biped Selector script from his JJTools download pack http://www.jimjagger.com/Pages/Tools/index.htm

Protips: The controls have their transforms and rotations frozen so you can Alt+Right Click and pick "transform to zero" or "rotation to zero" from the quad and they will go back to the default positions or rotations. There is also a copy collection with a default pose and a T pose for the biped. All hail copy pasta. The template, biped, and controls are on their own layers so you can quickly hide and unhide scene elements.

I've uploaded a couple of animations to SL based off of this and Abu's 8a script and done a quick walk-cycle that I checked in Qavimator and haven't seen any problems so far, but that's not nearly enough tests for me to call this production ready. Use at your own risk, I cannot be held responsible if it destroys your computer (it's Abu's fault anyway), void where prohibited. If someone uses this and sees any issues let me know! Thanks.

Here's a rig for Abu's template. Arms and legs are FK IK blendable. Controls are on the shoulders and hip controls as well as in the Parameter Collector under the Animation menu. Back is FK, but I isolated each segment's rotations.

Not much testing done on it yet. If you use it let me know how it worked or didn't for you.

Opened it in Max 8 and it's a thing of beauty. FK/IK blends on all limbs. Foot roll - woohoo!

I only played with it for a few minutes and it's going to take some time to get to know it, but I can definitely see myself using it. I have yet to test it with the BVH exporter script, but I will defintiely give it a work out in the next few days and let ya know how it goes.

Since the parts I made are mesh, feel free to manipulate the verts to make it a bit more friendly for your uses. As long as you leave the pivots alone, should be okay. I know I'll be doing a few vert tweaks to the torso.

This whole Not Zero thing has seriously exploded into something *much* bigger than I expected. When I'm done taking my break from scripting, I'm gonna hack out the !Zero stuff, but I'll definitely leave in all of the other options for layering reasons.

If we are lucky, we might end up with a post-BVH stand-alone that can do the optimization stuff on par with LL's own code.

Looking very very promising! I will try using/testing on my next production assignment. Will get back once done.

That was definitely a much needed break from all of this.

I'm calling Second Life-BVHExporter1a 'good enough'.

All I really did is strip out the Not Zero stuff from the last MS that I posted (NZ conundrum). I did some simple poses and a few short moving animations, and it looked good. Even the options that I threw in seem to be working okay. Although, I don't think that the Disable Preview option actually does anything. I remember reading somewhere that certain MaxScripts automatically disable the preview/updating and I think that MCR is one of them.

Pygora, I haven't tested Exporter1a thoroughly with your rig just yet. I'm still getting a bit used to your rig. For example, the FK on the arms doesn't seem to start at the collar and go all the way to the hands. Threw me off at first and no big deal to adjust working with. The one time that I did go to do a full anim test with your rig, I crashed, got discouraged, and went to do something else.

Pending anything going excessively bad, gonna go back to focusing on my sculptie stuff.

For a first MS project, it has been one frustrating and satisfying ride. Hopefully now I can finish some of the other projects that helped start all of this.

Wow, yet another update. Nice!

Thanks for the feedback. Yeah, I kept all the rotations on the torso (including the collar) isolated. The joints are not FK or IK. I appreciate that it must be a bit weird compared to FK torso animation setups most folks use for SL such as Qavimator and Poser, but the benefit is that if you need to go back and adjust something in the torso it won't completely throw off your pose up the links. Your arm will still be pointing that way and your head will still be looking over there. Good for the noodling of poses, but perhaps a bit of overkill for SL animations?

I plan on doing an update soonish. There's a couple of things that I need to redo. The company I work for got a SL development job so I can get paid to fix this sucka up. I'm on the fence about going to a straight spline spine or leaving it, but if I get community feedback one way or the other, that will be the deciding factor for me. Let me know if you would rather it be one way or the other if you (or anyone else) use it more.

Hi Abu,

I Just wanted to thank you for your efforts on this. I appreciate just how big a task this was (my brain hurts just thinking about it).

3DS Max's inability to play nice with SL was the main thing preventing me from buying it. Might be time for me to take the Max plunge!

Cheers,

Yawneeb

I've been meaning to ask if anyone else gets a 90 degree in X hip flip with Second Life-BVHExporter1a and the Pyg Rig?

All the BVH I export with this combo does this, but with the older script verisons I don't seem to get it. Its great If I want to do flying animations but not so good for anything else.

I just took a quick jaunt through the script. Looks like I perpetrated a major blunder. Nice catch, Py.

this little chunk in the script right here:

else
(
na = in coordsys gimbal hip.rotation.x_rotation as float
nb = in coordsys gimbal hip.rotation.z_rotation as float
nc = in coordsys gimbal hip.rotation.y_rotation as float
) -- end hips

should actually be like this:

else
(
mybox.rotation.controller.axisorder = 3
mybox.parent = mainworld
mybox.rotation = hip.rotation
na = in coordsys gimbal mybox.rotation.x_rotation as float
nb = in coordsys gimbal mybox.rotation.z_rotation as float
nc = in coordsys gimbal mybox.rotation.y_rotation as float
) -- end hips


Something like that.

Attached it 1b, but I fixed it blind. Theoretically it will work. Let me know.