Deterministic fixed-point port, open source
Re: Deterministic fixed-point port, open source
I forked and stuck it in a Unity project (2017.4.1f1), along with a simple test scene to compare with the Unity inbuilt physics. I'll keep adding bindings for all the primitive types, compound objects and expose a load more values. It's definitely interesting and the performance looks fantastic, I'm intrigued to see how it does though IL2CPP.
There's a decent profiler built in to Unity that might be of some use, at a glance the overheads just literally seemed to be the shear amount of function calls to the Fix64 methods, I'm building against an older Mono, so didn't have the aggressive inlining. The jitter also looks to be very minor, I created a dummy Fix64 which used float internally, to confirm this was the issue and obviously everything went back to silky smooth.
My aim is to add some sort of rollback/serialization, to allow me to add GGPO style rollback networking. It's something I've been playing with for a few months, given it sync's using a list of input, it should be able to chuck any game onto my current server setup.
There's a decent profiler built in to Unity that might be of some use, at a glance the overheads just literally seemed to be the shear amount of function calls to the Fix64 methods, I'm building against an older Mono, so didn't have the aggressive inlining. The jitter also looks to be very minor, I created a dummy Fix64 which used float internally, to confirm this was the issue and obviously everything went back to silky smooth.
My aim is to add some sort of rollback/serialization, to allow me to add GGPO style rollback networking. It's something I've been playing with for a few months, given it sync's using a list of input, it should be able to chuck any game onto my current server setup.
Re: Deterministic fixed-point port, open source
Hey, thanks for forking!
Where exactly did you notice jitter? Running the BEPUphysics demo scenes I didn't really notice any jitter, so maybe there's a bug I missed?
Where exactly did you notice jitter? Running the BEPUphysics demo scenes I didn't really notice any jitter, so maybe there's a bug I missed?
Re: Deterministic fixed-point port, open source
I had balls rolling down a long slope, accelerating (a longer slope than the current scene). They'd occasionally do a little hop that I wouldn't see with floats. It could just be confirmation bias on what I was assuming I'll see, I'll give it a much better investigation tonight, as well as recreating some of the original demo scenes in Unity.
I had a quick peep at porting the V2 library across. Sadly it's very reliant on C# 7, which Unity doesn't support, so almost every line would need changing (no support for ref locals). Almost everything seemed to be refs to structs so I'd lose all the performance with a "find and replace" job![Smile :)](./images/smilies/icon_smile.gif)
I wouldn't advise anyone to pull the Unity fork currently, there's virtually nothing there. It shouldn't take long to add Unity bindings to all the obvious bits though. The way I've serialized Fix64 in the Unity inspector is fairly messy as well, it's half there so I can debug what values it's baking out, from Unity's floats.
I had a quick peep at porting the V2 library across. Sadly it's very reliant on C# 7, which Unity doesn't support, so almost every line would need changing (no support for ref locals). Almost everything seemed to be refs to structs so I'd lose all the performance with a "find and replace" job
![Smile :)](./images/smilies/icon_smile.gif)
I wouldn't advise anyone to pull the Unity fork currently, there's virtually nothing there. It shouldn't take long to add Unity bindings to all the obvious bits though. The way I've serialized Fix64 in the Unity inspector is fairly messy as well, it's half there so I can debug what values it's baking out, from Unity's floats.
Re: Deterministic fixed-point port, open source
Ugh, as I'd thought the error was indeed in my own code. The code updating the positions of the rendered meshes was being called less than the updates were being run. I'll get back to adding graphical representations of the shapes and start porting some demos across ![Smile :)](./images/smilies/icon_smile.gif)
![Smile :)](./images/smilies/icon_smile.gif)
Re: Deterministic fixed-point port, open source
From what I hear from Norbo, there's not much hope of getting V2 to be deterministic. Its highly optimized to use SIMD instructions, which don't really translate to integer math at all.
Re: Deterministic fixed-point port, open source
There's a new 32.32 fixed point library for C#:
https://github.com/XMunkki/FixPointCS
There might be point in considering a switch to that one.
https://github.com/XMunkki/FixPointCS
There might be point in considering a switch to that one.
Re: Deterministic fixed-point port, open source
Yup- for now. I would like to look into abstracting scalars with a compile time switch, though. If I can find a way to do that with decent codegen (or if later versions of the compiler open up some more doors), it would be possible to build a SIMD accelerated fixed point version with fairly constrained changes. Performance would definitely suffer relative to FP32- particularly if 64 bit wide scalars were stored in the solver- but it would still be vastly faster than a fixed point v1.From what I hear from Norbo, there's not much hope of getting V2 to be deterministic. Its highly optimized to use SIMD instructions, which don't really translate to integer math at all.
(Also, to avoid confusion for future readers, this is referring to cross platform determinism. Determinism across simulations on the same hardware is just a matter of setting Simulation.Deterministic to true.)
Re: Deterministic fixed-point port, open source
Thanks for the feedback Norbo. For a bit of perspective, I work in a mobile studio so I end up targeting a huge mash of CPU types, hence the interest in the fixed point determinism. I'm keen to have a play with networking some games you wouldn't normally associate with deterministic rollback networking. Simple driving games, spaceships, rolling ball, things with a bit of momentum that hides some degree of input latency, with a simple enough simulation that allows me to replay a few frames worth of data in a frame, should I need to.
I've been playing about with networking emulators on mobile for a while, even via 4g the connections can be really impressive. My server setup just bounces input, so should drop straight into other titles.
I've been playing about with networking emulators on mobile for a while, even via 4g the connections can be really impressive. My server setup just bounces input, so should drop straight into other titles.
Re: Deterministic fixed-point port, open source
Hello guys,
Does anyone have this little bouncing problem?
[youtube]https://youtu.be/Iu2VVoQI1fM[/youtube]
Thanks for sharing the deterministic version, btw. I'm trying to use this engine into Unity.
But now I'm stuck in creating mobile mesh collider because of the bouncing problem.
Does anyone can tell me where should I start tracing the code?
Thank you.
Does anyone have this little bouncing problem?
[youtube]https://youtu.be/Iu2VVoQI1fM[/youtube]
Thanks for sharing the deterministic version, btw. I'm trying to use this engine into Unity.
But now I'm stuck in creating mobile mesh collider because of the bouncing problem.
Does anyone can tell me where should I start tracing the code?
Thank you.
Re: Deterministic fixed-point port, open source
That behavior reminds me of one of a few things:
1) Incorrect depth calculation.
2) Failing shallow collision detection, followed by deep detection trying to compensate and 'bouncing' the shape out.
3) Broken persistent manifold management.
All the pairs in the video would use the GeneralConvexPairHandler. So, chances are, whatever is going wrong is within the GeneralConvexContactManifold.Update function. Prime suspects are ContactRefresher.ContactRefresh and pairTester.GenerateContactCandidate, and maybe ContactReducer.ReduceContacts. Contact reduction doesn't seem likely because it shouldn't be doing anything until after a full manifold exists, and the problem appears to occur on the first impact frame.
Within GeneralConvexPairTester.GenerateContactCandidate, you'll see there are three states a collision can be in- separated, shallow, and deep. It's possible that they're all subtly broken, but the shallow case is the most likely culprit.
1) Incorrect depth calculation.
2) Failing shallow collision detection, followed by deep detection trying to compensate and 'bouncing' the shape out.
3) Broken persistent manifold management.
All the pairs in the video would use the GeneralConvexPairHandler. So, chances are, whatever is going wrong is within the GeneralConvexContactManifold.Update function. Prime suspects are ContactRefresher.ContactRefresh and pairTester.GenerateContactCandidate, and maybe ContactReducer.ReduceContacts. Contact reduction doesn't seem likely because it shouldn't be doing anything until after a full manifold exists, and the problem appears to occur on the first impact frame.
Within GeneralConvexPairTester.GenerateContactCandidate, you'll see there are three states a collision can be in- separated, shallow, and deep. It's possible that they're all subtly broken, but the shallow case is the most likely culprit.
Re: Deterministic fixed-point port, open source
Thank you, @Norbo
It is really GenerateContactCandidate() problem.
For more detail, it's PairSimplex.TryTetrahedronTriangle() problem.
I check the algorithms are the same, but output "point" are different.
When I revert this method to non-fix64 version, it fixes the bouncing problem.
I think it's much multiplication to make the deviation.
Now I have to find a way to resolve the deviation.![Sad :(](./images/smilies/icon_sad.gif)
It is really GenerateContactCandidate() problem.
For more detail, it's PairSimplex.TryTetrahedronTriangle() problem.
I check the algorithms are the same, but output "point" are different.
When I revert this method to non-fix64 version, it fixes the bouncing problem.
I think it's much multiplication to make the deviation.
Now I have to find a way to resolve the deviation.
![Sad :(](./images/smilies/icon_sad.gif)
Re: Deterministic fixed-point port, open source
any update on this?
I'm interested in the results!
If this instability is caused by precision limitations, have you considered using much larger (still fixed) precision for certain calculations?
I'm interested in the results!
If this instability is caused by precision limitations, have you considered using much larger (still fixed) precision for certain calculations?
-
- Posts: 4
- Joined: Sun Feb 03, 2019 4:30 am
Re: Deterministic fixed-point port, open source
I think I just fixed it (I will make a pull request asap) (edit: PR here https://github.com/sam-vdp/bepuphysics1int/pull/1)
The problem was here:
Changing it by:
even though division is slower than multiplication and this can optimize it, it looks like the precision lost by doing "denom=1/x" and then "y*denom" instead of "y/x" is large enough to cause problems. If this trick is used in more places, then that could also cause problems there.
Also, the previously posted Fixed math library is very fast, I'm working one one myself (but 32bits) and there is a minimum of 2x speed gain (at least with basic operations) if you can switch from using structs to an enum of type long because it avoids copying the struct and, when it is avoided using "in" or "ref", accessing the field or having functions for comparisons is a lot slower. The problem is that enums must work with extension methods because they don't support operator overloads, and that means changing all operators by functions. That is a lot of work, I don't know if there is a sane way of doing it.
The problem was here:
Code: Select all
Fix64 denom = F64.C1 / (va + vb + vc);
simplex.W = vc * denom;
simplex.V = vb * denom;
Code: Select all
Fix64 denom = (va + vb + vc);
simplex.W = vc / denom;
simplex.V = vb / denom;
Also, the previously posted Fixed math library is very fast, I'm working one one myself (but 32bits) and there is a minimum of 2x speed gain (at least with basic operations) if you can switch from using structs to an enum of type long because it avoids copying the struct and, when it is avoided using "in" or "ref", accessing the field or having functions for comparisons is a lot slower. The problem is that enums must work with extension methods because they don't support operator overloads, and that means changing all operators by functions. That is a lot of work, I don't know if there is a sane way of doing it.
Re: Deterministic fixed-point port, open source
I hold out hope that one day in the not too distant future, either RyuJIT (or an alternate AOT compiler backend under CoreRT) will be able to collapse operators into the same codegen you get from manual inlining- even for larger structs... one day, one day...and that means changing all operators by functions. That is a lot of work, I don't know if there is a sane way of doing it.