ravarcade
commented
4 years ago Background The possibility of comparing two physics engines gives a chance to improve both. So I started looking for an alternative. The first 2 attempts have been a failure. Both Unity's default physics and DOTS Physics have many problems with the collision between a fast-ball and a fast-flipper. Also, simple ball stacking gives unstable behaviour. It may be possible to overcome that obstancles, but that would take a lot of time.
Bullet Physics First tests looks good. Without any tweaking ball-flipper interactions looks realistic. Not same as VPX, but not bad. Portability looks good, linux, ios, osx, android are supported. Performance is ok too. I can put few more stacked balls than in current VPX physics. It doesn't mean VPX is slower, just that particular case is slow in VPX. For now it is also worst case scenario.
Current status
- we have first version of comunition interface between VPE Core and external physics engine (and with DebugUI too). This interface is probably not in finall form, but for start it is enought.
- basic ball - flipper or static object collisions works.
- manual ball roller for testing works... Well it is crucial tool to check models shape when debug draw of physical shapes don't work.
- flipper params are accessible to DebugUI. Few charts usefull in tweaking/debuging works fine. They are also accessible for VPX physics. Here is first place when we can compare both.
Guidlines
- A new Unity package containing a physics engine is added to the Unity project
Adding Bullet Physics is as simple as adding VPE to Unity. See instuction on my BulletPhysics repo.
- The editor somehow allows to select the desired engine (preferably on per-table basis, somewhere in the table inspector)
It is matter of one click in inspector to enable/disable Bullet Physics:
- If the (default) VPX engine is chosen, the other engine(s) should be invisible (not called at all in the game loop)
It works like that. There is one thing to remeber. Bullet physics code will be added to builded VPE. It will be possible to select engine later, when builded VPE will be executed.
- If another engine is chosen, the VPX engine should be completely disabled (no systems active).
Right now Bullet Physics will disable ECS systems used by VPX on start.
- Each engine can be configured somehow, by the table (i.e. at runtime)
It is easy to add single switch and gives table-dev decision witch physics should run. My goal is to minimize number special params for object when different physics is selected. Just to avoid confusion.
- The overhead should be minimal
In most cases, code required to select different physics engine, will be not in performance critical parts. So, it should not create a problems. Also adding more physics engines to chose will not make difference.
freezy
While this repository ships with VPX physics, we would like to have a way of replacing the physics engine at runtime. The main idea that we can a) easily test new engines without having to branch the code all the time and b) finally even deliver multiple engines for the table authors to choose from.
@ravarcade already started on a Bullet Physics implementation, so this has become somewhat relevant now.
Other physics engines aren't necessarily part of the same repo, but can be added as a Unity package and will be discovered by VPE when installed. Ideally, this would work like that:
~Architecture will follow.~
See ravarcade#3.