Internalize Entity CoGToModel

Post and discuss features you'd like to see in the BEPUphysics library.
Post Reply
Abuzer
Posts: 20
Joined: Thu Jan 19, 2012 4:12 pm

Internalize Entity CoGToModel

Post by Abuzer » Mon Jun 11, 2012 7:58 am

This might have been suggested previously, but I figured given how many people seem to be running into this issue and how some might expect a physics engine to "internalize" some of its details unless asked for, I wanted to suggest a feature where BEPU allows the use of a "local position"-like offset for the entities.

At a first glance, I'd expect that once an entity is created and the CoG (Center of Gravity) is determined, the user should be able to assign a Vector3 var (like CoGtoLocal) that would internally be used whenever a WorldTransform, Position, Orientation etc. is accessed either thru the getters or setters. This would potentially remove a good deal of the headache involving the book-keeping of model to physics entity positioning. This seems to get even more unwieldy when you have a model that has several pieces broken up into separate entities, and each one of them uses a different offset.

I don't know if it's common practice for physics engines to assign the origin on a physics entity to be its CoG or perhaps there are some underlying reasons why this wasn't done. In any case it'd be curious to hear about it.

Cheers

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

Re: Internalize Entity CoGToModel

Post by Norbo » Mon Jun 11, 2012 4:22 pm

If this is targeted at addressing shape recentering and graphical offsets, then the offset has no functional value to the engine itself- it would just be an extra layer. Since such a layer is trivially implementable externally from a more relevant context (game logic/graphics systems) and implementations could vary, it was excluded from the engine itself. There is value in simplicity and directness in design; automating things to make things seem simpler can backfire.

For example, if the offset is assigned automatically for shape recentering, the user could run into a situation where the Position does not reflect the true center of mass anymore, thus requiring an understanding of shape recentering (after spending some time being confused as to why they could not find the center of mass). If the offset is not assigned automatically, the user must still understand shape recentering again to choose the right offset. In the former case, the automation arguably has negative value; in the latter case, it has close to zero value since the transform process can be easily done outside of the engine in a custom layer.

Additionally, if another property is added to expose the unmodified states, the Entity gets pretty polluted. These changes would also propagate through the buffered/interpolated states systems, adding extra complexity. Earlier versions of BEPUphysics actually had a setup like this (with slightly different goals); the extra complexity caused noticeable confusion and it was stripped away in v0.15.0.

From what I have seen, the difficulty associated with shape recentering does not come so much from the act of applying the necessary transform to the graphic (since it is so easily handled with a layer), but rather understanding where to get the information and why it is necessary to do so. New users tend to start with something like Boxes and Spheres and are free from shape recentering, so they develop certain intuitions about the process of setting up graphics. Then, when ConvexHullShapes, MobileMeshShapes, or the other 'weird' shapes get involved, suddenly the user has to learn about the existence of CollisionShapes and this not-so-obvious recentering process. Even with the dedicated documentation and demo (and the following reduction in related questions), I don't feel like this is adequately explained/easy enough to do, especially for people who are less experienced with transforms/graphics. It seems likely that a 'proper' solution would be some sort of obvious unified framework across all the shapes for easily extracting the necessary data rather than the current per-type disparate methods. I'd like to add something like this, I just haven't gotten around to it.

On the other hand, if you weren't targeting shape recentering with this suggestion, I'm afraid I may have missed the point :)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest