Hey everyone.
I was looking at adding the ability to modify collision groups in game a while ago. It worked unless two objects were already colliding, in which case they were already included in the collision cache.
After some more thought, I’m also working on a new multiplayer system for my projects and I want to enable the ability to change some physics options. Therefore, having the ability to be informed of collisions and to modify collision layers and masks would be a useful thing.
The problem is that I don’t have all the time to look at this at the moment. I am asking for someone to help implement these features.
To implement Python callbacks to Bullet’s collision code.
Adding a collision callback to the KX_GameObject class:
KX_GameObject.addCollisionCallback(PyObject){
returns: Int (id)
}
KX_GameObject.removeCollisionCallback(Int){
returns None
}
Whenever the object’s collision status changes, it would call this function with the colliding object and the status of collision. See this psuedo callback:
def collision_callback(KX_CollisionObject collision):
# Status of collision (start or end)
status = collision.status
# Other collider
obj = collision.object
if status:
print("colliding with {}".format(obj.name))
else:
print("separated from {}".format(obj.name))
The issue I can foresee is that if the GameObject is deleted before the collision stops, this would raise some error. However, simply defaulting to None or an invalid gameobject reference would be acceptable.
Whether or not one would need to consider changing the existing api for the KX_GameObject (to return generic features, moving the bullet features into the RigidBody objects as Panda does) remains to be seen. At the simplest the following features would be useful to expose:
Exposing full gameloop behaviour to the API Current we have access to the game loop next_frame() through the HIVE commits. However, there is no ability to step a single component of the gameloop. Instead we can only tick a single NextFrame. It would be useful to be able to specify the tick order, and when we wish to tick certain components. It may make sense to put these in a separate module, like bge.gameloop:
tickPhysics
tickRender
tickLogic
tickSound
These components would use an internal clock for the delta time.
yes also the mask that fail the first frame is a bit annoyng…
would be nice having some option more from bullet, overall change physic as from static to rigid body.
this overall to workaround a lot of annoyng bugs that there actually as the parent static bug that transform a obj dynamic in static
this make very hard to do rigidBodyJoint
a demolition of a house simply transform a hose static in a house softBody
then after a bit can become no collision
then maybe start also some obj as sensor collision , in this way the calculation starts only when need (FPS advantage)
for example : if nearSensor (big) -> start and check other sensors(head , body , hand, etc)
The problem with giving the user more control over the game loop is you’re taking that control away from the engine, which means less room for optimizations. For example, I’ve been looking into multi-threading the BGE’s game loop. If we cannot guarantee the order of execution of the game loop, we could only parallelize each component, which would introduce a lot of barrier synchronizations, which would slow things down.
Even enabling a switch would be good. It’s fundamentally limiting that one cannot call a new physics tick per frame. If we could access GameObject data pre draw that would be somewhat better, but not fully there.
I think you love the concept of listeners/callbacks. I agree with Moguri this weakens the abstraction layer of the game logic. The code does not run in the expected context (when the controller gets executed).
I suggest to skip the callbacks completly and wrap this processing with a sensor. The CollisionSensor would be the perfect place to do that. This allows you to present the result of multiple physic substeps in one logical frame as well = no problem with the different frame rates anymore.
I agree it would be nice to get some more data out of Bullet. E.g. Impact of colision. Colllision areas etc… I do not know what bullet offers via API.
Again, the sensors sense into the system. Bypassing the SCA event system is not the best design desision. If colision testing is necessary the collision sensor is the place to ask. Its existence shows there is interest in this information.
The difference to the raycast is, that collisions are calculated anyway.
The question in asking is why must j run in a limited context for scripting in the first place. HIVE already has some control over the game loop, and you can now run logic outside of any controller brick. Networked physics needs authority over the physics directly.
So you are writing exclusive for Hive? I though hive plugs in on top of the current logic.
If you want to enhance the API you should focus on existing API rather than any future thingy.
Regardless of that, what you want to do should be implemented in a way that it works for the current system first and maybe for future enhancement as second priority. Finally it should not establish a different system. Especially as there is no need to do that.
The problems you describe sound more like a design problem rather then technical problems.
Firstly, the SCA concept isn’t all there is here. There is also HIVE.
HIVE is built upon the BGE API, but not on the SCA system. The system I’m designing doesn’t require HIVE however, I am merely saying that HIVE would benefit from collision callbacks too As would the ability to tick components separately.
I am also stating that the fact HIVE exists is a pointer that the SCA system is only one system. The idea is that I can run this without forcing the user to use HIVE or LogicBricks. Ideally, this would be used instead of them both, for it is designed to encapsulate the entire Engine in its operation.
In reference to you point about design;
This isn’t a design flaw. The necessity for collision callbacks is that the user can then design around a Python class rather than around a physical object. This means that one may re-use a graphics mesh without having to change logic on it. It also means that everything sits in one place. Furthermore, one cannot write an authoriative physics simulation without the ability to correct the mistakes. As well as this, the results of any physics modifications (e.g velocity) do not take effect until the next logic frame. As one cannot access game object information in the pre_draw callback, then it is actually impossible t send the result of an action on the same frame it was processed. Because of this you loose determinism and in order to try and compensate for this you must add a lot of boilerplate that needn’t be there.
It’s impossible to network physics in an authoritative manner without the ability to tick more than once per logic frame. Not a choice, just impossible.
Agoose , in simple words , is possible “move forward” a cube with HIVE ? i have yet blender 2.64a (but i can download 2.67)
if yes , there some tutorial ?
PS: i guess that a different order of gameloop would be a bit better
now is logic->physic->render
is not better
physic->logic->render ?
PS2:SCA is not a good system
think what happen in python if you are forced to subdivide the script in more step ,
a “POS” system internal in python:
P -> change position
O -> change orientation
S -> change scale
imagine what mess if you need to a different order … i see SCA in the same way …
SCA should be joint in one step single . maybe some task can still in the actuator (as end object) but few things…
Firstly, it’s not that the current game loop is ‘bad’. It’s actually the traditional order (the idea that a game is render based) meaning that your logic has a visible effect the same frame. However it means that you can only read the result of your physics operation at the start of the next tick. If we had access to the game objects in the draw callbacks then we could read the effect of the physics update. However it still doesn’t allow us to perform ‘resimulation’ if something needs to be corrected.
HIVE currently works it’s just that we don’t have any specify BGE workers or drones other than one or two basic ones. Once the gui is implemented we can look at it more robustly. There is work planned in about two months from sjoerd and myself.
