Skip to main content
gamedev.net
🔒 Locked 🎮 Unity

OOP design question.

Started by daniel_i_l Apr 5, 2009 at 3:52 PM 4 replies 1.1k views
Original Post
daniel_i_l
daniel_i_l
I'm currently trying to design a physics engine. The engine is constructed of objects of the RigidBody type. Since I want to experiment with different ways of partitioning the object space I want to make a base class "PartitionedSpace" which the different methods (trees, grids,...) can inherit from. The interface of this base class gives the client the ability to add RigidBodies to the space, update the position of the objects in the space upon movement, and get a list of potential collisions. I have two questions about this: 1) Since every type of space partition will need the objects to store different information (such as cache information from the last collision checks) where should I store this information? It can't be stored in the RB itself because then I'd have to change the RB structure whenever I wanted to try out a new partitioning class. Should every partitioning class have it's own wrapper for the rigid bodies that it hold and store the information in that wrapper together with the RB? That seems sort of wasteful to me. 2) I only want to update the positions of the RBs in the partitioned space if they move. Does that mean that each RB will need to have the ability to update itself whenever it moves? If that's true then how can that be implemented without each rigid body having to point to information in the PartitionedSpace class? Thanks.
"We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the internet, we know this is not true." -- Professor Robert Silensky
ApochPiQ
ApochPiQ
Just a random suggestion, only answers half the question but I think it should get you started:

class PartitionedSpace{   // Shtuff.};class ParticularlyPartitionedSpace : public PartitionedSpace{   // Shtuff.private:   struct PartitioningInfo   {      // Track here anything you need - bounding volumes, whatever.   };   std::map<ContainedObject*, PartitioningInfo> ObjectPartitionInfo;};



Now you can cram your implementation-specific information into the std::map; the advantage of this is all you need is a pointer or reference to the object you want to look up, and voila, there's all your data.



As for moving things: this depends on who is responsible for moving RigidBodies around in the universe. How are you planning on making things actually animate/move?
daniel_i_l
daniel_i_l
Quote:

Just a random suggestion, only answers half the question but I think it should get you started:

That looks like an interesting idea. I think that I'll try it.

Quote:

As for moving things: this depends on who is responsible for moving RigidBodies around in the universe. How are you planning on making things actually animate/move?

I'm going to have a seperate "Simulation" class that move the objects. I'd like it to be able to call: PartitionedSpace.update_body();
After the idea of using the map that you posted it looks like I can put a pointer to the node that the RB is in inside the PartitioningInfo class. Then the PS would be able do check if a RB was still inside it's node or not via it's PartitioningInfo. Is that a good idea?
Thanks.
"We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the internet, we know this is not true." -- Professor Robert Silensky
ApochPiQ
ApochPiQ
Yep, that sounds pretty much like how I would do it. Of course it may also make sense to tell the partition classes to move their contents, so they can do so in an optimal way for each partitioning scheme.

For instance, if you have a bounding volume hierarchy, it may be most efficient to tell the BVH class to move one of the contained entities, which should just be a transformation of a couple of bounding nodes, plus of course recomputation of the higher levels in the hierarchy. This way objects (bodies) don't have to know anything about how they move or even about the fact that they are stored in a partitioned space system.
daniel_i_l
daniel_i_l
Thanks. If I understand you suggestion it's only for partitioning schemes that relate to the objects themselves - like a BVH, and not a global partition like an octree. Is that correct?
Thanks.
"We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the internet, we know this is not true." -- Professor Robert Silensky
ApochPiQ
ApochPiQ
For something like an octree, IMO it still makes sense to tell the partition class to move the contents. The octree implementation should know where to place the moved item(s), but you don't want that implementation detail to leak out in the interface, so having the partitioner do all the work seems to be the cleanest approach.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.