Rigid body Physics status

#61 Kevin,

I can suggest it because recent survey results (that Melv mentioned) that was performed to gauge what is important to TGB users, physics was not that high up on the list. Furthermore, TGB is a tool that is designed to help people make games, not simply integrate advanced rigid body physics. To this end, TGB has a great deal of other areas in which it could, and probably should, improve before making large API changes for one small subset of game genre or something that will only be a small feature in a game. Puzzle games are not the only genre of game that have no, or minimal need, of advanced physics and one quick look at any game portal will show that to be true. For shooters, adventures, platformers and puzzle games TGB has almost all the physics you will ever need, in fact, it has a much more robust and integrated system for handling basic physics than many other development tools currently competing with it.

I really think that if you're putting that much emphasis on physics in your game design, then you would either:

A.) Use a different tool for the creation of your title that already supports the kind of physics you need. Possibly integrating it with OpenGL or D3D for rendering, OR

B.) Roll your own.

Wes

#62 ... obviously though this can go 'round and 'round forever so let's do something different ...

There are a number of stumbling blocks here to achieve an easy integration of something like Box2D so let's discuss those instead as that'll be much more productive. Also, I'm fairly smart and not scared of any form of math but I'm also *not* a game physics expert nor am I a veteran Box2D user.

With that out of the way, let's talk about those problems and potential ways around them for the future.

Let me start by saying a few things in the open and if anyone wants to break this into another thread then I'll happily repost this there:


------------------
TGB
------------------

- TGB has too much inheritence and doesn't implement certain design patterns which would've made our job easier e.g. Strategy etc. That's my fault and I'll take that one on the chin for the team.

- TGB could and should abstract the col-det/physics where possible. Adding in proxy objects that implement that functionality would at least in theory (not necessarily in practice) make it easier to bring in third-party functionality.

- TGB has home-grown collision-detection which is very fast and implements more features than even Box2D or lots of other col-det available. This code is fairly well centralised and in itself provides swept col-det and picking all with filtering by group/layer/enabled-status.

- TGB has a bin-system that is designed to be a container of objects in a scene for no specific purpose. Filtering is then used to extract a list of objects we're interested in for stuff such as col-det or picking or rendering what's in the "view". We need to be able to support this behavior if we stop using TGBs internal collision-bin system. An alternative is to maintain two bin-systems but that seems expensive and "lazy".

- TGB doesn't implement iterative solvers which is one of the reasons you get jittering. The reason though is performance. Iterative solvers for multiple, simultaneous contacts wasn't and mostly still isn't important. With rigid-body (RB), it's essential. In TGB, RB is <0.0001% of the code!

- TGB mostly seperates col-det from the physics. It's not that difficult to add extra physics and doing so wouldn't change any of the col-det. This is one area where having a Strategy pattern would help.

- TGB physics has stock collision-response routines. It's these that are the basis for physics, not the col-det! Most, if not all, of these can be simulated using RB if you wanted to pay the price for doing so. Maybe the unification would reduce the overhead of using RB, not sure?

- TGB doesn't have arbitrary point rotation support.

- TGB doesn't cap the velocity, mass, size etc of its scene-objects. A good RB simulation needs to do this as it's a fine balance for reasonable forces. This is partly why even the basic RB stuff in TGB can be hard for beginners to configure correcty.

- TGB collision responses can be confusing because some use certain physical properties and some don't e.g. restitution. Most of them though are for RB only. Exceptions are mass/density.

- TGB *is* the editor. You could say the API is T2D. If you want to use the editor then by far the easiest way is to not change the public interface of T2D but replace the internals only and simulate the same behaviour. Not an easy job but definately doable.


------------------
Box2D
------------------

- Box2D has its own collision-bin system represented by its b2World facade. Last time I looked it wasn't easy (but not impossible) to hook into it for auxillary functions required for picking. We'd need point, rectangle, circle and line picking of objects. Box2D has a query method for AABB but it wasn't clear to me then what the next step would be e.g. some (non)swept check against a shape. Maybe a workaround would be to add a shape temporarily into the world, check it and then remove it. I'm not sure if that would be the best way but it's an *essential* ingredient for this integration to work.

- Box2D has filter functions. We need a unified collision-detection / picking based upon collision group / layer. We could happily loose bi-directional collision support but we need to simulate the existing filtering constructs for both standard implicit col-det as well picking explicit col-det. This'd also apply to extra functions such as "CastCollision...." which are really just an extension of picking.

- Box2D has lots of joints (no, not that kind)! These can obviously be used for arbitrary-point rotation support as well as mounting support (or at least the physical aspect of it).

- Box2D has the concept of "static" shapes. These would ease the conceptual barrier to objects that don't want to receive/send collision and are there to simply "block" objects e.g. the ground and general impassable scenery.

- Box2D has the concept of a "world" which would seem the have a nice fit with the concept of a "t2dSceneGraph". Assuming we've got picking supported we can then do a pick-query to determine what's in the view (t2dSceneWindow) and render those objects.

- Box2D provides a simple time-step method that would seem to have a nice fit with the TGB time-ticking.

- Box2D is tuned for MKS (metres, kilograms and seconds). This would be one of the hardests things for starters to understand and it'd also be hard to see how we could easily use the existing spatial defaults for this. Also, some people want to use pixels and they'd need to understand the concept of using "real" MKS values. Not unsurmountable.

- Box2D has wake/sleep support!!! I want this! This should really help with performance.

- Box2D has swept-collision ("bullets") as an opt-in. This can be *very* expensive but is a clear advantage over something like "Chipmunk" which (last time I looked) didn't support this.

- Box2D does have built-in world "boundary" support as well as listeners so supporting some kind of world-limit shouldn't be too hard.

- Box2D has contact listeners but I didn't look into the detail of that enough. On the face of it, it would seem that support for per-collision callback (yuck but lots of people need it) could be supported.

- Box2D is obviously evolving disjoint to TGB. This means we really need to ensure we use the public interface to Box2D since it began making stuff private/public (didn't always do that AFAIK). If Box2D changes, we need to ensure that we've not got a major merge on our hands. Using the public interface should reduce this workload although not necessarily remove it.

-----------------

Let's discuss. Any Box2D veterans out there (Michael I'm looking at your from across the room) please join in and please feel free to correct my misunderstanding and/or assumptions!!!! :)

Also, I'll say again that this is my personal exploration, not on behalf of GG. If there was a way through this minefield then I'm sure I can get it on the product road-map. I don't see any of this being that complex or massively time consuming. I do see real problems to ensuring a we get a good fit between the TGB and Box2D systems. There's also the question of how bound should we be to Box2D and therefore the question of how abstract should we be from the col-det and physics work-horse code.

Melv.

#63 This is exactly what I am writing about in my thesis right now.

A few other things that I found were:

- Box2D does not support ellipses as collision shapes, TGB does.
- Box2D does support multiple shapes per body. TGB doesn't. It would really be a shame to lose this feature.
- CLAMP and STICKY cannot really be simulated by RB. You can get close to CLAMP I guess but would still have inertia as a problem.
- That's rather an implementation detail: Box2D uses placement new a lot in its custom allocator. I had to turn off Torque's memory manager in my wrapper. There may be ways to keep the TMM but I have not spent any time in trying to do so.

I am still in the process of finding more points here. However, I was able to collect a little experience in using Box2D over the summer so here are some points that might interest you:

- Box2D does support collision filtering customization via implementing a callback interface. It would be quite easy to let it use TGB's filtering criteria.

- b2World and t2dSceneGraph are a perfect fit :)

- The Box2D contact listener does *only* support per contact-callbacks. You cannot exclude single objects from being reported. In our project at university I created an adapter that did let you subscribe to callbacks for certain objects. That works really well in our case but I don't know what the performance overhead would be in a more stressful environment with all that event routing and virtual method calls.

- In Box2D you can specify a world boundary but it is global, not per-object. Objects that touch the boundary are not integrated anymore. They also trigger the b2BoundaryListener if one is installed. That's not really what world limit does.

