New Animation System for Irrlicht
this is what view hierarchy shows me in the directx mesh viewer, this must be what you are talking about when you say there is no nesting. This is what happens when I export from Panda with "Top Frame Only"
exporting with "Sub Frame Hierarchy" checked gives me this. A nested hierarchy but with "Unnamed frame" for each joint.
the thing is, both give me the same result loaded into irrlicht. one bone sticking straight up, and getJointNode->getAbsolutePosition() returning the same point for every joint
exporting with "Sub Frame Hierarchy" checked gives me this. A nested hierarchy but with "Unnamed frame" for each joint.
the thing is, both give me the same result loaded into irrlicht. one bone sticking straight up, and getJointNode->getAbsolutePosition() returning the same point for every joint
Posting to report an issue I found that is present in the old animation system, and is present in a different form in the new animation system. I discussed this with hybrid and he suggested I post it, along with anything else different in my game between animation engine versions.
Old engine:
I have a bunch of animated mesh scene nodes in my game that share a common mesh. There appears to be an issue with sharing a mesh and bounding boxes as any time I kill a monster and he falls down, all the other monsters in the game have their bounding box flicker between the lieing down on the ground one and the standing up one. Sometimes they go back to the standing up one sometimes they remain lieing down. The common thing is wherever they stay, they are all the same. So you will either have a bunch of monsters with on the ground boxframes even though most of them are standing up, or they will all be standing up even though some of them are lieing down. These are ms3d meshes btw.
Here is the code to create a monster:
IAnimatedMeshSceneNode *node;
IAnimatedMesh *mesh = myGameSceneManager->getMesh("models/zombie.ms3d");
node= myGameSceneManager->addAnimatedMeshSceneNode(mesh);
node->setScale(vector3df(1.6f,1.6f,1.6f));
node->setMaterialTexture(0, myGameDriver->getTexture("textures/zombie.jpg"));
setDefaultMaterialFlags(node);
node->setAnimationSpeed(400);
node->setAnimationSpeed(30);
//node->setFrameLoop((u16)(2.0f*ANIMATION_MAGIC_NUMBER),(u16)(20.0f*ANIMATION_MAGIC_NUMBER));
node->setFrameLoop(2,20);
//node->setCurrentFrame((u16)(2.0f*ANIMATION_MAGIC_NUMBER));
node->setCurrentFrame(2);
node->setLoopMode(true);
return node;
New engine:
The bounding boxes in the above situation are always the standing up one. They never lie down when shot(even though graphicaly the monster does fall down as normal). The only code change for the new engine is changing the frame speed to get rid of the magic number bit
Old engine:
The gun(A ms3d model converted from a halflife 2 mdl) is in the center of the screen 2 hands holding a pistol. The gun is a single animated mesh scene node from an ms3d file. It is attached to the camera and given a position offset.
Here is the code that makes this gun:
IAnimatedMesh *mesh = myGameSceneManager->getMesh("weapons/pistol/pistol.ms3d");
ISceneNode* node= myGameSceneManager->addAnimatedMeshSceneNode(mesh);
String textureNames[]={"weapons/pistol/hand.bmp","weapons/pistol/thumb.bmp","weapons/pistol/pistol_I.bmp","weapons/pistol/pistol_II.bmp"};
applyTextures(node,4,textureNames);//Helper function i wrote that just puts textures on
setDefaultMaterialFlags(node);
return node;
and then later on in the code
equippedWeapon->getSceneNode()->setParent(weaponAttachSceneNode);//Where weapon attach scene node in this case is the camera
equippedWeapon->getSceneNode()->setPosition(weaponAttachOffset);//some offset
equippedWeapon->getSceneNode()->updateAbsolutePosition();
New engine:
The gun is off to the left and only one hand is visible.
I have some screenshots of this if you would like them let me know where to send them. I don't have anywhere to host them atm to link them on this post.
Please let me know if there is any other information or work i can do to help you diagnose this. I can send you this code but its huge so it might be painful.
Old engine:
I have a bunch of animated mesh scene nodes in my game that share a common mesh. There appears to be an issue with sharing a mesh and bounding boxes as any time I kill a monster and he falls down, all the other monsters in the game have their bounding box flicker between the lieing down on the ground one and the standing up one. Sometimes they go back to the standing up one sometimes they remain lieing down. The common thing is wherever they stay, they are all the same. So you will either have a bunch of monsters with on the ground boxframes even though most of them are standing up, or they will all be standing up even though some of them are lieing down. These are ms3d meshes btw.
Here is the code to create a monster:
IAnimatedMeshSceneNode *node;
IAnimatedMesh *mesh = myGameSceneManager->getMesh("models/zombie.ms3d");
node= myGameSceneManager->addAnimatedMeshSceneNode(mesh);
node->setScale(vector3df(1.6f,1.6f,1.6f));
node->setMaterialTexture(0, myGameDriver->getTexture("textures/zombie.jpg"));
setDefaultMaterialFlags(node);
node->setAnimationSpeed(400);
node->setAnimationSpeed(30);
//node->setFrameLoop((u16)(2.0f*ANIMATION_MAGIC_NUMBER),(u16)(20.0f*ANIMATION_MAGIC_NUMBER));
node->setFrameLoop(2,20);
//node->setCurrentFrame((u16)(2.0f*ANIMATION_MAGIC_NUMBER));
node->setCurrentFrame(2);
node->setLoopMode(true);
return node;
New engine:
The bounding boxes in the above situation are always the standing up one. They never lie down when shot(even though graphicaly the monster does fall down as normal). The only code change for the new engine is changing the frame speed to get rid of the magic number bit
Old engine:
The gun(A ms3d model converted from a halflife 2 mdl) is in the center of the screen 2 hands holding a pistol. The gun is a single animated mesh scene node from an ms3d file. It is attached to the camera and given a position offset.
Here is the code that makes this gun:
IAnimatedMesh *mesh = myGameSceneManager->getMesh("weapons/pistol/pistol.ms3d");
ISceneNode* node= myGameSceneManager->addAnimatedMeshSceneNode(mesh);
String textureNames[]={"weapons/pistol/hand.bmp","weapons/pistol/thumb.bmp","weapons/pistol/pistol_I.bmp","weapons/pistol/pistol_II.bmp"};
applyTextures(node,4,textureNames);//Helper function i wrote that just puts textures on
setDefaultMaterialFlags(node);
return node;
and then later on in the code
equippedWeapon->getSceneNode()->setParent(weaponAttachSceneNode);//Where weapon attach scene node in this case is the camera
equippedWeapon->getSceneNode()->setPosition(weaponAttachOffset);//some offset
equippedWeapon->getSceneNode()->updateAbsolutePosition();
New engine:
The gun is off to the left and only one hand is visible.
I have some screenshots of this if you would like them let me know where to send them. I don't have anywhere to host them atm to link them on this post.
Please let me know if there is any other information or work i can do to help you diagnose this. I can send you this code but its huge so it might be painful.
Go for it!!
Dear Luke,
I cannot wait to use your animation system!!
Best greetings.
I cannot wait to use your animation system!!
Best greetings.
Oh I have a question in addition for Luke, or whoever. I read through this entire thread and I didn't see anyone talking about this so hopefully I am not asking a duplicate question.
The current ray tracing functions. It would be awsome if there was a way to get the join that a line intersects with. Right now I believe you can only get the triangle or the scene node.
I would love to be able to do body part specific collision detection for my game's projetiles.
I don't know much about how your code works so there might be a really good way to do this, but one option would be to just take the center of the triangle, and iterrate through all of a scene node's joins and find the one that is the closest. There is a chance for picking the wrong joint though if a bunch are close together. If you have something better though let me know.
The current ray tracing functions. It would be awsome if there was a way to get the join that a line intersects with. Right now I believe you can only get the triangle or the scene node.
I would love to be able to do body part specific collision detection for my game's projetiles.
I don't know much about how your code works so there might be a really good way to do this, but one option would be to just take the center of the triangle, and iterrate through all of a scene node's joins and find the one that is the closest. There is a chance for picking the wrong joint though if a bunch are close together. If you have something better though let me know.
Last edited by kendric on Tue Aug 07, 2007 2:19 pm, edited 2 times in total.
Luke:
http://www.sendspace.com/file/62ozwf
actually I just tried loading this again and the debug skeleton does appear, except the joint sticking straight up is still there, and I can't get any usable joint positions.
For moving joints, I can't move them with setPosition. Has this been implemented yet, or is it just a problem with my mesh?
http://www.sendspace.com/file/62ozwf
actually I just tried loading this again and the debug skeleton does appear, except the joint sticking straight up is still there, and I can't get any usable joint positions.
For moving joints, I can't move them with setPosition. Has this been implemented yet, or is it just a problem with my mesh?
yeah I was talking to bitplate, about this, the bounding box is mainly used for culling, not really picking. you could try manually setting the bounding box per node, but the plain irrlicht will overwrite any value (skinnedMesh should be fine)The bounding boxes in the above situation are always the standing up one. They never lie down when shot(even though graphicaly the monster does fall down as normal). The only code change for the new engine is changing the frame speed to get rid of the magic number bit
irrlicht made the culling of animated meshes completely pointless (in fact it's alot slower then not culling at all), which is fixed in skinnedMesh and 1.3.1, I'd like a better way to fix it, but I cannot think of any.
well normally this is done in a physics engine, along with ragdolls. The animation system doesn't know how wide, or what shape the joints should be. And a physics engine would also be a lot faster at ray casting then irrlicht.The current ray tracing functions. It would be awsome if there was a way to get the join that a line intersects with. Right now I believe you can only get the triangle or the scene node.
But if you had the triangle id, I could get the animation system to return which joint is affecting it, so you take a different hp off based on it or something, by this is not what most games do, it's pretty slow with a few meshes.
gheft, I'll reply to you later, it's to late now...
but yes, setPosition has been implemented...
thanks for the comments
Thanks for the answer Luke. I have 2 comments that maybe you can shed some light on.
As far as the bounding boxes go:
I use the bounding box check in the same way the irrlicht engine(atleast the 1.3.1) does, in picking. So does that code need to be changed as well? If you look at:
getSceneNodeFromScreenCoordinatesBB
which calls:
getPickedNodeBB
which does:
const core::aabbox3df& box = current->getBoundingBox();
if (box.intersectsWithLine(line))
What I really want is a way to screen scene nodes rather then doing a triangle test on every single one.
This falls into the 2nd comment, you mention using the physics engine to do these things. It seems to me that all the animation art work is moving meshs around, and you would have to move the physics model every frame to match the mesh. There are 2 big issues here. I am using newton and your supposed to apply forces to move things. I don't know how warping things around will effect the realisitic ness of things. The 2nd issue is matching up complex joint movement and physics bodies to match. With joints its more possible now but like in 1.3.1 there would be no way to match body parts from the mesh with physics bodies to synch them up. This is why I chose to ray trace in the scene node side of things, and just let physics control rotation and position.
Moving to a 100% match of what you see on screen with scene nodes and what your bodies are in your physics engine is a task that seems very daunting to me. What I have now is basically a simple cylinder for character models and then more complex shapes can easily exist for non animated scene nodes. All ray tracing is done scene node side and then the user always sees what they expect and you don't have bullets passing through body parts.
Phew that was long winded.
So to sumarize if bounding boxes are no good, and I want to stay scene node side, what do you suggest i use for ray tracing screening to avoid a hundred triangle selector tests each frame. And finally you mention if I have the triangle ID, the triangle3d class has no ID that I can see. Its just a collection of points. Thats what i get back from the getTriangle function in irrlicht.
If you made it all the way to the bottom of this post, thank you very much and Thanks for you hard work.
As far as the bounding boxes go:
I use the bounding box check in the same way the irrlicht engine(atleast the 1.3.1) does, in picking. So does that code need to be changed as well? If you look at:
getSceneNodeFromScreenCoordinatesBB
which calls:
getPickedNodeBB
which does:
const core::aabbox3df& box = current->getBoundingBox();
if (box.intersectsWithLine(line))
What I really want is a way to screen scene nodes rather then doing a triangle test on every single one.
This falls into the 2nd comment, you mention using the physics engine to do these things. It seems to me that all the animation art work is moving meshs around, and you would have to move the physics model every frame to match the mesh. There are 2 big issues here. I am using newton and your supposed to apply forces to move things. I don't know how warping things around will effect the realisitic ness of things. The 2nd issue is matching up complex joint movement and physics bodies to match. With joints its more possible now but like in 1.3.1 there would be no way to match body parts from the mesh with physics bodies to synch them up. This is why I chose to ray trace in the scene node side of things, and just let physics control rotation and position.
Moving to a 100% match of what you see on screen with scene nodes and what your bodies are in your physics engine is a task that seems very daunting to me. What I have now is basically a simple cylinder for character models and then more complex shapes can easily exist for non animated scene nodes. All ray tracing is done scene node side and then the user always sees what they expect and you don't have bullets passing through body parts.
Phew that was long winded.
So to sumarize if bounding boxes are no good, and I want to stay scene node side, what do you suggest i use for ray tracing screening to avoid a hundred triangle selector tests each frame. And finally you mention if I have the triangle ID, the triangle3d class has no ID that I can see. Its just a collection of points. Thats what i get back from the getTriangle function in irrlicht.
If you made it all the way to the bottom of this post, thank you very much and Thanks for you hard work.
gheft:
well the problem seems to simply be the scaling on the bones, some of the code is uncomment be cause it was causing problems. it's hard because some x meshes only work fine when you ignore scaling and some only work (like yours) when you don't. I would like to fix it proper, but exporting the mesh without any bone scaling will fix the problem.
kendric:
yeah the physics can be pretty tricky.
but there is still the problem with updating the triangle selector as the mesh updates, it's pretty slow.
I could add a ray picking function to AnimatedMeshScene, it wouldn't be the fastest function in the world, but faster then updating and using a triangle selector. But that would be after skinnedMesh is complete.
well the problem seems to simply be the scaling on the bones, some of the code is uncomment be cause it was causing problems. it's hard because some x meshes only work fine when you ignore scaling and some only work (like yours) when you don't. I would like to fix it proper, but exporting the mesh without any bone scaling will fix the problem.
kendric:
yeah that's weird I'd like to have a lookThe gun is off to the left and only one hand is visible.
yeah the physics can be pretty tricky.
yeah that's true, you could change the function to give you the id.And finally you mention if I have the triangle ID, the triangle3d class has no ID that I can see.
but there is still the problem with updating the triangle selector as the mesh updates, it's pretty slow.
I could add a ray picking function to AnimatedMeshScene, it wouldn't be the fastest function in the world, but faster then updating and using a triangle selector. But that would be after skinnedMesh is complete.
Oh and I meant to add another piece of info on my selection issue. When I was seeing the bounding box thing, I tried as a workaround for fun getting the frame of the mesh and generating a fresh triangle selector. I still seemed to see behaviour where it wouldn't detect collisions right when one guy was lieing down and one was not.
-
- Posts: 1638
- Joined: Mon Apr 30, 2007 3:24 am
- Location: Montreal, CANADA
- Contact:
LW Loaders?! Alexionne?
Hi!
Great for this new animation system! Is it true Alexionne?! You would implement LW loaders!??
Im working primiraly with this, this would be more than great to use this! I would load a mesh with bones and animate it directly
Great for this new animation system! Is it true Alexionne?! You would implement LW loaders!??
Im working primiraly with this, this would be more than great to use this! I would load a mesh with bones and animate it directly
Re: LW Loaders?! Alexionne?
I've already started working on it. I'm currently implementing loading of VMAD chunks (discontinuous vertex mapping), and hope to find some nice way of implementing skeletal animation support. Also, I'll try to improve material support for LWO objects, if present Irrlicht design allows it.christianclavet wrote:Hi!
Great for this new animation system! Is it true Alexionne?! You would implement LW loaders!??
EDIT: There's already partially working LWO loader at http://parsys.informatik.uni-oldenburg. ... rmats.html, I've used is as a base for my work.
Best,
Aleksa
LWO is well suported for objects quite ok by wings and blender.
WOuld be great
WOuld be great
Finally making games again!
http://www.konekogames.com
http://www.konekogames.com