When are you guys planning on updating .jme format for stuff like rag doll. I also would like to see some upgrades in the bone animation department of it. Like combining animations(i.e standing/shooting model+running model=running shooting model) it saves space, and it’s pretty cool.
Couple of other things thats may or may not be in there
vertex weight
source http://www.extremetech.com/article2/0,1697,1156303,00.asp
"Another advantage of skeletal animation is being able to ‘weight’ each vertex individually based on a number of other bones that influence the vertex. For example, movement of bones in the arms, the shoulders, the neck and even the torso can affect the mesh in the shoulders. When you move the torso, the mesh moves like a living character might move. The overall effect is a far more fluid and believable set of animations the 3D character can pull off, for less memory. Everybody wins.
Of course the drawback here is that if you want to animate something organic and very fine, like hair for instance, or a cape, you have to end up sticking a ton of bones in it for it to look natural, which drives up processing times a bit. "
overriding a specfic bone(I talked about this in AI and started it but I always had to update a drame after creating a lag that looked horrible),
source: above
"A couple of other things that skeletal based systems can give you is the ability to ‘override’ bones at a specific level–to say, “I don’t care what the animation wants to do for this bone, I want to point it at a specific point in the world”. This is great. You can get models looking around at events in the world, or keep their feet actually level on the ground they are standing. It’s all very subtle, but it helps bring additional realism to the scene. "
importing IK
source: above
“Using IK, the programmer can move a hand, or a leg, and have the rest of the model’s joints reposition themselves so the model is correctly oriented. For example, you’d say, “OK, hand, go pick up that cup on the table” and point the hand at the world position where the cup is located. The hand would move there, and the body behind it would sort itself out so the arms moved, the body bent appropriately, and so on.”
Well, we had been discussing the idea of including physics information in the .jme format, but it sort of got dropped a while back. Currently there is no real physics information stored in the files and further, better support needs to be implemented for handling ragdolls.
darkfrog
dark frog think you could drum up a list? Maybe I can see what I can do to help
First we need a good object that encapsulates multiple dynamic physics objects that represent the ragdoll. I did some preliminary work on this in jME-Physics. It is in the repository under the name "DynamicPhysicsGroup" but I wasn't very happy with the concept when I got done with it and thought it needed some re-thinking.
darkfrog
could you give me a link or 2 on rag dogs I thought all you had to do was limit the joints range of motion and make sure it didn't penatrate any other physics objects.
Thanks
Actually, that would be handled by your joints…realistically the DynamicPhysicsGroup is just an encapsulation that gives capabilities to the developer. Ragdolls can be done entirely without it, but for the purposes of making ragdolls easier to use having a grouping object makes a lot of sense to be able to keep a reference to it and grab what we want out of it. I would expect the concept to be similar to that of a Node in jME.
darkfrog
well then seems your jumping ahead of yourself shouldn't you get that much done? If you already have that much alrite then a node that contains what? Sounds like this doesn't have to be written into the jme file but extracted. Read in a joint,make a like of the verts it effects, then the mesh becomes a dynamic physics object and after it does that for all the joints you have a bunch of dynamic physics objects that are put into a dynamic phyics object group or what have you. The dynaimc physics group will just have an array list of all the objects. Am I right so far? Then it just becomes a matter of writing the contents of the dynamic phyisics group out in a file and in .jme it puts see blahblahblah.physicsgroup or what ever it ends up being.
setting the mass is really the problem nobody wants to sit at a command line entering mass values. I guess you could make up a list of final static values of stuff that is general. So what they input is just denisty like for a whole group they could do group.setDensity(body) and that would find volume and do that times density to get mass.
You are correct, there is nothing here that ties to the .jme file. However, it is my belief this should be done first and then you could just load a .jme file and get a DynamicPhysicsGroup back. The .jme file would need information on joints and mass of each DPO and potentially friction information.
darkfrog
Since there is nothing tring it to just rendering anything it shouldn't be in the .jme format thats why I said make an another format thats looked up when physics are used. If they just have a model running an animation then phyiscs info is no good. Another format keeps stuff seperated(better than some huge lump), can be accessed when physics are used, and it can store that info on joints,mass of DPO, and fiction infomation.
Divide and conquer is what i'm saying
What needs to be done
Just DPO group? Or do we need a system that imports the .jme format can finds joints and sets them to the phyisc joints and sets mass and what not.
PS: a kinda off topic question does phyics deal with IK, i wrote about it above.
Well, my idea was to make the .jme format able to encapsulate as much or as little as was desired. The .jme format could include just model information or it could include just physics information, or it could include both. This would allow maximum flexibility and you could pass multiple .jme files into a loader and come out with one model with all the aspects applied. This way for very simple models you can do it all in a single file, and more complex models (say that have multiple skins, potential physics attributes, etc) could be separated into multiple .jme files and then the combination loaded be determined at runtime.
With regards to Inverse Kinematics I don't think there is currently support for that in jME-Physics/ODE (Irrisor? Per?) for it. I could be wrong though. I can't imagine it would be that difficult to implement directly in jME-Physics though (at least a very simple implementation). If there is not current support for it that would be a great feature to have and probably something we would want available before we add this kind of information to a loadable format.
darkfrog
inverse kinematics is sort of automatic if you have a physics lib that supports joints, which ode does…just take control over one of the nodes in a chain of nodes…
MrCoder,
You explain that a little further? I was under the impression there was a lot more to it than that particularly since ODE doesn't have built-in support for range of motion on joints.
darkfrog
really ode doesn't have that, well if you just do the collision support it should keep (lets say human wise)the arm going into the torso basicly limiting it to that range of motion, the other thing is a joint can only go so far, i have always thought it to be the x,y,z bind position , but i think it's the distance between the 2 joints in the xyz bind position.
ODE does indeed have built-in support for range of motion on joints…and has for a long time
http://www.ode.org/ode-0.5-userguide.html#sec_7_5_0
Interesting…did not know that. I apologize for speaking out of my own ignorance. :o
darkfrog
ignorance is bliss 
…what we would really need though, is a connection between a physics library(read. jme-physics) and an animation library
if this animation libary include bone override, ik, and animation blending i'm all in
before "chaos" left I was hoping that his animation system and the md5 in particular would have formed the foundation for ragdolls in jmephysics, that have/had motionblending, easy weapons placement(if you skin and export to md5) and with special a maxscript on doom3world.org I could export any kind of animations to it(I have a rippling water puddle model done from it).
I have asked privately to have it fixed to be compatable with .9 plus but that going to be a while in the future 
I still maintain jars compatible with it for animation testing
Well it looks like there's plenty of interest to move forward on this. I guess lets just try to come to a consensus on what would solve the problems the best and go step-by-step and try to get it implemented.
Feedback on the DynamicPhysicsGroup would be appreciated (negative criticism won't be taken badly since I'm not too thrilled with it…and I wrote it) and what can be added to it for a good representation of a physics grouping. Does everyone agree that we need a good mechanism to store all these properties and then we can determine the properties that have to be loaded from a file based on that? We don't necessarily even need to use DPG, but to my knowledge it's the only supporting feature in jME-Physics currently for it.
darkfrog