- Box2D only allows for AABB queries in the b2World but as far as I know the b2CollideCircles(), b2CollidePolygonAndCircle(), and b2CollidePolygons() functions in b2Collision.h are accessible from outside the library so the narrow-phase can be easily re-created. There is also a b2TimeOfImpact() function that might allow swept collision checks (in contrast to the other three). I have not tested any of these though.

-Michael

... edited for typos

#64 ... can't wait to read that thesis if it's ever available. :)

Melv.

#65 Melv,

we should not be bound to Box2D at all if possible :)

#66 Melv, just thinking outloud, but is it not possible to add into tgb's exsisting rigid solution? like joints, pivots etc for those who need it? or add a new extended rigid class or would all that just get messy?

going by the exsisting arguments it would be better to add to whats there?, maybe have the option to use full physics if needed and try to keep the exsisting light physics?

and just for reference, is there a 2d engine out there as cool as tgb with full physics support?

just my thoughts on the topic at hand, i make no claim to know what i am talking about ;)

#67 You can overlay a Box2D world onto a TGB world but not easily integrate it so whilst the worlds coexist, they cannot interact unless they share a common grounding.

TGB objects interact because they're all in the same container system e.g. world. Performing a query such as asking what objects are in a certain region requires that all the objects are in the same "container". Box2D has its own world-container as does TGB. You cannot fuse the two and you cannot just swap over from one to the other.

You could then start thinking about leaving non RB objects (TGB objects) as they are and Box2D (RB) objects in their own container and then do some cross-coordination of queries which unfortuntely gets very messy and would give bad performance.

You could add proxy objects in the TGB side which represent objects in the Box2D world but the problem then becomes one of updating those proxy objects because the objects are stored by their position/orientation and the container must always be up-to-date.

If you want to keep the worlds seperate and don't have RB ever interact with non-RB then it becomes much easier. The problem then becomes one of not inheriting support from TGB for mounting etc. You then have to add special mounting calls (or proxy them) to the RB objects.

I'm not sure if I explained that well enough. Essentially there's several ways forward which all have pros/cons. The subjective "best" would seem to be to abstract the col-det/physics completely and always plug-in one system (never use multiple ones simultaneously). That abstract interface isn't that difficult if you consider some systems already define that interface and so you could sit on the shoulders-of-giants on that one.

I'm sure Michaels thesis would explain that much better. :)

Melv.

#68 Oh, I forgot one integration problem before:

- Box2D bodies/shapes cannot not be resized. This can be simulated though by destroying and re-creating the object at a different size, which sounds a bit costly in terms of performance.

#69 Ouch!

I guess as long as you know that its potentially expensive then you can deal with it. An existing TGB owner would probably be the person who'd not like a resize performance hit.

It does seem to me though that a model to adopt would be one of components where the component provided the functionality and maintained the appropriate state. This is where the GG engines are going anyway to drive, amongst other things, modularity.

For the moment, it makes sense that "picking" uses the same container system as the collision-detection but that doesn't necessarily have to be the case. A "picking" component can decide whether it's capable of hooking into the state of a collision-detection component or whether it needs to roll-its-own state to maintain that picking functionality. Add to these components a well-factored interface and you've got a way forward.

In more concrete terms; adding a "picking" component to an "object" and a "rigid-body physics" component to an object should be possible. The trick is how the "picking" and "rigid-body physics" components would interact because they obviously share and, in the case of rigid-body physics, one drives state of the other or one is a visitor and one is a subject. The "physics" component could expose a Strategy interface which allows a concrete implementation for TGB, Box2D, Chipmunk etc.

In other words, the problem still exists but it's in a much more formal and definable basis.

This is one of the most important aspects for future TGB design over-and-above this threads' subject and would hopefully subsume some of the discussion here.

Melv.

#70 The question is whether there should one "physics component" at all. There could be different components with different interfaces that do more or less the same and which exclude each other. There could be a Box2dPhysicsComponent that exposes everything Box2d bodies can do. And there could be a ZeldaStylePhysicsComponent that can't do much at all, because it does not need to. The scenegraph could then have a Box2dPhysicsManagerComponent containing the b2World. Or it can have a ZeldaStylePhysicsManagerComponent that does everything that is needed in that case. It's pretty obvious that these two systems exclude each other but that's ok.

