Physics usecases - Githubissues

As discussed on discord, here's a couple things which AFAICT are impossible with the current physics API but are necessary for nontrivial games.

Setting IntegrationParameters
- Currently i need just max_ccd_substeps, will likely need dt soon, but probably all should be exposed
Expose more perf counters - e.g. https://docs.rs/rapier3d/0.11.1/rapier3d/counters/index.html - i am currently most interested in CCD steps.
Run physics for only a subset of objects
- Example 1 - client-side prediction / server reconsilliation: 1) Take a subset of game entities back a few frames, 2) do raycast or projectile hit detection, 3) resimulate physics for the affected entities. 1 and 2 look possible already but i don't see a way to do 3. Graph::update always updates the entire scene and most of its internals are private.
  - Also note that Graph::update does not use its dt param for physics - this is likely a bug.
- Example 2 - simulate physics a couple frames forward for a projectile to draw the expected path.
Running custom gamelogic in the middle of a physics update. Most common usecases are teleports/portals - detect when a player touches a teleport, change his position, run the rest of the physics frame.
- A temporary solution would be to at least allow pausing physics for the player when he touches the teleport so he doesn't bounce off and influence other entities until my code can get to him next frame and teleport him. Don't think this is currently possible either.
- This is a pretty low priority for me and i didn't see anybody else using teleports in fyrox yet, plus it's not completely game breaking.
- I don't know how exactly this would be done with pure rapier but i assume I'd need to use there traits https://docs.rs/rapier3d/0.11.1/rapier3d/pipeline/index.html
Snapshots - e.g. multiplayer game client receives update from server (which is in the past), restores physics to that point in time, reapplies player input on top of it. Rapier says it supports snapshots but i don't see where. I guess this can be achieved by saving the state of all entities a few frames back and restoring manually. Might even be preferable to avoid resimulating expensive stuff like particles.

I think it would be best to expose rapier's structs directly where possible:

Fyrox will attract people from bevy who want to use a more powerful engine and they will already be familiar with rapier.
Being able to point people at rapier docs.
Not having to look up and keep in mind differences between rapier and fyrox.
Less code to compile, less symbols in binary, faster compile time.

Issues that currently prevent exposing rapier fully:

Serialization - probably solvable
Prefab inheritance / hot reloading
Rapier doesn't allow a custom container for joints - step_generic

FyroxEngine / Fyrox

Physics usecases #289