Entities/constraints hierarchy

Post and discuss features you'd like to see in the BEPUphysics library.
Post Reply
Posts: 52
Joined: Mon Jun 01, 2015 9:02 am

Entities/constraints hierarchy

Post by JusTiCe8 » Thu Nov 26, 2015 7:01 pm

Hi Norbo,

in what I'm working on these days, I do something like this:

create entity1
create entity2
create entity3
create joint ent1-ent2
create joint ent2-ent3

and at some point:

in a method or another (very close to suspensioncardemo2 for example).

which looks pretty bad and hard to maintain/evolve.

It would be a lot better to have:

Rentity = create_something()
space.Add (Rentity)

where entity will be kind of a root (like in model meshes, a dummy bone transform), which will take care of every entities and joints inside it (also true for debug drawers).

create_something method containing only entities and joints definitions/relationships.

As for now, unless using a data structure (list, array, anything), it's pretty bad to have "part(s) of a part" (example a wheel and a suspension, to a vehicle body) with some elements are added to space inside a method and the "root" element, or base entity added outside.

An example of use: making independent parts which can be used in any way, having an handle to the whole part to add/remove to/from space and drawer would be great.
I would have parts: wheel1, wheel2 (the wheels include "brakes"), suspension, body I can build a vehicle like:

body body
susp susp susp susp or susp susp susp
wheel1 wheel1 wheel2 wheel2 wheel1 wheel1 wheel2

with only one space.add(body).

What do you think ?

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

Re: Entities/constraints hierarchy

Post by Norbo » Thu Nov 26, 2015 9:39 pm

Going into v2, I would like to keep the API minimal. Since the engine itself doesn't require it and it is easily (and in many cases, best) accomplished externally, this isn't something I would add directly to the engine. In the past, attempts to provide technically unnecessary convenience features inside the engine itself have always backfired in one way or another.

Posts: 92
Joined: Fri Apr 17, 2015 11:42 pm

Re: Entities/constraints hierarchy

Post by mcmonkey » Fri Nov 27, 2015 7:13 am

I keep physics separate from game in my creation.

Basically, I can do:
Entity ent = new CarEntity();

and I've got an entire functional car there and spawned :)

Entity, CarEntity, and Region are all classes I own, and all have custom methods. EG Entity is abstract and has SpawnBody(), and CarEntity extends Entity and overrides SpawnBody with code that spawns all its parts and saves them all in variables in CarEntity (so they can then be mass-removed in the same manner).

(Note: The above is a sample of what my setup roughly looks like, not exact code!)

Unless you're writing a physics demo, there's no reason for the main code to be directly spawning/editing physics bodies, imo it makes far more sense to maintain a layer of abstraction in which all your game-local code runs, separate from where the physics runs.

edit: Oh and this also allows me to keep non-physics entities and physics entities in the same list of entities and treat them all as entities, as they should be treated.

Posts: 52
Joined: Mon Jun 01, 2015 9:02 am

Re: Entities/constraints hierarchy

Post by JusTiCe8 » Fri Nov 27, 2015 4:39 pm

@Norbo: ok, you're right of course.

@mcmonkey: thanks for the tip.

I haven't reach such a point for now where I would need to keep things really apart, the spawnEntity method idea is nice.

In order to get something quickly, I just fill a list of entities and constraints (using either generic object type or ISpaceObject BEPU type), caller process the list (using ISpaceObject type help staying away from dynamic cast or such issue), adding items to space, and relevant ones to the right drawer (model or constraint).

Post Reply