How do games normally do it when 3d models move or/and rotate? Is it an animation or does it actually move and rotate through code?
I started wondering about this while playing Dungeon Siege III yesterday. There's a place in the game where you are running over a floating pathway and hovering rocks move in circles around the path. Here's an image that I hope will make it a bit more clear.
[media]http://img225.imageshack.us/img225/2329/unled1dv.jpg[/media]
Other examples might be doors that opens or floating islands (like in WoW Outlands). What I am trying to describe is movement that involves movement of the object in its environment and not "internal movement" in the object (Like a flag in wind or a car engine shaking).
If both methods are used, what are the pros and cons with them? I don't know if it's possible to answer this, but I got a bit curious and thought maybe someone here knows.
If this is the wrong forum to post this, please move it.
3d model movement
It probably varies depending on how the developers want to do it. Typically for rocks like that, I would animate them to spin locally (so the animation is them spinning in a circle around the center of the model), and in the game you draw a path for it to follow, like it orbiting around a larger rock. It might all be one model, and they just animate it to spin and orbit at the same time. There really aren't any pros or cons to it, just whatever is easier.
Author
I don't know much about 3d modelling, but if you were to include the movement path in the animation, would it affect the file size? I might just be thinking too sprite sheet now (since a single sprite in that animation would have to be large enough to fit the whole path) ...
It will, but usually not by much. The path in the game engine will increase the ultimate file size as well, but likewise it's fairly minimal, especially in comparison to the size of the final game.
I hope you don't get offended; I think you have a lot of knowledge to get reproducing these rocks by modelling and animating them in a package such as 3DS Max or Blender, and then later trying to animate again but through direct code in a 3D engine.
You need to produce. If you have any trouble reproducing what you saw in the game, please ask and I'll help.
You need to produce. If you have any trouble reproducing what you saw in the game, please ask and I'll help.
Author
I'm not sure what you're trying to explain, so I am definitely not offended. I wasn't thinking of making anything like these rocks. As the first post says, I am just wondering how this sort of movement is done in general. The rocks from Dungeon Siege III was just an attempt at giving an example, since I had a hard time trying to describe it.
If it was me, I'd keep the model and animation paths separate. I'd probably keep the animation path as a list of points or a spline that I could load up and step through. That way, I could tweak the points via script at run-time, rather than having to open the model up in the 3D editor and tweak the animation there. Also, this way you could use multiple instances of the same model and put them on different paths, or put several different models on the same path.
I would find it preferable to not animate them at all in Max or whatever you're using, and just make them static. You can usually rotate them in the engine however you want, so you could just set up a prefab or something and tweak it a little bit to change the speed it rotates as well as the paths. Unless the mesh needs to be distorted like character models or has overly complicated movement, I see no point in animating it for something that simple.
How do games normally do it when 3d models move or/and rotate? Is it an animation or does it actually move and rotate through code?
I started wondering about this while playing Dungeon Siege III yesterday. There's a place in the game where you are running over a floating pathway and hovering rocks move in circles around the path. Here's an image that I hope will make it a bit more clear.
[media]http://img225.imageshack.us/img225/2329/unled1dv.jpg[/media]
Other examples might be doors that opens or floating islands (like in WoW Outlands). What I am trying to describe is movement that involves movement of the object in its environment and not "internal movement" in the object (Like a flag in wind or a car engine shaking).
If both methods are used, what are the pros and cons with them? I don't know if it's possible to answer this, but I got a bit curious and thought maybe someone here knows.
If this is the wrong forum to post this, please move it.
There's no simple answer to this question, there're several considerations. The basic idea is, that it is quite simple to animate whole objects by just moving and rotating them, on the other hand it is legal to add some bones to the rocks and animate them in a modelling tool. The later case has the disadvantage that you would use some kind of skeletal animation system which costs more preformance than simply moving the object around. Still it could be valid if you want to avoid to extend your engine to easily create such animation (i.e. splines).
An other consideration is that you want to keep the control of the animation sometimes. I.e. a gate/door which moves only up and down and will be blocked by obstacles is easily done in code. On the other hand if you have a very complex door setup (i.e. roots which will entangle when blocking a path) you will most probably need to do the animation in a modelling tool.
Both can and will be used, depends on what is happening. The picture isnt good, but regardless: If simply hitting left on the joystick, the model will physically rotate in the world by code.
Jumping and doing a sword attack forward: Physics is driving the model up and forward, while sword attack is driving animation.
Most of the time animation is in place. IE walk cycles when played back are models air walking in place.
Jumping and doing a sword attack forward: Physics is driving the model up and forward, while sword attack is driving animation.
Most of the time animation is in place. IE walk cycles when played back are models air walking in place.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
