Setting the Body's World

Topics: Developer Forum
Jan 20, 2012 at 2:37 AM

Iis it possible to create a body without adding it to a world ? That used to be possible in 2.0. 

I would like to be able to create a body, then assign it to a world eventually. 

Ex:

 Body body = BodyFactory.CreateRectangleBody(width, height, density...)

// Do some stuff since the world is not created yet.

body.World = someWorld;

Thank you for your help
Jan 21, 2012 at 7:58 PM

Anyone ?

Jan 22, 2012 at 12:03 AM

No you can't do that since Body's constructor calls world.AddBody(this). If you insist you could rewrite the body class a bit, take out the call for world.AddBody from the constructor, make World a public property and add to the world upon set. Not sure why you would want to do that though. 

May 1, 2012 at 12:49 AM
jerrysb wrote:

No you can't do that since Body's constructor calls world.AddBody(this). If you insist you could rewrite the body class a bit, take out the call for world.AddBody from the constructor, make World a public property and add to the world upon set. Not sure why you would want to do that though. 

It's good encapsulation. Personally, I relied on this functionality for my component-entity engine to delay simulation of the Body until the component is manually added to the physics environment by the user. 

May 1, 2012 at 2:25 PM

It's the opposite of encapsulation since a body is in an invalid state if it's not added to a world. You should , at the very minimum, guard its public methods until the state is valid...

By the same reasoning the world member should be "protected set" property (and not "internal" field as it is now).

Box2D does the thing properly by having a separate body (or joint) definition (template) and making the creation of the body simultaneous with adding it to the world. So in a component framework you can lazily create bodies with late evaluation just by storing their body defs. On the other hand in Box2D the world is also a factory for bodies (CreateBody) which is contradictory to the fact that the body can be created on its own. So no OOP design patterns joy there either.

May 4, 2012 at 11:50 PM
Edited May 4, 2012 at 11:58 PM
jerrysb wrote:

It's the opposite of encapsulation since a body is in an invalid state if it's not added to a world. You should , at the very minimum, guard its public methods until the state is valid...

By the same reasoning the world member should be "protected set" property (and not "internal" field as it is now).

Box2D does the thing properly by having a separate body (or joint) definition (template) and making the creation of the body simultaneous with adding it to the world. So in a component framework you can lazily create bodies with late evaluation just by storing their body defs. On the other hand in Box2D the world is also a factory for bodies (CreateBody) which is contradictory to the fact that the body can be created on its own. So no OOP design patterns joy there either.

Which is precisely the reason I'm now going with Box2D.Xna. The latent initialization of physics bodies from definitions just makes things so much simpler for a component-object design scheme. Also I think I misunderstood your original quote, but while the cited example may not be a demonstration of poor encapsulation, it's certainly a demonstration of poor design principles. Having a physics body add itself to the simulation world just breaks with so many physics engine paradigms. Using a Factory pattern is something different entirely, and is acceptable in most cases, IMO, even though Factories tend to be over-blown helper methods.