Animation Woes - 3dmax

posted on October 8th, 2012, 1:30 pm

I am trying to setup a couple of objects to emulated automated welders within a shipyard. The diagram below represents a top view of the respective setup. Now keep in mind, I am green as grass when it comes to 3dMax but I am slowly learning.



The procedure I used to set this up follows:

1. Assigned an animated texture to Object 2 (emulate the welding beam).
2. Assign an animated texture to Object 4 (emulate the welding beam).
3. Select Object 1 and Object 2 and group together (GROUP A).
4. Select GROUP A and establish its pivot point.
5. Select GROUP A and setup its rotation

a. Assign controller (Rotation: Euler XYZ; TCB Rotation)
b. Assign keys to rotate approximately 45 degrees to the right, return to home, 45 degrees to the left, and return to home.

Note: At this point I exported the test subject using Mr. Vulcan’s superb exporter script in order to see how it would look in Storm 3D and it behaved perfectly.

6. Select Object 3 and Object 4 and group together (GROUP .
7. Select GROUP B and establish its pivot point.
8. Select Group B and setup its rotation.

a. Assign controller (Rotation: Euler XYZ; TCB Rotation)
b. Assign keys to rotate approximately 45 degrees to the right, return to home, 45 degrees to the left, and return to home.

I exported it again thinking I was actually beginning to learn 3dMax (lol). This time the results were not what I expected as both objects were now rotating but they seemed to be rotating from a completely different pivot point. In other words, the position of GROUP A and GROUP B had changed completed and they were off the base.

What am I doing wrong? Any help would be appreciated.

posted on October 9th, 2012, 6:10 pm

I posted this on AFC as well, but I think here the answer will receive a wider audience for those that are interested.

Looking awesome pepperman, great idea

I think what's going on with the pivot points is that upon moving/scaling/editing etc, the object pivot point can be transformed in unexpected ways.

Whenever possible, I try to use helper points instead of the object's pivot point to control animations. In your example, the hierarchy would look as follows:

Code: Select all

-geometry
  -StationaryMesh
  -Pivot1
    -Obj1
    -Obj2
  -Pivot2
    -Obj3
    -Obj4


Here, pivots are animated point helpers (same type as root and geometry), and objects are the mesh objects. You do not have to group or "attach" the two objects together.

The neat thing about this setup is that now you can scale/move/rotate the pivots and the animation will still work correctly. You can even clone the pivots and their children, and the animations will still work correctly.

Did you by any chance change the hierarchy setup between your exports on groups A and B? Or attach something to the groups? This almost always screws up the location of the pivots.

Cheers, hoping to see this in action
Mr. V

PS: something else I think might be helpful..

Sometimes (for yet unknown reasons), the parent-child transform becomes invalid and doesn't get exported properly. The transform is the rotation + translation matrix that determines the relative position and orientation between the child and parent objects (in this case, it is from point helper to mesh).

I added some quick checks and validations to make sure that the transform is valid before export, but something still breaks occasionally (once for me out of 50 or so animations). One way to fix this is to manually reset the transform just before exporting.

Go to the hierarchy tab on the side tools panel (a box with three little boxes under it). Select the mesh that will be animated, or the mesh that will be attached to an animated point helper. Then click on "transform" and "scale" buttons inside of the "Adjust Transform" rollout. This repaired a similar animation issue that I was having.

Let me know how this goes. I'll try to post a screenshot later when I'm on my modding machine.

posted on October 9th, 2012, 7:14 pm

Thanks for posting that here Mr.Vulcan . Would you by any chance be willing to expand your 3dsMax guide with that information? It might prove useful to have that on the FOguide for future problem solvers

posted on October 9th, 2012, 7:41 pm

Sure, I could do that. Lets see what solves the animation problem pepperman is having. I will be updating the documentation with a few additions anyhow sometime in the near future (intentionally vague )

posted on October 9th, 2012, 11:06 pm

Thanks Mr. V. I saw a reference to using point helpers in my research but wasn't quite sure how to hook it up in the hierarchy. I will certainly give this a go and report back the results.

As far as what might have gotten changed between test 1 and test 2, I have no idea as I tried so many things I lost count and I neglext to keep good book on this or that. Back to the drawing board. I am hoping this will look kind of cool once I figure it out.

As far as your script documentation goes, it has been extrmely valuable to date. I have made reference to it many many time.

posted on October 10th, 2012, 9:23 pm

These dummy pivot nodes are indeed the way to go. Just did two of the welders and it worked perfectly in Storm. Now I need to figure out how to make the welding beam only come on when the rotational animation starts. I am thinking this has to be done via the animated sprites somehow.

posted on October 10th, 2012, 11:31 pm

Not sure whether this occurred previously or not but it seems the animated texture stops when the mesh animation in in play. Could be me doing something out of sequence.

posted on October 11th, 2012, 3:33 am

Glad to hear it works now

Is the animated beam a sprite or a mesh?

If you can make it into a sprite node, then you can apply two types of animation to it:

1 - texture animation for the welding beam (standard flipbook type)
2 - draw animation for the sprite (the type seen on lighting in nebulas)

The first simply animates the texture, and the second lets you turn "on" and "off" the sprite node as an animation loop.

To do this, make a new draw animation:

Code: Select all

@animation weldgunDrw
draw 3 5 step
@keyframes
0.0   0
1.0   1
4.0   0

Then add the sprite entry

Code: Select all

weldTexture   weldTextFile   0   0   64   64   @anim=tex4x4
@sprite_node weldGunSpr weldTexture welgGunDrw (2.0,2.0) (1,0,0)

The last thing to do is to synchronize your mesh animation with the sprite animation. In the example here, I used a 5 second draw animation, which draws the sprite for 3 seconds (1 to 4). To make the mesh animation have the same length, attach a

Code: Select all

"c_keys_5"

point helper to all animated objects (ie, objects with key frames).

"c_keys_#" specifies the length of the animation in seconds.

Now the hard part comes in trying to scale and position the sprite node correctly

Not sure whether this occurred previously or not but it seems the animated texture stops when the mesh animation in in play. Could be me doing something out of sequence.

This happens in Storm? Should be going on a loop.. not sure why it'd stop. If this happens in game, then you need buildAnimation = 2 in the odf.

posted on October 11th, 2012, 7:37 pm

Thanks again Mr. V. I will give this a good read and disect it.

This was happening in game. I am using the stock welding beam texture, applied as a standard flipbook type (i.e., c_anim_tex1x4) applied to the beam mesh. In Storm it looked fine, looping continuously. When played in game, not so. I had animation = 2 and buildAnimation = 1 set in the shipyard odf. What I suspect is that there is a synching issue. The welder animation (rotational) is much longer in duration than the flipbook animation. I think but cannot confirm that both worked however the flipbook animation happens so quickly you can't really see it. Is it possible that the buildAnimation = 1 causes both to animate through 1 complete cycle then stop. If so, this would explain why the flipbook animation can't be seen as it does it 1x4 thing and then stops.

I will continue to explore, learn and report back. You'll laugh at this one. I accidentily dropped the mesh file in the addon folder and hadn't realized it. I was making changes in Max to this or that paramether and I keep noticing nothing was changing. Took me a while to realize that the mesh was in the addon folder. I didn't realize that it would take precedent over the sod folder. I was tired and didn't find it too funny at the time.

posted on October 12th, 2012, 12:05 am

Test #1:

1. Removed the top part of the shipyard for observation.
2. Added two sprite nodes for one of the welders using the prescribed method. One was oriented in the horizontal plan; the other in the vertical plane. This replicated the mesh version nicely.
3. Added flipbook animation texture to the beams for the other three welders.
4. No rotational animation applied to any of the welders.
4. Exported the sod.
5. Viewed in Storm 3D. All for welding beams working nicely.
6. Tested in game. Shipyard odf included animation = 2 and buildAnimation = 1.
7. Prior to building a ship the animations were playing. Upon building the ship, both the flipbook texture animation and the sprite node animation quite playing.
8. Upon exiting the shipyard, the welding beams did not resume their animation.

Test #2:
Essentially the same as test #2 with the exception of an odf change: animation = 1 and buildAnimation = 1
Tested in game. None of the welding beam animations were playing prior to building the ship. None begain while building the ship.

posted on October 14th, 2012, 1:13 pm

Okay, after multiple tests I am increasingly convinced that the standard flipbook animations do not cooperate well with the odf command: buildAnimation = 1. The best I was able to accomplish was getting the flipbook animation to cycle through one time and one time only. In order to keep my frustration level manageable, I abandoned using the flipbook animation approach using sprite nodes as Mr. V suggested; however, I set up each sprite node to play one frame of the of the 1x4 sequence and chained them together to get the respective timing. I setup 4 sprite nodes for the horizontal plane and 4 sprite nodes for vertical plane, setting up the animation sprite to cycle through the flipbook three times. At the present, the Phoneix ship takes 300 seconds to build so I adjusted the animation sprite to have the beam fire every 25 seconds. This sort of emulates the building bees. A brute force technique that accomplishing a similar thing so I am pretty happy with the results.

posted on October 14th, 2012, 3:34 pm

That's a perfectly valid way to make those animations work

I was going to suggest making a custom flipbook animation if all else failed. Instead of using @auto for keyframes, you can define your own frame sequences, which can be much longer than the standard square flipbooks.. But I guess more on that in a different topic.

Congrats on making it work

posted on October 22nd, 2012, 1:01 am

If anyone is interested in the final result, it can be downloaded here:

http://armada2.filefront.com/file/Romua ... ity;121345

posted on October 22nd, 2012, 1:12 am

Awesome work pepperman, you weren't kidding about the brute force method, lol. I might use your technique for something if you don't mind.

posted on October 22nd, 2012, 7:20 pm

I remember in many engineering classes that if there was a hard way to solve a problem I'd often go that route.

Brute force, isn't pretty but in this case it worked. I enjoy learning so if anyone ever see a better mousetrap by all means let me know. Mr. Vulcan...feel free to use the method or improve it as you see fit. I am off trying to lean more about Max and animation in general.