The documentation for CharacterController.SimpleMove has a line that reads like this: “It is recommended that you make only one call to Move or SimpleMove per frame.”. My question is: Why? What is the reason behind this.
I’m not sure what the behind the scenes reason would be. But why would you want to call it more than once? It makes sense to do your calculations and all that before then actually apply them once in the end.
Because I need to, sorry but this wasn’t my question.
1 Like
Yeah I know it wasn’t. I stated that I didn’t have the answer but was just wondering why would you want to do it.
Because I’m doing some rewind/forward functionality for a multiplayer game.
Any update on this? Rewind/Replay is a bitch with Unity’s rotten physics core, and I’m sick of having to debug stuff to figure out what should be documenent.
And for those who are wondering why not just use rigidbodies, well, we need to use CharacterControllers to actually get collision information during a replay and CC is the only way to do it with the half-baked Physx implementation. Or you could manually do (multiple) SweepTests per entity per frame, but that’s even worse.
(Remember when the Unity devs were looking into Bullet but didn’t pull the trigger? Yeah, I’m hoping whoever made that call has been demoted to working the mail room.)
How are you doing rewind/replay?
You can disconnect the physics and rewind/replay with just the mesh renders.
That’s where I’m headed. Right now I have a CharacterController per pawn, but what I think I’m going to do is just have one CC that I use to do my state stepping and disconnect the physics as much as I can. Since CCs don’t actually collide properly anyway (with mass and such) there’s really no reason to have more than one.
Now, I used to have rigidbody pawns and projectiles and items and everything was AddForce() based in FixedUpdate() and it all worked fine modulo numerous workarounds for the baseline wonkiness of the Physx implementation… of course that all fell apart once I tried to add rewinds and discovered that you can’t get rigidbody collision information until you reach an Update phase. So now I’m trying the CC thing and have regressed to no shooting for the time being.
My plan at the moment is to step pawns with shared CharacterControllers separate from any entity (one per pawn type / shape), step projectiles with SweepTests, put entities (read: kinematic rigidbody hitboxes) in the proper positions for timesteps by either using rigidbody.MovePosition() or directly moving their transforms and doing an enable / disable (which I’ve heard “reinitializes” the collider position), and doing performance culling by distance from replaying entities and switching entities between layers. Oh, and doing basic “visual” interpolation in Update() to mitigate jerkiness.
Do you have a full rewind/replay/lag comp/client extrapolation thing working with solid physics?
Btw, my project is an FPS, but it’s very physics oriented with rugged terrain, acceleration based movement, and all projectile weaponry, not your standard hitscan, run n’ gun corridor shooter.
Edit: To be clear, we’re talking about Source Engine style rewind / replay, where the server “rewinds” the game state to the past when it receives client input and “replays” the physics up to the present, changing the world state to what should have happened if there was no latency. And clients rewind and extrapolate when receiving data from the server to show the player what it thinks the world state on the server is for the current timestep (or, more precisely, will be after future rewinds that haven’t even happened yet) based on lag and imperfect information.
Time.timeScale?
Very interesting stuff you’re working on. Playing back rigid body and physics is problematic. There are ways around it, but you have to invest the time to modify your code to deal with it.
I have a work in progress - lol. I recently added some experimental scripts to OMS (link in signature) that allow you to record multiple objects in one scene.
To get an idea of how it works with one object, take a look at this demo.
The cars in this scene were fully animated by recording the car bodies and the wheels independently, so 15 objects in all - which in OMS can be replayed, rewound and controlled with a slider in-game.
http://dl.dropbox.com/u/25954755/AnimatedCars/WebPlayer.html
I haven’t had the time to fully test legacy and mecanim animations. I’ve been able to record mecanim joint movements, but they don’t deform the overlaying mesh when playing back the data - so that is something I need to investigate. If I can animate it, then that would be great, but how does one go about doing that in-game to allow for rewind replay?
I’m imagine the movie Wanted right now - not sure if that’s the effect that you’re after, but a game like that would be very, very cool. 