Need helping finding solution to design goal

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
twig314159
Posts: 7
Joined: Thu Apr 28, 2011 5:31 am

Need helping finding solution to design goal

Post by twig314159 »

My intent is to write a little game in which the player can move an object around and pick up other objects.

In a perfect world, with a perfect engine here's how I want it all to behave:
- Player moves their object via input device.
- When colliding with another object, the player picks up that object and welds it to the player's object at the contact point(s).
- The new player object treats itself + new objects as it's full collision space. Thus if one of the welded objects contacts a wall, the entire collection stops moving in that direction.
- Each attached object needs to have it's own collision information and event handler.

Basically, I want the entire collection of welded objects to behave as if it is one big CompoundBody with regards to movements and to impassable objects (like walls). I also want the entire collection of objects to behave as if they were all independent bodies connected with WeldJoints. By remaining distinct Entities, they can each handle there own collision events.

Things I've tried:

Attempt #1: Using distinct Entity objects and WeldJoints to connect them all.
Problems: When the root object (the player's Entity) comes in contact with a wall (Terrain) the player's object responds and everything stops moving as expected. But when child Entity (which is connected via WeldJoint) comes in contact with the wall (Terrain) the wall puts up some resistance, but since the root object is still moving, it essentially pushes all of the child objects through the wall. Also, performance really suffers once you have about 600-700 child objects all welded to the same parent object.
Desired behavior: When a child object contacts a wall, I want the entire collection to halt movement.

Attempt #2: Using a MorphableEntity that has a CompoundBody. When a collision is detected, I remove the child object from the Space and recreate the root Entity's CompoundCollidable to include a CompoundShapeEntity in the same relative location as the child object.
Problems: Because CompoundCollidable is a collection of shapes, that collection can only have a single collision event attached to it. There's no nice way for me to discover which shape in the collection was actually collided with. The only way I've come up with to do that is to compare the contact points of the collision with each shape in the collection.
Desired behavior: To easily know which shape(s) were involved in the collision.

I have thought about combining my two attempts, but that feels redundant to me. I feel like I should be able to get the behavior I want without resorting to strange setups.

For the curious here's the strange setup I'm picturing:
- Maintain two sets of Entities that overlap each other, but don't trigger collision with each other.
- One set is the collection of Entities from attempt #1 that are welded together. These respond to individual collision events with other objects (but not walls!).
- The other set is a single MorphableEntity/CompoundBody from attempt #2. This entity responds to collision events with walls, but not other objects.

Thought? Is there a better way to get the behavior I'm looking for within the physics engine?

Thanks,
Twig
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Need helping finding solution to design goal

Post by Norbo »

But when child Entity (which is connected via WeldJoint) comes in contact with the wall (Terrain) the wall puts up some resistance, but since the root object is still moving, it essentially pushes all of the child objects through the wall. Also, performance really suffers once you have about 600-700 child objects all welded to the same parent object.
The pushing-through-the-wall issue sounds like a mass ratio style problem. If the primary character is very heavy relative to the connected objects, it is very hard for the solver to handle the constraints. Increasing the iteration count or reducing the mass ratios can help this issue. With many hundreds of objects connected by constraints, the performance is definitely going to be problematic.
Because CompoundCollidable is a collection of shapes, that collection can only have a single collision event attached to it.
It is a collection of shapes, but it can be constructed using CompoundChildData structs instead of CompoundShapeEntry structs. CompoundChildData structs include a CompoundShapeEntry as well as other things, like the events manager, collision rules, and material. There is one sample usage of this in the demos, in the RobotArmDemo, where collision rules are specified for subshapes. This mode of setup (along with other nontraditional entity construction methods) could use some extra samples.
twig314159
Posts: 7
Joined: Thu Apr 28, 2011 5:31 am

Re: Need helping finding solution to design goal

Post by twig314159 »

Norbo wrote:The pushing-through-the-wall issue sounds like a mass ratio style problem. If the primary character is very heavy relative to the connected objects, it is very hard for the solver to handle the constraints. Increasing the iteration count or reducing the mass ratios can help this issue. With many hundreds of objects connected by constraints, the performance is definitely going to be problematic.
My root object does have a mass a thousand times the mass of each child object. I want all of my objects to behave as if they have no mass as all. If they all had equal mass, the root object moves slower as it accumulates children because it's mass relative to the collection is getting smaller. Increasing the root mass many degrees of magnitude above the children was my workaround for that behavior.
Norbo wrote:It is a collection of shapes, but it can be constructed using CompoundChildData structs instead of CompoundShapeEntry structs. CompoundChildData structs include a CompoundShapeEntry as well as other things, like the events manager, collision rules, and material. There is one sample usage of this in the demos, in the RobotArmDemo, where collision rules are specified for subshapes. This mode of setup (along with other nontraditional entity construction methods) could use some extra samples.
Thanks for the tip. I'll check out CompoundChildData more closely. I had seen it before, but in the process of learning the physics engine, I stuck with CompoundShapeEntry because their usage was clearer.
Post Reply