Announcement

Collapse
No announcement yet.

Physics Sub-Stepping

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Physics Sub-Stepping

    Hey everyone! Engine programmer Ori Cohen has put together a great little post on physics sub-stepping for you guys. Hope you enjoy!


    One of the lesser known features in UE4 is the ability to turn on physics sub-stepping. By doing this you can get physics simulations that are more accurate and stable. The most noticeable improvement will be with ragdoll jitter and other complex physical assets.

    Sub-stepping can be turned on in the project specific physics settings:



    This feature is still a work in progress, and is not fully supported by APEX destruction. It is also currently not supported on mobile devices. However, we are working towards this as it can greatly improve the look and feel.

    What does this do?

    UE4 uses a variable frame rate. While this is good for hardware scalability, it creates a challenge for the physics engine, which works best with small fixed time steps. Sub-stepping takes the total frame time and divides it into sub-steps. The physics simulation is then ticked multiple times per frame. The number of sub-steps taken will depend on how small your max sub-step delta time is set to. The smaller the max sub-step time the more stable your simulation will be, but at a greater CPU cost.

    How does it actually work?

    Sub-stepping is completely hidden from the user, which means that some calls to the physics engine have to be interpolated or maintained. For example, if a user applies a force to an actor for a single frame, and the frame is internally sub-stepped N times, we need to apply the force for N consecutive simulation steps in order to achieve the same acceleration. Similarly, if the user sets the target location of an actor, we must interpolate the target location over multiple sub-steps in order to maintain the desired speed. All of these details are already handled internally by UE4, but there are some CPU and memory costs associated with the required bookkeeping.

    Another technical detail to be aware of is the way collision callbacks behave while sub-stepping. UE4 runs the physics sub-stepping in a separate physics thread, allowing the game thread to continue doing work. In order to get the best performance we delay the collision callbacks until the final sub-step is done. This means that you can get several callbacks for the same collision. For example, if A collides with B and bounces off, you may get a callback for A and B overlapping AND a callback for A and B no longer overlapping in the same frame. Internally all callbacks are pushed into a queue and so callbacks from sub-step 1 will be processed before callbacks from sub-step 2.

    Should I turn this on?

    The answer depends on the needs of your game. If you are using complex physics assets it’s likely that you’ll see a significant improvement in quality by turning sub-stepping on. On the other hand, if the physics simulation is not as important to you as some other features, it might be CPU time better spent elsewhere. Either way, I would strongly recommend trying this feature out to see what kind of improvements it makes for your game!

    Have questions? Let me hear about them below!
    Attached Files

    #2
    Which of these techniques would enabling this option be most similar to? I would prefer the "Free the Physics" method, as that seems to produce the most reliable results for a timing/physics-sensitive game like a platformer.

    Comment


      #3
      Hi, this is a great link, thanks for posting it.

      UE4's sub-stepping is in fact Semi-fixed timestep. I agree with you that "Free the Physics" would be ideal. We actually had a debate about these two techniques and eventually decided on semi-fixed, and here's why:

      If you use Free the physics you have to use a timebank. If you want to tick physics at 60fps and you have a frame that took a little bit more than 1/60 you will need to have some left over time. Then you will tick the physics engine with the perfect 1/60 delta time, leaving the remainder for the next frame. The problem is that the rest of the engine still uses the original delta time. This means that things like blueprint will be given a delta time of 1/60 + a bit.

      You can imagine a case where a user would want to use delta time in blueprint to determine the location of an object that's moving at some constant speed by saying "new position = old position + speed * delta time"
      In such a case the user will expect the object to move speed * delta time. However, since delta time is longer the the time we tick a single physics frame, we would need to either brake the movement into two physics ticks to maintain the right speed, or we would have to place the object in the new expected position at the end of the frame, but increase speed. Either way the result isn't what the user would expect.

      Getting the rest of the engine to use this new delta time would affect many systems, and so we ultimately decided to go with semi fixed.

      If you're interested in this there are some files I can direct you to where you could actually change this behavior quite easily, but it would introduce some of the problems I describe above.
      Last edited by Ori Cohen; 05-02-2014, 10:57 PM.

      Comment


        #4
        It's been a while since the original post, so I was wondering on the status of physics sub-stepping being available on mobile? Thanks!

        Comment


          #5
          Thank You Ori!

          I recently tried Physics Substepping and wow! It made such a huge difference for my game where the player controlled unit is a physics simulating mesh!

          Controls feel so much more fluid now!

          Thanks Ori!

          And thanks Crystal for letting us know about it!

          Rama
          100+ UE4 C++ Tutorials on the UE4 Code Wiki, including UE4 Multi-Threading!

          UE4 Marketplace: Melee Weapon Plugin & Compressed Binary Save System Plugin | Rama's C++ AI Jumping Videos | Vertex Snap Editor Plugin

          Visit www.ue4code.com to see lots of videos about my C++ Creations! ♥ Rama

          Comment


            #6
            Hi Ori! It’s good to know that the sub stepping is not a true fixed time step. Could you direct me to the files you mentioned to attempt to make it a fixed frame rate as I’d like to experiment with it.
            Also – could you elaborate a bit more on the technical limitations in doing a fixed frame rate in Unreal as I believe the time issue you’ve described can be solved using the interpolation technique described in the “Free the Physics” article unless I’m horribly mis-understanding something.......

            Explanation: If the physics is run 1 frame ahead then that remaining left over bit or time is the amount to interpolate between the last complete physics frame on the current side of the game update and the end of the first physics update on the next game update. Therefore the physics frame can be some small delta that fits n times into a normal render frame accumulating the left over time each render frame and using it for the next one using this idea of “the renderer produces time and the simulation consumes it in discrete delta time sized chunks”. The game layer can do its calculations using the render frame time as it wants to and will be given interpolated values from physics.
            Does that sound valid?

            Comment


              #7
              Physics Substepping is very useful. I always use it if physics is involved.

              I also increase the velocity iteration and position iteration in each actor's physics tab.
              Default is something like position iteration=8, velocity iteration=1. I usually go like 80 and 10. I noticed there is an effect, but I am not sure about the interplay of these iteration and substepping.
              Can you elaborate on this?

              Overall I am very happy with the physics at such high settings (substepping and velocity/position interation count).
              I did pure ragdolling using the HeroTPP+PhAT and human-like swing/twist limits for the 'joints' and threw the HeroTPP down cliffs and whatever and the motion looked absolutely live-like.
              And I am in the middle of creating a euphoria engine-like selfbalancing and powered ragdoll, with the intention of fully animation-free character control, that uses physics constraints and angular motors for 'joints and muscles' and a balancing AI. It works really well!

              Only thing that is a bit annoying, is that PhysX multithreading seems to be limited to 2 cpu cores.

              Comment


                #8
                Would it be possible for callbacks to receive information about additional callbacks that might be firing in that frame? (Even just a number of callbacks would be enough) so that functionality that might rely on this info doesn't break.

                Comment


                  #9
                  Hi Keribo,

                  The interpolation issues come from content creation. In the free the physics approach you can end up with some delta time that is reserved for the next frame. The potential problem with this is that an object that's been set to a certain location will have to interpolate that position over two frames.
                  If the user does something like this:

                  frame 1:
                  Object.SetLocation(1,0,0)

                  frame2:
                  print Object.GetLocation()

                  You will get some interpolated value which could be confusing. In this example it doesn't really matter, but you can imagine some cases where this would break.

                  There are two places where you can look. If you want to go with Free the physics route you should take a look at PhysSubstepTasks.cpp where you can change the way we compute the number of sub-steps and delta time.
                  Another approach would be to set the engine to run in fixed timestep mode. This is not really exposed right now, but you can try it out with the commandline: -UseFixedTimeStep -FPS=60
                  The obvious downside to this is that the game will speed up or slow down based on performance.

                  If you wanted to go the free the physics route I think you'd want to create a new event for content which would be called FixedTick or PhysicsTick, which would indicate the delta time the physics engine will use in this frame. This way you can distinguish between the physics time and the rest of the game time.

                  Hope that helps

                  Comment


                    #10
                    I use Sub-Stepping in a racing game and the effect is huge

                    dev100000 sad something about position Iteration and velocity Iteration. This sounds interesting, is there a docu or can someone describe how it works ?

                    Comment


                      #11
                      Position and velocity iteration is a per body setting that you can use to improve simulation stability. The PhysX docs give a good explanation here: https://developer.nvidia.com/sites/d...olver-accuracy

                      Comment


                        #12
                        Thanks for the thread.

                        Out of interest, how much more expensive is this? I'm working on a hobby title where players control and command Physics-based Hovertanks (see here), and it's Multiplayer. My calculation changes PhysicsAngularVelocity and PhysicsLinearVelocity directly, and I simulate the input over the network on the server and send authoritative updates back. (That way it feels nice and instantaneous for Clients).

                        Thing is, I eventually want to simulate up to a couple of hundred of these bodies in PS2 style games. Is sub-stepping going to help me or am I better off going down the fixed lockstep approach?

                        Comment


                          #13
                          Is there a way to access each sub step from game code? For our car project, we're doing our own engine/clutch/gearbox simulations. It would be great if we could do them every substep and not just once per frame in Tick (our current approach).
                          Proud member of iNFINITE Production - VR and hi-tech development studio (sometimes) available for hire.

                          Comment


                            #14
                            Originally posted by ENiKS View Post
                            Is there a way to access each sub step from game code? For our car project, we're doing our own engine/clutch/gearbox simulations. It would be great if we could do them every substep and not just once per frame in Tick (our current approach).
                            Yes, for our project we have added that feature and it should be present in engine versions 4.6 and up.

                            In the tick of component which you want to access sub-steps from the game, do this:
                            Code:
                            void URailroadWheelComponent::TickComponent(float DeltaTime, enum ELevelTick TickType, FActorComponentTickFunction *ThisTickFunction)
                            {
                            	Super::TickComponent(DeltaTime, TickType, ThisTickFunction);
                            
                            	// Add custom physics forces each tick
                            	GetBodyInstance()->AddCustomPhysics(OnCalculateCustomPhysics);
                            }
                            This will call the delegate 'OnCalculateCustomPhysics' during next tick, for each substep (16 times for 16 substeps). Define delegate as:
                            Code:
                            FCalculateCustomPhysics OnCalculateCustomPhysics;
                            OnCalculateCustomPhysics.BindUObject(this, &UTrainPhysicsSimulator::CustomPhysics);
                            The delegate body is:
                            Code:
                            void UTrainPhysicsSimulator::CustomPhysics(float DeltaTime, FBodyInstance* BodyInstance)
                            {
                            	URailroadWheelComponent* RailroadWheelComponent = Cast<URailroadWheelComponent>(BodyInstance->OwnerComponent.Get());
                            	if (!RailroadWheelComponent) return;
                            
                            	// Calculate custom forces
                            	//.....
                            
                            	// You will have to apply forces directly to PhysX body if you want to apply forces! If you want to read body coordinates, read them from PhysX bodies! This is important for sub-steps as transformations aren't updated until end of physics tick
                            	PxRigidBody* PRigidBody = BodyInstance->GetPxRigidBody();
                            	PxTransform PTransform = PRigidBody->getGlobalPose();
                            	PxVec3 PVelocity = PRigidBody->getLinearVelocity();
                            	PxVec3 PAngVelocity = PRigidBody->getAngularVelocity();
                            
                            	//......
                            
                            	PRigidBody->addForce(PForce, PxForceMode::eFORCE, true);
                            	PRigidBody->addTorque(PTorque, PxForceMode::eFORCE, true);
                            }
                            You can contact me at irc.freenode.net #unrealengine (nickname BlackFox), this isn't the correct account from which I should be replying.

                            Comment


                              #15
                              Thanks a lot, it's exactly what i was looking for. Just to clarify for others, it's not included in 4.6.1, but it is in 4.7
                              Proud member of iNFINITE Production - VR and hi-tech development studio (sometimes) available for hire.

                              Comment

                              Working...
                              X