Box2D Forums

Yeah the way it's broken out should work just fine.
I love seeing those dynamic bodies just bounce off really thin static
boxes btw.. it's almost like magic!
Mike

Somewhat thematically related to "fast" being an application-side decision, it would be helpful if the unit scale were settable by the application. Compiling the Box2D library with pixel-scale units makes the Box2D demo application flake out, but I need pixel-scale units for my application. While I do statically link Box2D with my application, I'd prefer to leave its source code "pristine". (I don't think it would make much difference from a performance standpoint.)

Is it possible that your CCD implementation affected the Pyramid test? Now when I load the test, before I even touch it, a few blocks fall off the tower. Should it not stack perfectly? It looks like a lot of weight is being applied to the center of the tower, which is causing some deformation which throws a block off. Even if this was the correct simulation, shouldn't the destruction be symmetrical (or was the tower not quite symmetric to begin with?)

I just ran the old simulation of the pyramid (1.4.3)...it actually produces a similar affect (you can see a sort of ripple from the center to the upper right -- where the block got knocked off in 2.0.0, but it doesn't become deformed as much.

Is it possible to give the blocks a more concrete feel? They sort of look rubbery with the compression...but I assume that's just a side affect of the not-quite-perfect simulation?

Please forgive me if I'm being naive.

The CCD test looks promising anyway

kdmiller3:

Many of the settings in b2Settings.h have to be hard coded, so that arrays get the right size. This should be the only file you may need to customize for your application. I see this as a benefit of an open source design. You can customize some settings that get baked into the library. Some commercial libraries are only tuned for meters.

On the other hand I can see your point, since there have been many version of Box2D over the last few months. The project is still young. Once it matures you should see less frequent updates.

I suppose that values that are not related to array sizes could be made into non-constant globals that are tunable at run-time. Accessing these may cause some cache misses.

darkzerox:

I discussed this instability in an earlier post. I will address this soon. Contact points are processed sequentially, so you don't get a symmetric solution.

The pyramid test is more of a stress test than a demo. If I wanted it to appear more solid, I would do what other demos out there do: start the bricks already stacked instead of dropping them and perhaps make the lower bricks non-responsive to the movement of upper bricks.

Would this be a better & simpler method for enabling CCD?
Instead of 3 categories have a CCD velocity threshold setting
for each body? I guess that would be the most general since you
could set the value < 0 to always enable CCD and 0 for never use
CCD or something similar.
Mike

Fair enough.

The unit scale factors were the most likely tuning parameters that applications would want to configure, but making those non-constant would force the dependent values to become non-constant as well. Then the dependent values would need to be set by an accessor function when the unit scale factors changed, and then everything gets all complicated...

Mike: That's a good idea, but I'm concerned that people might have trouble picking the threshold. Let's see how far we get with the flag. If it works well then we'll have the simplest solution.

Thanks!
Yeah I see your point. I agree tunable parameters should be minimized.
I bet 90% of the problems people have with physics engines involve the tunable
parameters.
Mike

As long as the flags can be changed during the simulation, it should be a simple exercise for each application that needed it to set up its own handler that marks fast moving objects as such, based on what "fast" means for a particular game - will that work right, or is there persistent information that needs to be stored in order to do CCD such that you'd really need to mark the object at creation?

Flipping the flag will work. Great idea! I'll make sure there is an accessor.