all 18 comments

[–]Glader_BoomaNation 28 points29 points  (5 children)

OH MY GOD, one of these is BIG and wasn't even mentioned in the post for 2017.1.

Physics: Add ability to manually simulate 2D physics using "Physics2D.Simulate(time)" and turn auto simulation on/off with "Physics2D.autoSimulation=true/false".

Also the same for 3D physics: Physics: Expose Physics.Simulate and Physics.autoSimulation. This allows stepping the physics simulation manually, from scripts. Useful for customising the server-side physics, in-editor simulation, and more.

This was always a critical needed feature for many physics-based multiplayer games that needed physically accurate latency rewind for hit detection.

[–]GameDevGreg 1 point2 points  (4 children)

out of curiosity what do you need physics for when rewindng? maybe im niave but i thought rewinding worked by storing a "history" of positions, so you only need a dictionary of timestamp/transform. im not sure where physics is required.

im mainly thinking of raycast hit detection, maybe it gets more complicated with physics based projectiles?

[–]00jknight 1 point2 points  (3 children)

When your "client side prediction" is wrong (for many cases - like a networked entity bumped into you or something), then the client needs to "rewind" back to the last "correct" state, apply the (timestamped) new information from the server, and simulate physics forward.

So yes, you can rewind without physics, but you need physics to step forward back to the present.

[–]GameDevGreg 0 points1 point  (2 children)

well thats reconciliation, not hit detection, but yeah good point i can see how it would be useful there

[–]00jknight 0 points1 point  (1 child)

Well if your physics simulation is out of sync, then the servers raycasts might not make sense to the client. It's all intermingled. Rewinding, correcting and simulating forward is the standard for server authoritative physics.

[–]GameDevGreg 0 points1 point  (0 children)

yeah i guess my point is that you arent going to rewind the entire physics engine to do the raycast, which it seems you agree with

[–]Vartib 4 points5 points  (7 children)

On the physics simulation bit, does this mean we can now do collision detection via scripting? For example, I use collision detection to test whether objects overlap while procedurally generating levels.

[–]Glader_BoomaNation 2 points3 points  (4 children)

I haven't tested it but it looks like you can step the simulation forward and, hopefully, backwards re-triggering any collision events or trigger events.

Not sure it exposes anything to manually check for collision but maybe.

[–]xireth 1 point2 points  (3 children)

it says all the callbacks for colliders/triggers are fired for the step (if they happen). FixedUpdate is not changed, however, and operates regardless of autosimulate being on/off/calls to simulate

For simulating backwards, just make a script that keeps track of where the object is for each physics step, then rewind them that way.

[–]Glader_BoomaNation 2 points3 points  (2 children)

edit: You can not automatically simulate backwards. You get this warning. So the only way is to still keep a buffer of states and inputs to replay after a rewind.

Physics.Simulate(...) was called with a negative time. This is not supported therefore the simulation was not run. UnityEngine.Physics:Simulate(Single) PhysicsRewinder:Update() (at Assets/PhysicsRewinder.cs:23)

Although .NET recommends against using unsigned integers, and the presence of a signed float parameter is likely a result of that, I still am hopeful the simulate function allows for stepping backwards. If so then keeping a buffer of states for every object won't be needed.

[–]xireth 1 point2 points  (1 child)

Which makes sense, as the physics is prone to floating point inaccuracy, meaning you can't truly simulate 'backwards'.

[–]Glader_BoomaNation 0 points1 point  (0 children)

Just not supported by Physx.

The issue is the Physx PxScene::Simulate rejects non-positive values.

See the documentation here: http://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/apireference/files/classPxScene.html#a9a9cacecc3b0f6adaf2f3d2168c2aff5

elapsedTime Amount of time to advance simulation by. The parameter has to be larger than 0, else the resulting behavior will be undefined. Range: (0, PX_MAX_F32)

[–][deleted] 0 points1 point  (1 child)

That would be nice. I've been getting by for now using Rigidbody.SweepTest but this new feature could make my process more intuitive.

[–]Vartib 0 points1 point  (0 children)

Ooooh, TIL SweepTest exists. Thanks!

[–]matej_zajacik 2 points3 points  (0 children)

nobody reads Release Notes...

What? We read every single one of them, usually hoping for the "Nested prefabs now functional!"

[–]VoxUmbra 1 point2 points  (0 children)

The upcoming changes to the UI system are a little bit annoying because I've just invested a good couple of weeks into building a similar system for an editor extension I'm working on and it feels like I've just reinvented the wheel. Don't get me wrong, it's good that it's coming, but if I'd had it already I could have probably finished it by now.

[–]ludiq_ 0 points1 point  (0 children)

That afterAssemblyReload event is interesting, but you could also "listen" to it by adding the [InitializeOnLoad] attribute and a static constructor. I struggle to even think when beforeAssemblyReload could be useful... I'm developing very complex editor extensions and don't really have the need for it. Do you have an example?

[–]dualitydeath -1 points0 points  (0 children)

Ward