Page 1 of 1

Entities/constraints hierarchy

Posted: Thu Nov 26, 2015 7:01 pm
by JusTiCe8
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:
Space.Add(entity1)
Space.Add(entity2)
Space.Add(entity3)
...
Space.Add(joint1)
Space.Add(joint2)
...

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 ?

Re: Entities/constraints hierarchy

Posted: Thu Nov 26, 2015 9:39 pm
by Norbo
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.

Re: Entities/constraints hierarchy

Posted: Fri Nov 27, 2015 7:13 am
by mcmonkey
I keep physics separate from game in my creation.

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

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.

Re: Entities/constraints hierarchy

Posted: Fri Nov 27, 2015 4:39 pm
by JusTiCe8
@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).