New Animation System for Irrlicht
-
- Posts: 11
- Joined: Sat Feb 10, 2007 10:02 pm
-
- Posts: 11
- Joined: Sat Feb 10, 2007 10:02 pm
Thanks, Vermeer.vermeer wrote:battle.... :http://www.onigirl.com/pipeline
I tried the pipeline, but it doesn't export CS Physique. And Discreets phy2skin converter doesn't work properly for my models. However, the .FBX export-import converts correctly to skin and then I can also use as well the .X exporter. I think this shows again that having our own irrlicht format and exporters (both, xml ascii and xml embedded binary for example) would be best.
-
- Posts: 277
- Joined: Thu Dec 15, 2005 6:11 pm
I would like to request something in this animation system, which is much better by the way. I saw a post about culling the models that are offscreen. For my want them to be animated even if not rendered. It's like a particle fountain that dies with time. i don't want to turn around in myh game and turn back around to find the fountain the same as when it escaped my vision. Animations should be the same way, though I do believe it is a speedup, I don't think it applies in most cases. Also, if they are hardware skinned, how easy is it to get the current vertices for use for collision, physics whatever. If the info goes to the card and stays their, then will it be a bottleneck to retrieve it frame by frame for physics. If not(which is easy to believe since I don't know how it works), then cool, but if so, then it should be optional whether to use hardwared or software skinning.
kburkhart84:
I can go though this more technically, but what your saying is not a problem.
If you really needed the vertex positions every frame, the best method is to do hardware skinning, and do software skinning at the same time, but don't upload it.
I can go though this more technically, but what your saying is not a problem.
Well the way the system works, it will appear as if the models were animating when they were culled, it will not appear as if animation was paused when it was off screen.I saw a post about culling the models that are offscreen. For my want them to be animated even if not rendered.
I cannot see how it could possibly be a speedup not culling the animations.Animations should be the same way, though I do believe it is a speedup
well the vertices's of animated meshes are not normally used in physics engines, they normally use ragdolls, etc.Also, if they are hardware skinned, how easy is it to get the current vertices for use for collision, physics whatever. If the info goes to the card and stays their, then will it be a bottleneck to retrieve it frame by frame for physics.
If you really needed the vertex positions every frame, the best method is to do hardware skinning, and do software skinning at the same time, but don't upload it.
Yeah, of course, for lots of other reasons too.then it should be optional whether to use hardwared or software skinning.
-
- Posts: 277
- Joined: Thu Dec 15, 2005 6:11 pm
By the way, this project is not dead, me and bitplane are working on it over at http://code.google.com/p/irrlicht-plugins/
operational?
cool, i was able to find a bunch of your files on the svn over on google code. not asking for guarantees or anything, but could i get maybe a quick rundown of what you guys have working so far? im really curious heh.
My irrlicht-based projects have gone underground for now, but if you want, check out my webcomic instead! http://brokenboomerang.net
buhatkj:
Sorry for the massive delay, I've been a bit busy (I'm not anymore ), and I forget about your post.
CSkinnedMesh:
-All the stuff has been written for the same kind of animations irrlicht has now, should be faster then the animators irrlicht has now
-features have been written for animation blending, etc
-Able to hold and skin Vertex, Vertex2TCoords and VertexTangents type meshes (eg. bump-mapped animated meshes will be easy)
-Todo: Add an interface for the loaders to create this mesh
CB3DMeshLoader:
-Bitplane has started this, I need to covert it to create an CSkinnedMesh using it's interface.
-when done, this should all be usable in irrlicht
-other loaders with follow...
CAnimatedMeshSceneNode:
-For now no changes are needed to use all the same animation features irrlicht has now.
-I would like to fix a bug to double the speed of irrlicht's animations
-I'll get this to use SkinnedMesh's features, for bone control, animation blending, transitions...
-Change it from calling GetMesh() when holding SkinnedMesh, to the newer functions, this will also stop the need for the loaders scaling the animations out for interpolation, and will make animations a lot smoother.
Sorry for the massive delay, I've been a bit busy (I'm not anymore ), and I forget about your post.
Well nothing can be run yet, but:could i get maybe a quick rundown of what you guys have working so far?
CSkinnedMesh:
-All the stuff has been written for the same kind of animations irrlicht has now, should be faster then the animators irrlicht has now
-features have been written for animation blending, etc
-Able to hold and skin Vertex, Vertex2TCoords and VertexTangents type meshes (eg. bump-mapped animated meshes will be easy)
-Todo: Add an interface for the loaders to create this mesh
CB3DMeshLoader:
-Bitplane has started this, I need to covert it to create an CSkinnedMesh using it's interface.
-when done, this should all be usable in irrlicht
-other loaders with follow...
CAnimatedMeshSceneNode:
-For now no changes are needed to use all the same animation features irrlicht has now.
-I would like to fix a bug to double the speed of irrlicht's animations
-I'll get this to use SkinnedMesh's features, for bone control, animation blending, transitions...
-Change it from calling GetMesh() when holding SkinnedMesh, to the newer functions, this will also stop the need for the loaders scaling the animations out for interpolation, and will make animations a lot smoother.
-
- Posts: 277
- Joined: Thu Dec 15, 2005 6:11 pm
Since the topic was bumped up, I thought I would ask something. If I want to have one mesh(character) and control the bottom and the top differently, so say the walking animation for the legs and have the shooting be however, more or less how will this fit into the new animation system. I won't have to have two different nodes right?? Also, how would I create the bones and mesh as far as this is considered so that this won't be too hard to code later??
This is a very common need, which is why I cannot understand why everyone puts up with the animation system irrlicht has now.Since the topic was bumped up, I thought I would ask something. If I want to have one mesh(character) and control the bottom and the top differently, so say the walking animation for the legs and have the shooting be however, more or less how will this fit into the new animation system. I won't have to have two different nodes right?? Also, how would I create the bones and mesh as far as this is considered so that this won't be too hard to code later??
There are many ways to do this,
-Yes, you can do it with two nodes (one not visible) and use bone control, to animate the visible one, with the invisible one. (you have the most control with this method)
-You can use the animation blending we are making, you simply play both the walking animation and the shooting animation at the same time and they are blended together.
-Me and bitplane were talking about being able to set the animations are bone level (rather then whole node based), this should be pretty fast.
-
- Posts: 277
- Joined: Thu Dec 15, 2005 6:11 pm
I like the second and third best. With the second, I understand(maybe wrongly) that with the animation for shooting, I don't need to effect the leg bones, and with the animation for walking, I shouldn't effect the arm bones. I think if I had arm left to right animation when walking, wouldn't it look funny to blend that with shooting??? The third isn't bad as well, I think the second is enough solution to the problem. Though it would be useful like if your character is running, and a shot to the top area makes him lean back, but keep running, then yeah, the third could come in handy. But I think the same could be achieved like in the shooting example. Thanks for the confirmation though Luke. Now it is even harder to wait for the new system to come through finished and without too many bugs to be useful. Hopefully the day will come soon.Luke wrote:This is a very common need, which is why I cannot understand why everyone puts up with the animation system irrlicht has now.Since the topic was bumped up, I thought I would ask something. If I want to have one mesh(character) and control the bottom and the top differently, so say the walking animation for the legs and have the shooting be however, more or less how will this fit into the new animation system. I won't have to have two different nodes right?? Also, how would I create the bones and mesh as far as this is considered so that this won't be too hard to code later??
There are many ways to do this,
-Yes, you can do it with two nodes (one not visible) and use bone control, to animate the visible one, with the invisible one. (you have the most control with this method)
-You can use the animation blending we are making, you simply play both the walking animation and the shooting animation at the same time and they are blended together.
-Me and bitplane were talking about being able to set the animations are bone level (rather then whole node based), this should be pretty fast.
-
- Posts: 11
- Joined: Sat Feb 10, 2007 10:02 pm
I think nobody has used the current animation system properly for a game that needed more than the most basic character animation, thats why. People who had higher animation requirements turned to Ogre etc, and the others made car racers and Tetris clones.Luke wrote:This is a very common need, which is why I cannot understand why everyone puts up with the animation system irrlicht has now.
cheers
So, just wondering, what is the progress on this? Do you have the AnimatedMeshSceneNode modification? Basically, is there anything ready yet that lets me get transitions between animations for different mesh formats? I'm really glad you are making this, because I really need this feature. Thanks for your work!