Ybalrid / Annwvyn

Annwvyn C++ Open Source designed-for-VR game engine and application developement framework
MIT License
41 stars 7 forks source link

Permit GameObject parenting #67

Closed Ybalrid closed 7 years ago

Ybalrid commented 7 years ago

Relatively small change to be done, but the API doesn't provide a way to attach object to other object. The underlying node system of Ogre is based on this, yet everything is the code has been thought as in "world" position/orientation/scale.

Attaching Object nodes to other objects should not cause any problem.

Ybalrid commented 7 years ago

There's quirks with the physics engine.

Everything works with world position, so I changed how the RigidBodyStateset the position/orientation to use the "derived" ones. This works fine.

However, having a parent/child relationship with 2 object having a dynamic rigidbody will do super weird things, especially when bullet will put bodies "asleep" to save resources when they aren't interacting with anything, so their position will not be updated in the physics engine, so they will be free to "drift" with their parent, and jump back to their intended position.

So, to prevent this the only good solution I have is to prevent this situation from happening. The engine will throw exception if you're trying to construct something convoluted like this.

Otherwise, syncing position of audio sources is a no-problem and has been dealt with in #69 already.

For now the engine don't give easy access into the constraints and joint systems available in bullet. this may be useful to think about that.

I'm probably going to do the merge on the opened PR but I may have to tweak a bit more theses things. The API of AnnGameObject has been extended quite a bit and the distinciton between moving "relative to the parent" and "moving in the world" is not that clear.

Also, just to be sure I want to check the source code of Ogre to see what's exactly happening when you call {get,set}Derived{Position,Orientation}. Apparently they are marked with the "" prefix (for the Ogre project, this means that it's for internal use) because it causes problem when calling them in bones. But I'm dealing with SceneNode, not Skeleton