where is m_gravityScale?

[rjdgtn]

Why you remove m_gravityScale? What is your analog?

[louis-langholtz]

Hi rjdgtn,

Thank you for asking!

By m_gravityScale, I think you mean the b2BodyDef::gravityScale and b2Body::m_gravityScale member variables.

I had removed these because b2Body::m_gravityScale was associated with an additional multiplication operation within the island solver in more performance critical code (specifically in integrating velocity as v += h * (b->m_gravityScale * gravity + b->m_invMass * b->m_force)). By combining bodies' m_gravityScale with world gravity and bodies' m_force variables, the calculation of the new linear velocity (v) effectively reduced to v += h * body.GetLinearAcceleration(). It also reduces the memory size of world and body instances (since they need to remember less data now). Note that I removed body forces and non-persistence of these also so that a body's acceleration setting contains this all now.

The closest analogy to these original variables are the BodyDef::linearAcceleration, Body::m_linearAcceleration, and World:: m_gravity member variables. So if you want a body to have an acceleration different than the world gravity, that acceleration can be set on the body (after it's creation by the world instance) by calling the Body::SetAcceleration method or one of the free functions that also sets it. Note that world gravity only sets the body acceleration on body creation and doesn't factor in to the body's velocity calculation after that.

By the way, your question suggests that this change from the original Box2D is surprising and/or unclear. Please accept my apology for this and my thanks again to you for pointing this out.

I reviewed this project's changes document to see if I'd made any mention of this difference in there and didn't find any. I've also moved development of this project over to the new project name and space of PlayRho. I suspect PlayRho also doesn't mention this change from the original Box2D either. I have updated PlayRho's issue louis-langholtz/PlayRho#219 to help me remember to address this. I'm less sure of what to do for this Box2D however.

Would you be willing and/or interested in trying out PlayRho? I'd really love to get more people to use PlayRho and help with great questions like you've made. Also, PlayRho is open to contributions and has that process integrated in the pull requests mechanism in a way that I quite like.

[rjdgtn]

Thanks for the detailed answer. I'll use SetAcceleration for change gravity influence.

1) Is current PlayRho version more stable or more optimised than your box2d fork last commit version?

2) I make pong-like game with very simple physics, but need full determinism. Your box2d fork looks 20% faster that original box2d, but using of Fixed32 for float calculations makes it 10 times slower. This is a very big price for determinism. Is there a way to improve performance?

3) I want to have two or more independent physics worlds in different threads. Do I correctly understand that this will not be a problem?

[louis-langholtz]

1. In some ways no and in other ways yes. The master branch of PlayRho including its API is still evolving while I'm not doing any further development on this Box2D fork. PlayRho has continuous integrated builds and testing for more of its functionality however. I've started doing some benchmarking between PlayRho and Erin's 2.3.1 or so release of Box2D and seen PlayRho perform better on some situations and slower in others.
2. Thank you for having performance tested my Box2D fork against the original! I'm happy to hear also that my fork looked faster. Note that while the Fixed32 type is available, I've found the use of 32-bit based fixed precision seemingly not generally very usable and I don't recommend using it. My Box2D fork's implementation of Fixed32 also still uses the standard floating-point math library and the float type to do calculations like sine, cosine, and square root. That's likely to re-introduce the platform dependence which it sounds like you want to avoid. PlayRho's implementation of the Fixed32 and Fixed64 types meanwhile was updated to not rely at all on hardware floating point support nor the standard math library. So PlayRho's implementation of the fixed types should provide better platform independence. Some of the math library routines I implemented for fixed types in PlayRho disappoint me however in their performance (log's performance is the most disappointing). I've read that going back and forth between integer and floating-point arithmetic hardware can kill performance but then I've also read that integer division tends to be significantly slower than floating-point division. I haven't done any actual bench marking of the different implementations though to be more specific. Using a popular implementation of fixed point type is probably the better way to go in terms of performance and correctness but then none of them seem to support constexpr/LiteralType C++ concepts causing other problems.
3. I believe my fork of Box2D and my PlayRho projects should both work correctly with different world instances being stepped through in separate threads. A user would of course still need to ensure that their uses of those worlds like for visualizations was in sync somehow with the world being represented.

Hope this helps.

[rjdgtn]

Thanks for the detailed answer.

1. I'll migrate to PlayRho
2. I would be glad to use Fixed64 but it require int128_t to be defined, but when you build on ios device with armv7 (32bit iPhone5 and earlier) __int128_t is not available... I replaced #ifndef WIN32 to `#if LP64__`

https://static1.squarespace.com/static/51adfbd9e4b095d664d9b869/51af2a99e4b06a9242b3992c/5a577101c8302558effd2433/1515683843292/Matrix+16by9%402x.png?format=original

[louis-langholtz]

Yes. Sorry about this. A 128-bit integer does need to be supported on the platform for the Fixed64 implementation to deal with intermediary fixed point results, and that does preclude Fixed64's use on many platforms.

I've opened PlayRho issue louis-langholtz/PlayRho#295 to address my desire to have an externally developed fixed point type supported by the PlayRho library. An external implementation would likely be much more widely tested too which would be appealing to me.

Alternatively, the implementation of Fixed64 could be worked on to at least optionally use two 64-bit integers (instead of the 128-bit integer) and I've opened PlayRho issue louis-langholtz/realnumb#1 for that. It's not clear that Fixed64 would be performant enough though.

[rjdgtn]

Ok. Thanks