I guess the problem with this approach is that each of them would need their one editors. Except if all of them would be required to implement a least common denominator interface. E viola, we have a "physics component" again. Or at least a physics component interface...

#71 Certainly if you're going the composite route you'd definately want to keep the components as focused as possible keeping to the single-responsibility-principle.

Even if it makes sense that certain features in the physics component come together I'd still supply them as a true component composite. The component interface or the editor shouldn't see the component as an individual component or a composite of components as is required of an object implementing the composite design pattern. If not it's just an aggregate pretending to be a composite. ;)

I wish we could adhere to the clean-slate-principle which states, "moving forward with backwards compatibility majorly sucks".

There's alot of work going on (has been going on) in the Garage using components and it's a major part of the next-gen engine.

Melv.

#72 I think I don't get your point here? Can you elaborate on this a bit?

#73 Certainly.

I'm really just backing up what you said but adding that the concept of a single "physics" component is quite large so my point was to break that down and use a composite component e.g. a component that can be composed of different components but still act like a singular component.

Components can then become:

- Core Physics Component
- Rigid-Body Physics Response Component
- Bounce Physics Response Component
- Static Physics Response Component
- Contact Physics Callback Component
- Wake/Sleep Physics Component
- CCD Physics Component
- etc...

You can then add a component to the "object" that is a composite of the above say:

- Core Physics Component
- Rigid-Body Physics Response Component
- Wake/Sleep Physics Component

... to get a physics component that provides a rigid-body response that supports wake/sleeping.

In the above example I created a wake/sleep physics component instead of adding it to core physics because I considered it better to factor out that functionality. Also, when swapping around different physics "providers", I can work out what components are available to be linked-in. There's also the potential for increased performance if a component does extra work rather than always doing some work with some defaults.

Of course the above can be changed in name for "Box2D Core Physics Component" etc.

I just prefer the use of composites because of the dependencies implied but of course you can use registration for that purpose as well.

Melv.

#74 OK, now it's clear. Thanks a lot.

But one problem (at least ;) remains: A bounce physics response component and a rb-physics component would exclude each other, right? How do you prevent the case that both would be added to the same composite? Without hard-coding anything and knowing the list of possible components beforehand?

There could be something like "categories". And only one component is at most allowed per category. Then the above mentioned and any future components that handle collision response could belong to the "response" category. Does that make sense?

#75 It does make sense. There are several ways of doing this, one of which is to use a builder to provide the composite and it can use an external configuration file to make that determination (XML). That file could be as simple as stating dependencies but could also include stuff like compatibility of components as well as defaults for properties etc.

In this respect you don't go around doing the low-level work like creating and hooking up components but give that responsibility to the builder and you also leave it open for extension (the XML file) which is what the open/close principle is all about.

I know it seems as if I've just swallowed a design pattern book but it pains me to see the lack of established design pattern usage in TGB so that when I look at moving forward, all I see is how it should now be!

It's likely that the next steps in TGB won't result in a major rework but to solve a number of issues that are very high on the list of stuff being asked for. We will be looking at doing a TGB in a component form though simply because that's where GGs engines are going as was stated previous by GG.

Melv.

#76 Yes, using a builder really sounds like the better solution. I am looking forward to seeing TGB's future development :)

#77 I have a quick tgb physics question for you Melv. Why does t2dPhysics.cc have 4 space tabs while the rest of the engine has 3? It's your fault isn't it! '-)

#78 What the standard is has changed a few times in the Garage or at least a recommendation by various folks. That's the reason why some of it may be inconsistent.

For a long time it was spaces of 4 but a lot of TGE is spaces of 3.

I personally prefer 4 because I like a non-trivial indent to the code and I'm happy with spaces or tabs. Spaces are obviously better when using different environments to edit the code.

Melv.

#79 Vote 1: 4 spaces!

#80 Michael,

Can I call on you to have a chat about physics and your findings on Box2D in the next few weeks? Do you google-chat?

I'm particularly interested in your results on what's not (easily) possible using rigid-body.

Melv.