Announcement

Collapse
No announcement yet.

[OPEN-SOURCE] Machinery Modelling Toolkit

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

    All I did was set the hull to replicate, it seems to have worked for the basic testing I wanted to do. I'm not sure whether that tries to simulate the physics altogether or just the velocities. It did behave a bit odd when slowing down, acceleration seemed pretty smooth though.
    Why do all programmers wear glasses? Because they can't C#

    Comment


      Might be interesting to run some crash tests in multiplayer

      Comment


        Since this uses custom physics, I wonder if this would work with other UE4 projects that involve physics, like the OceanProject

        Comment


          Originally posted by siverwolfe View Post
          Since this uses custom physics, I wonder if this would work with other UE4 projects that involve physics, like the OceanProject
          Sure, what is meant by custom physics, in the first post, is not using PhysX template for the vehicles but doing calculations directly in game code. PhysX is still used to handle rigid body collision and process forces. The way it works, for example with friction: we measure relative velocity, calculate necessary friction force and apply it to vehicle using AddForceAtLocation(). From there, physics engine will handle changes in velocity linear and angular velocity, rotation and position.
          Youtube Channel

          Comment


            Originally posted by BoredEngineer View Post
            Sure, what is meant by custom physics, in the first post, is not using PhysX template for the vehicles but doing calculations directly in game code. PhysX is still used to handle rigid body collision and process forces. The way it works, for example with friction: we measure relative velocity, calculate necessary friction force and apply it to vehicle using AddForceAtLocation(). From there, physics engine will handle changes in velocity linear and angular velocity, rotation and position.
            Not sure if I understood it correctly. In a nutshell, the difference between MMT and normal physics in UE4 is that you update your physics positions/forces/impulses during each substep, while 'normal' physics in UE4 updates only at the end of a full substeps cycle. That's the novelty here as far as I understood.
            This per-substep updating is only active for your nodes that you created and use in MMT and it does not mess around with the other physics in the project, right?

            Comment


              Originally posted by BlueBudgie View Post
              Not sure if I understood it correctly. In a nutshell, the difference between MMT and normal physics in UE4 is that you update your physics positions/forces/impulses during each substep, while 'normal' physics in UE4 updates only at the end of a full substeps cycle. That's the novelty here as far as I understood.
              This per-substep updating is only active for your nodes that you created and use in MMT and it does not mess around with the other physics in the project, right?
              What plugin does is provides you "MMT Physics Tick" event to run almost any kind of code during physics sub-stepping. It uses the same AddForce() functions, as BP is using, but with extra parameter that is not exposed. That parameter tells if AddForce(), AddTorque() and etc. are called from the physics sub-step or from regular tick. So all this works just as any other physics code works, just with ability to utilize sub-stepping.
              Just want to highlight that per-substep updating is active for almost everything that you call from "MMT Physics Tick" event. I'm highlighting almost because practically, code invoked by such event is running in parallel thread, so you can't call regular draw debug commands or print string (I've build separate components for that, which are "thread safe"). Other than that you can do pretty much anything. In some cases this might even improve performance as your "simulation" code runs in a parallel to the game thread (as long as it's not so heavy that you stall physics thread).
              You can mix this with any other code that you have, as long as you are ok with Pawn (I'll add physics sub-stepping Actor too) having a Pre-Physics tick group, as otherwise you can't get "custom physics" delegate on c++ side.
              Youtube Channel

              Comment


                Originally posted by BoredEngineer View Post
                What plugin does is provides you "MMT Physics Tick" event to run almost any kind of code during physics sub-stepping. It uses the same AddForce() functions, as BP is using, but with extra parameter that is not exposed. That parameter tells if AddForce(), AddTorque() and etc. are called from the physics sub-step or from regular tick. So all this works just as any other physics code works, just with ability to utilize sub-stepping.
                Just want to highlight that per-substep updating is active for almost everything that you call from "MMT Physics Tick" event. I'm highlighting almost because practically, code invoked by such event is running in parallel thread, so you can't call regular draw debug commands or print string (I've build separate components for that, which are "thread safe"). Other than that you can do pretty much anything. In some cases this might even improve performance as your "simulation" code runs in a parallel to the game thread (as long as it's not so heavy that you stall physics thread).
                You can mix this with any other code that you have, as long as you are ok with Pawn (I'll add physics sub-stepping Actor too) having a Pre-Physics tick group, as otherwise you can't get "custom physics" delegate on c++ side.
                Actors would be interesting to see. That would enable more things than just the standard pawn based Unreal Engine project.
                I wonder how joints would be affected by updating after each substep. Basically how would a ragdoll composed of actors (static meshes) and joints or joint motors behave...
                With actors, you could also set up a side by side project with identical actors: one with substepping updates and one without. That would be interesting to see the difference.

                Comment


                  Originally posted by BlueBudgie View Post
                  Actors would be interesting to see. That would enable more things than just the standard pawn based Unreal Engine project.
                  I wonder how joints would be affected by updating after each substep. Basically how would a ragdoll composed of actors (static meshes) and joints or joint motors behave...
                  With actors, you could also set up a side by side project with identical actors: one with substepping updates and one without. That would be interesting to see the difference.
                  It would behave the same way as if you are using standard physics constraints as physics constraints do use sub-stepping when it's enabled. I'll add actors then, it's literally just copy/paste of Pawn code with a different base parent.
                  Youtube Channel

                  Comment


                    Originally posted by BoredEngineer View Post
                    It would behave the same way as if you are using standard physics constraints as physics constraints do use sub-stepping when it's enabled. I'll add actors then, it's literally just copy/paste of Pawn code with a different base parent.

                    no need for the actors, we can do it ourselves at some point. We just want to collect infos.
                    How about collision? They write they only collect collision at the end of a full substeps cycle for performance reasons, but it sounds as if you could well do it after each substep, even if it is more expensive.
                    Do you have a rough idea how easy/difficult it is to change code to do collision per substep?
                    https://forums.unrealengine.com/show...ht=substepping

                    Comment


                      Originally posted by BlueBudgie View Post
                      no need for the actors, we can do it ourselves at some point. We just want to collect infos.
                      How about collision? They write they only collect collision at the end of a full substeps cycle for performance reasons, but it sounds as if you could well do it after each substep, even if it is more expensive.
                      Do you have a rough idea how easy/difficult it is to change code to do collision per substep?
                      https://forums.unrealengine.com/show...ht=substepping
                      [MENTION=179867]0lento[/MENTION] did mention in one of our conversations that it's possible to receive collision event between sub-steps, but it did involved modifying engine code. The way solved this for light tank is by adding results of collision events into array in each TrackAnisotropicFriction component and then removing them after processing. Which might be not too accurate at low fps but works in general.
                      Youtube Channel

                      Comment


                        Originally posted by BoredEngineer View Post
                        [MENTION=179867]0lento[/MENTION] did mention in one of our conversations that it's possible to receive collision event between sub-steps, but it did involved modifying engine code. The way solved this for light tank is by adding results of collision events into array in each TrackAnisotropicFriction component and then removing them after processing. Which might be not too accurate at low fps but works in general.
                        The line mentioned here is this:
                        https://github.com/EpicGames/UnrealE...cene.cpp#L1356
                        DispatchPhysNotifications_AssumesLocked() gets called at end of full physics frame. I haven't modified the engine myself to make that happen on each substep but it shouldn't need more than just placing that line where each substep ends.

                        What you can do without modifying engine though is copy/paste this for loop and use it as a separate function on your own project and call the function at start of each physics tick:
                        https://github.com/EpicGames/UnrealE...cene.cpp#L1124

                        I also needed to handle SwapContactOrders() manually there, but you can trace back that code as well from sources. This is quite hacky though, so if you can just modify the engine it would be a lot cleaner way.
                        https://github.com/0lento/UnrealEngine (GameWorks tech merges & upgrades, UE4 physics modifications)

                        Comment


                          I think doing it without modifying the engine is better, unless it is done with support from Epic.
                          It might be paranoid thinking, but when something breaks your game and it only appears after you published, then you can lean back and finger point at Epic when they torch you on the Steam forums and in the reviews.
                          Like with the one game where it turned out UE4 has problems with AMD sound drivers (I seem to remember). They just threw the ball into Epic's court (where it belongs in such cases) because they used the Engine out of the box. Had they tinkered with the engine, the problem would have been much bigger, also in terms of actually resolving it.
                          If you modify something yourself, it is a bit like destroying the warranty.

                          Comment


                            The bad part of this is that since that code that would need to be included on project is actual engine code, it can't be included on open source project that is freely available to all. So even if BoredEngineer wanted to include that on MMT, license technically doesn't allow it on it's current distribution form (only possible way to work around that would be to fork full UE4 github repo and include the plugin with it, this is how Allegorithmic does this for substance plugin).

                            Nothing is stopping you on the other hand from doing it yourself and using on that on your own projects as long as you don't share engine code yourself to other than verified UE4 licensees.
                            https://github.com/0lento/UnrealEngine (GameWorks tech merges & upgrades, UE4 physics modifications)

                            Comment


                              Update: Modular Drive Train [work in progress]

                              In this update I've added basic components for modelling behavior of the drive train. Small video to demonstrate current features:


                              A lot of credit for this system goes to 0lento as it wouldn't be possible to implement this without his help!

                              Each component of the drive train is build to be used as replaceable module. The main motivation for this is rather simple - to avoid writing custom implementation for each configuration of the drive train. Let me show you what I mean by this.
                              This is a typical configuration of the car's drive train:
                              Click image for larger version

Name:	DriveTrain_Car.JPG
Views:	1
Size:	28.8 KB
ID:	1106083
                              If you are building a car racing game, most likely you will be implementing such drive train in one way or another. When you start to add features, such as ability to stall engine, engine drag, locking collar of gear box to gears and etc. you might find yourselves re-writing quite a lot of code as each new feature might require different implementation of other features. Still, it's not too bad as long as general configuration of the drive train stays the same. For example, A_Tracked_Vehicle uses similar configuration with a bit of a trick to enable neutral turn.
                              When configuration changes, you can get into a bit of the trouble as certain assumptions that were true before, such as integrating velocities only at wheels and engine, are not true anymore and integration of velocity have to be done in more places. This is the case with old British and Russian tanks:
                              Click image for larger version

Name:	DriveTrain_Clutch-Brake_Steering.JPG
Views:	1
Size:	39.4 KB
ID:	1106084
                              What they did, is installed clutch for each track in addition to main clutch between engine and gearbox. Driver would have two levers, one for each track, by pulling the lever half way he would control locking of the clutch. Un-clutched track would naturally slow down and tank will start rotating as other track is rotating with full power. By pulling lever even further, it would enable track brake and turn would happen even more rapidly. Mechanically, this wasn't very efficient but very simple system and was quite common on early tanks of WW2. To implement such configuration, we need to integrate velocities in multiple places. The main problem is that we can easily get into combination madness of levers position and how and where torque should be transmitted.
                              To make it even worse, let's look at next exhibit:
                              Click image for larger version

Name:	DriveTrain_GearedSteering.JPG
Views:	1
Size:	37.2 KB
ID:	1106085
                              As far as I know, such system was used on quite a few tanks of WW2, as it was more energy efficient than clutch-brake system and provided driver with a combination of turning radii by switching each steering gearbox into a different position. This is the first practical system which allowed neutral steering where each track would rotate in different direction.
                              Practically, you might not need more than a first configuration, unless you are building more of a simulator and want to highlight differences in vehicles performance and steering. But even in such case, you can have cars with automatic or manual gear box, 4WD or RWD, or even switchable between them as on many SUVs. Modular system will allow you to just change your components and don't bother with a custom logic for each configuration.

                              How it works?
                              [to be continued]
                              Last edited by BoredEngineer; 05-08-2016, 11:37 AM.
                              Youtube Channel

                              Comment


                                How modular drive train works

                                Each component of the modular drive train needs to implement "DriveTrainModuleComm" interface which has 4 methods:
                                - DTUpdateFromSourceToApplication
                                - DTUpdateFromApplicationToSource
                                - DTReceiveDataFromSourceSide
                                - DTReceiveDataFromApplicationSide

                                "Source" means side of the drive train with the engine and "Application" means side with wheels/tracks.

                                The idea is that on each Tick (or physics sub-step Tick) each component is "updated" twice and each "update" ends with sending resulting data to next component up (or down) the chain:
                                Click image for larger version

Name:	DriveTrain_Components_Communication.JPG
Views:	1
Size:	77.8 KB
ID:	1106087

                                So if engine is connected to a clutch and clutch is connected with gearbox. We start with updating engine using "DTUpdateFromSourceToApplication" function call, which sends data to the clutch using "DTReceiveDataFromSourceSide" function at the end of the update.
                                Now as clutch received data from the engine, it does it's own update in "DTUpdateFromSourceToApplication" and sends data to gearbox. In this example, gearbox is the last component and there is no data to send further. As we reached the end of the chain, we start to update components in the backwards direction - gearbox->clutch->engine. For this we use "DTUpdateFromApplicationToSource" functions and "DTReceiveDataFromApplicationSide" to pass data.
                                This way each drive train component can do it's own calculations as a "black box" and the rest don't need to know anything about it. For example, engine doesn't need to know if clutch is locked or not. When clutch is unlocked (completely released and not slipping) clutch will just pass back the same angular velocity to the engine as it received from the engine. When clutch is completely locked (not slipping) it will pass angular velocity received from the engine to the next component, which decides on it's own what should be done with it.
                                The only other consideration is regarding components that can integrate velocity, meaning that they apply torque to change angular velocity on their update. Such components are engine, clutch, gearbox and track sprocket or wheel hub. Not all of them integrate velocity all the time, only when their logic requires to do so. For example, engine integrates velocity on every tick as final engine torque changes with RPM and throttle position. Clutch integrates velocity only when not completely locked as clutch plates will produce friction force. Gearbox integrates velocity when you shift gears and synchro produces friction force to match velocity of lay and drive shafts. Wheels or tracks, integrate velocity from the reaction force as the result of friction with the ground. The pattern is pretty clear: each component that creates or receives torque from outside of the drive train or can "disconnect" drive train - will integrate angular velocity.
                                When components "disconnect" drive train, such as clutch or gear box, they integrate velocity on their "application" side of the shaft. The "source" shaft is considered as responsibility of the component previously in the chain.

                                In feature posts I'll describe each of the implemented components.
                                Youtube Channel

                                Comment

                                Working...
                                X