Also, some race seems to be taller than others. For now, the physic system doesn't take that into account. Should it?
Yes. And you need to consider object scaling too. This is a separate issue through. I guess we can consider the race-specific sizes to be part of this task.
this suppose that the scene node is located on feet
The scene node is at the position specified by the coordinates in the world model. Any offsets (rendering or physics) need to be handling by the respective subsystem.
So when physic is on, the camera is located on feet position. The camera should be translated of 70 in the Z axis (the Y axis for Ogre?) but I don't know where to do this change in the new render system.
The whole camera handling is highly provisional and probably needs to be rewritten from scratch. No point in bothering with it now.
As far as activation goes I am pretty clueless, so I don't know if this will help, but here goes:
I was thinking the way activation works in morrowind for npcs/creatures is a "particle" is shot from the current view angle. If it hits a body part/shape of an npc/creature then it is activated.
Npc body part entities can be obtained through the scene node. Npcs have multiple free parts (not attached to just 1 bone) attached to the scenenode -- hands, chest, tail, beast feet.
One entity attached to the scenenode is the base, and has body parts bound (attached to 1 bone) to it (using attachObjectToBone()). These parts include: feet, lower legs, upper legs, wrists, forearms, groin, head, neck, upper arms, ankles.
Dunno if our activation system could actually query parts like this, but if this could work you wouldn't have to mess with heights/shape tweaking.
Creatures consist of only one entity - so they may be simpler for activation.
Dunno if my rambling will help.
Are we trying to get creature activation in too?
Actually no, it doesn't help, because activation is fully functional now. It has been so for quite a while. Even for creatures. There was only this one last annoying bug. Nothing more to do, unless someone finds a new bug.
There was a portability problem with it and corristo provided a fix. But actually it seems we have a bigger problem here. This code doesn't make sense to me. Where is this number coming from? And the == is also a problem. I doubt that a float can represent the value 10000000000000000 exactly. Under what conditions would this comparison yield the value true?
It was a constant FLT_MAX, but I changed it when you were having compile errors. If the timeStart is FLT_MAX, it should be skipped, otherwise we get a crash. Certain pieces of clothing had FLT_MAX as the time start, and didn't have any real animation data. It should actually be >= . We will need this for clothes/armor.
It was a constant FLT_MAX, but I changed it when you were having compile errors
No idea about what compile errors you are talking, but it won't work that way. Except for being C instead of C++ FLT_MAX would have been the right solution, I guess. So we should change it as I proposed on the pull request and also change the comparison operator.
Just committed some code to the animation2 branch. Did a few things differently and am now getting slightly better performance, 35fps average animating all 10 npcs at the same time in Beshara. I tested this on several npcs and creatures. I will do more testing tomorrow, and some much needed cleanup.
I have not looked at any of Zini's additions yet, but they sound good. For additional animation code changes, is animation2 the right place? Or should I make a new branch off master?
