Real-Time Physics Simulation Forum

but it should be called 'instant velocity' instead I think. I believe that can work. Correct me if i'm wrong. Yup, it is technically velocity, and a perfectly good way to do it is though calls like in the motor control (dynamic control) demo. Just replace the joint angle with a velocity. Problem st...

There's VS2010 projects in the build folder, just import that and let VS2012 up-convert for you, no need to deal with cmake.

I based my comment on playing way too many old school games. In things like Zelda and Pokemon, you can interact with the environment and enemies to a certain extent, and your character can get bounced around pretty well without using "real" physics. On a 2d plane, it's pretty straight forw...

Sounds like you're over-complicating what could just be very simple stuff. Ignore actual simulation, just use the collision detection if needed, though if you do it the jrpg way even that isn't really needed. Since it sounds like you are going for the 8bit style, why not just check every screen upda...

These bodies should be kinematic ones rather than static or dynamic, that is that they interact with dynamic objects but are not simulated themselves. That would let you avoid any constraints, let you move them around as you please, and lower simulation times too.

Bullet is typically single threaded, but there's multithreaded demos in the source (though they lack great documentation). If you haven't switched to it, might as well try. Is your calculation so difficult that you need more power than the multithreaded code? If that's the case, you can wait til Bul...

Are you sure the issue is with bullet and not your graphics engine? You'll need to turn on a profiler to see what's taking up your cycles. Even with 600 simulations a second at 10 iterations for a hundred objects, any cpu better than an old E8400 should be able to do above 11fps without really worry...

I do agree that there is little to be "worried" about here. The truth is, people in actual game companies working on actual games (like Dirk) already have their benchmarks, and already know these results. The posts were specifically targeted at clueless morons on the internet. At the end ...

Sadly they have no mention of powered joints in that. Considering Nvidia is touting PhysX's pseudo-Featherstone as a plus, it would be interesting to see physical accuracy and speed comparisons. Should also be interesting to see what happens when Bullet 3.x finally gets released (keep hearing "...

I find that increasing the motor iterations works well, as well as increasing the simulation rate (though that brings it's own problems.

you're intending this to be for realtime use (i.e. stepping physics at < 60Hz and just a handful of iterations) I have a 18 joint model that runs at 300Hz with 100 joint iterations in about 5ms with a 2.0GHz cpu, so you can easily increase it as long as you don't have a ridiculous number of joints ...

Sounds like the same problem I had with the hinge constraint the first time I tried them. I ended up increasing the stop ERP parameter to 0.8 like so: setParam(BT_CONSTRAINT_STOP_ERP, ERP, 0); STOP_ERP actually does nothing to improve motor strength in the "chain" model. setParam(BT_CONST...

I've been trying to use hinge motors for a 18 servo chain (think CMU robot snake), and come across some rather odd situations. Unless the number of iterations is quite high, maxImpulse increases to the angular motor don't seem to work at all, regardless of max_impulse (tried a million times higher t...