Would be interesting to look at the conversion of operators to methods, wasn't particularly aware at the time of the performance differences for them. Does move a bit away from trying to make things 'match' the c++ bullet code but would be worth it.
Array's are always range checked also; moving away from arrays is another performance boost.
I started to make some unit-test sort of things; but when I checked the same code for this version vs current git version; found they diverged significantly quickly. the basic solver loop has changed significantly. (even things like gravity are applied in a different place... the same drop from 50 at the same frame it should have it (height 1) XNA still had the cube at 3.5 something... first checked defaults like gravity and they were the same; but tracking back where gravity was applied found the code was significantly different between 2012/13 and now.
My current port matches pretty well... but trying to make it more exact (after 211 frames of 300 it starts to diverge... should enable debug drawing so I can see what they think. It's not in a repository of its own; but the WIP is at -deleted-; when I get it closer to bullet original behavior I'll make a separate repo for it... I wish there was a low-impact way to make a btScalar sort of type to switch between float/double; though can pretty much do a project-wide find/replace for double->float.
I know that support vertexes are used for GJK sort of calculations... but are you familiar with what 'support vertex' really means? Such as... the convex-static plane constraint algorithm finds basically one corner of a cube that hits a surface, which ends up applying all correction force at that point... which results in the origin being able to go 40% into the plane before it settles out... (a 2x2x2 cube with center 1,1,1 goes to 0.62 before resolving entirely... and it stays that deep for 4 or 5 processing frames) It's more work certainly, but finding all points that penetrated and doing a weighted average of those ( weighted by depth) as a resulting point I would think would make more sense; but then that would probably have to be a different calculation than what local support is returning? my test-001 is a cube that falls from fairly high onto a flat plane... so the cube would actually hit the ground face-down and in a mathematically perfect should bounce straight back up; picking a single corner of course results in a more 'real' result because a cube (a die) would never hit face down because of air disturbances etc... but; it's also not a good place to apply the correction impulse.
There's also a large amount of code that I haven't had to touch at all for a basic simulation; or for the core system... where do I find more information on what 'featherstone' and 'gimpact' and 'MLCPSolvers' are for? (oh guess I should do more searching http://box2d.org/files/GDC2014/ErwinCou ... rstone.pdf for instance answers those things)
Sorry I'm just kinda rambling a little 
I guess visual feedback would be nice.
Test 2 is a sphere dropping - it doesn't penetrate as much
test 3 is a box dropping, but a sphere sitting on the ground where it would hit first (0.25,0.25 offset from center with bodies of radius/halfextent 1)
test 4 is the sphere dropping...
I dunno maybe I shouldn't worry about the few decimal points of difference for now and move on to testing things like hingesStatistics: Posted by d3x0r — Fri Nov 06, 2015 7:15 am
]]>