with bone or without bone?
Author
i''m a beginner in 3d game programming, and i want to start making my own 3d engine..
there''s a questions that i want to ask..
-which one is better (speed, animation, etc) in 3d character, with bone or without bone?
-and any other suggestions thay u all may add on 3d engine
i''m planning the 3d engine for rpg game, third person, and many character in a scene.
thanks for all the reply.
Depends on a few factors.
First, target hardware-- If you plan on allowing for support on older hardware such as GeForce2, remember that vertex program support is slow and often worse than falling back on the CPU for transformation and lighting. So, you will need to provided fallbacks for your animation code to be handled by the CPU rather than the graphics hardware via vertex shader. Doing so will limit the number of models you can display onscreen, due to performing transformations in software.
Second, animation flexibility-- Skeletal animation with bones is a little more complicated than using vertex-keyframed animation, but it comes with the ability to dynamically generate animations at run-time by combining animations that affect different parts of the model. Walking affects the legs and torso. Swinging a sword affects the arms. You can create animations that only affect these parts, then dynamically combine them together when needed to create an animation for swinging the sword while walking. With vertex-keyframing this is very difficult to do.
Third, memory requirements-- Vertex-keyframing, while simpler and generally a bit faster than skeletal animation, takes up a significantly more amount of memory. Consider that in skeletal animation, your memory usage consists of storing the model vertex data (vertex, normal, UV, fall-back software transformation buffers if needed, etc...) only once, then storing multiple instances of the bone hierarchy for the frames of animation. In vertex-keyframing, you have to store multiple instances of the mesh, rather than a much smaller bone hierarchy. While not as memory-intensive as an equivalent 2D image animation, it is still memory hungry and so should be carefully considered.
Fourth, animation smoothness-- This can be lumped in with the memory requirements in a fashion. With skeletal animation, it is still possible to generate smooth, realistic animations with a very limited amount of keyframes, since each keyframe is interpolated by SLERPing quaternions, resulting in realistic rotational movement of bones around joints. With vertex-keyframing, frames are linearly interpolated from one to the next, so if keyframes are limited you will see an increase in visual artifacts of pieces of the mesh which are supposed to rotate around a joint linearly morphing to the next pose instead, sometimes causing abnormal shortening of limbs and awkward motion. This problem is alleviated by having more densely-packed keyframes, making the distance to morph from one keyframe to the next be as short as possible, but this heightens your memory usage accordingly.
Fifth, non-hierarchical animations-- Skeletal animations lends itself very well for animations of a hierarchical nature, such as the movements of a human, animal, or other living creature. It is not quite so convenient for animations of other natures, such as buildings that gradually grow (as in an RTS), things like waterfalls, breaking walls or shattering rocks, and so forth. For some things, it simply might be easier and more intuitive to do with vertex-keyframing. This allows you to generate the animations in your modelling package with different techniques than skeletal animation (particle systems or scripted rules, whatever) and still be able to use the resultant animation in your game, without some sort of awkward conversion to a bone system.
Sixth, component-based appearance-- For RPGs in which it is possible to equip a wide variety of equipment, it may be desirable to drastically change the appearance of a character based on current equipment. This is more easily accomplished with a skeletal system. The character consists of a set of pointers or references to various body parts and equipment meshes, which all have references to the bone(s) which affect them. Equipment can be swapped in and out while the pose remains largely the same (perhaps differing by choice of equipment in some regard, such as the different combat stance required to use a spear over a sword, etc). With vertex-based animation, this sort of thing becomes tricky indeed.
In summary-- implement a variety of types of animation, and don't limit yourself to one. Support them all, and use them when appropriate.
Best of luck
Golem
Blender--The Gimp--Python--Lua--SDL
Nethack--Crawl--ADOM--Angband--Dungeondweller
[edited by - VertexNormal on February 28, 2004 12:45:31 PM]
First, target hardware-- If you plan on allowing for support on older hardware such as GeForce2, remember that vertex program support is slow and often worse than falling back on the CPU for transformation and lighting. So, you will need to provided fallbacks for your animation code to be handled by the CPU rather than the graphics hardware via vertex shader. Doing so will limit the number of models you can display onscreen, due to performing transformations in software.
Second, animation flexibility-- Skeletal animation with bones is a little more complicated than using vertex-keyframed animation, but it comes with the ability to dynamically generate animations at run-time by combining animations that affect different parts of the model. Walking affects the legs and torso. Swinging a sword affects the arms. You can create animations that only affect these parts, then dynamically combine them together when needed to create an animation for swinging the sword while walking. With vertex-keyframing this is very difficult to do.
Third, memory requirements-- Vertex-keyframing, while simpler and generally a bit faster than skeletal animation, takes up a significantly more amount of memory. Consider that in skeletal animation, your memory usage consists of storing the model vertex data (vertex, normal, UV, fall-back software transformation buffers if needed, etc...) only once, then storing multiple instances of the bone hierarchy for the frames of animation. In vertex-keyframing, you have to store multiple instances of the mesh, rather than a much smaller bone hierarchy. While not as memory-intensive as an equivalent 2D image animation, it is still memory hungry and so should be carefully considered.
Fourth, animation smoothness-- This can be lumped in with the memory requirements in a fashion. With skeletal animation, it is still possible to generate smooth, realistic animations with a very limited amount of keyframes, since each keyframe is interpolated by SLERPing quaternions, resulting in realistic rotational movement of bones around joints. With vertex-keyframing, frames are linearly interpolated from one to the next, so if keyframes are limited you will see an increase in visual artifacts of pieces of the mesh which are supposed to rotate around a joint linearly morphing to the next pose instead, sometimes causing abnormal shortening of limbs and awkward motion. This problem is alleviated by having more densely-packed keyframes, making the distance to morph from one keyframe to the next be as short as possible, but this heightens your memory usage accordingly.
Fifth, non-hierarchical animations-- Skeletal animations lends itself very well for animations of a hierarchical nature, such as the movements of a human, animal, or other living creature. It is not quite so convenient for animations of other natures, such as buildings that gradually grow (as in an RTS), things like waterfalls, breaking walls or shattering rocks, and so forth. For some things, it simply might be easier and more intuitive to do with vertex-keyframing. This allows you to generate the animations in your modelling package with different techniques than skeletal animation (particle systems or scripted rules, whatever) and still be able to use the resultant animation in your game, without some sort of awkward conversion to a bone system.
Sixth, component-based appearance-- For RPGs in which it is possible to equip a wide variety of equipment, it may be desirable to drastically change the appearance of a character based on current equipment. This is more easily accomplished with a skeletal system. The character consists of a set of pointers or references to various body parts and equipment meshes, which all have references to the bone(s) which affect them. Equipment can be swapped in and out while the pose remains largely the same (perhaps differing by choice of equipment in some regard, such as the different combat stance required to use a spear over a sword, etc). With vertex-based animation, this sort of thing becomes tricky indeed.
In summary-- implement a variety of types of animation, and don't limit yourself to one. Support them all, and use them when appropriate.
Best of luck
Golem
Blender--The Gimp--Python--Lua--SDL
Nethack--Crawl--ADOM--Angband--Dungeondweller
[edited by - VertexNormal on February 28, 2004 12:45:31 PM]
thanks VertexNormal
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
