[OPEN-SOURCE] Machinery Modelling Toolkit

[BoredEngineer]

Update on progress

When constraint based model for simulating suspension of the tank failed (miserably in some areas and wasn't flexible enough in others), I started looking for other algorithm. Sweep based model with shaped colliders was rather obvious and works quite well.
This model is very similar to doing a raytrace for each wheel for calculating suspension. The core difference is that instead of using a ray or sphere trace for all wheels, front and back wheels use shaped collider which approximates contact of the track with the ground:

Some of you seen this previously - the same shaped collider was used in constraint based model. While this model is better for functional behavior of the tank, it lacks proper articulation of the track. Tracks have to be "glued" to wheels and can penetrate some of the obstacles. In typical game scenario this isn't a big problem and such artifact can be hidden by landscape and other geometry.

I've decided to give a try to a more complex model, where track would approximate behavior of the real one. There are quite a few implementations, including simulating track as a connected chain of rigid bodies - real deal. I might give a try at some point but not now.

Just to make it clear, the algorithm that I want to describe is not final and not planned to be used for more than a few tanks at the same time. We are not looking only at visual behavior of the track either, we want it to have an effect on tank's mobility too. Tanks are capable of driving over large obstacle not only because of powerful engine but the fact that road wheels never have to "attack" obstacle in a sharp angle. For comparison with the wheeled vehicle:

With enough traction, wheeled vehicle can in fact drive over an obstacle higher than radius of the wheel, but it's problematic to achieve with substantial horizontal acceleration. In case of tracked vehicle, track itself provides a slope for the wheel and this way even smaller roadwheel can overcome much taller obstacle.
So what we need to do, is imitate how track would be placed on the ground and obstacles and then roll wheels over the track. To do this we need to find position for some key points of the track, for hypothetical tracked vehicle we could do something like this:

Blue points are fixed, green points are "main" points and aligned with road-wheels, orange points are "middle" points and placed between main points or fixed points.

[BoredEngineer]

Green points (main) are allowed to move only vertically in local space of the tank, so that they can follow wheels. There are multiple forces that effect them:
- gravity, that pulls point down
- elastic force, that keeps track from stretching too far
- suspension force which is transferred through road-wheels

Yellow points (middle) are effected by the same force when they are not in contact with obstacle. During contact with obstacles these point can move not only vertically but horizontally. This is schematics of how contact with obstacle is detected:

First raytrace between main and fixed point, detects an obstacle.

Second raytrace just few centimeters forward from where first collision was detected, gives us point where middle point should be moved:


this is how it looks like in the engine, without smooth tangents on the spline:




Unfortunately, while this approach with using "middle" points was an optimization, it has some issue which I can't solve right now. Mainly there are situations where tracks start to jitter as middle point keeps jumping between free and collision states. Today I've tried replacing middle points with a several regular main points and results where better than I've expected. Work continues, there are still couple of things I have to try here and there before deciding on final approach.

[BoredEngineer]

Capture of the WIP results:

[Dealman]

Long time since I last read this thread, I'm glad to see you're still actively working on this - you've made some really impressive progress since. Keep it up

[BoredEngineer]

Long time since I last read this thread, I'm glad to see you're still actively working on this - you've made some really impressive progress since. Keep it up

Thank you!
The plan is to have multiple implementations for tracks:
1) One that is similar to PhysX implementation - for best performance and with ability to combine it with modular drive train and other features
2) Second one that "simulates" how track works for a "hero" tank or cases when fidelity is important. This won't work well on 10+ tanks, the idea is to use it only on main tank or only when you can actually see tracks.
3) Third implementation that is in between first two. It won't simulate the tracks, but it will be more forgiving to terrain than first implementation and should simulate movement of the tank itself more adequately.

Updated repo to 4.14. Didn't test vigorously but it compiles and doesn't throw errors. Cleaned up the main level a bit (there were half broken tanks slowing down everything).
I'm planning on converting MMT Content into c++ project, right now it has to be done every-time when you want to compile executable and I'm getting tired of making a copy of the project for this every-time. Judging by this thread:
https://forums.unrealengine.com/show...-Project/page2
we won't get content only projects with custom c++ plugins anytime soon, so I might cut out this hassle of converting it.

[Dominik Peacock]

Hello, BoredEngineer!

I am working on "Our Ghosts of War" (link here) and I want to use this kit to implement vehicles. Right now, I am focusing on tanks. I have set up a model of the Tiger I and physics are working great. Before integrating this into the project I have been testing performance and noticed that placing several of my tanks (10 in my case) has a significant drop on the FPS so I tried doing some optimisations, which you might be interested in. I managed to double the FPS, which sounds good but I wish I could further improve it. My tank is set up nearly the same as the M113 with the only differences being: 1. three additional wheels on each side 2. spline tracks were replaced with a skinned posable mesh whose bones are aligned with the wheels and moved up to make the tracks follow the wheels 3. the tracks movement is animated using UV animations. For debugging, I have added afunctionality which causes the tank to keep driving forward, so it does not go to sleep while debugging. All optimisations were run separetly for better analysis.

The simplest optimisation which works but yields only minimal improvements: For both tick functions, the main tick and the substepping tick function, I added added the option to configure that some ticks are simply skipped. For instance, I tried several configurations in which every 2nd, 3rd, etc up to 8th tick are skipped. Setting it too low causes the simulation too look jerky but setting it too high will hardly yield any performance boosts. Empircally I determined that without loss of the simulation quality skipping every 5th tick is fine. However, it turns out this hardly saves much performance, as might have been expected: With 10 tanks, it went from ~18 FPS to ~21 FPS so a rather small improvement but it still works.

A second improvement is in the main tick: there are several animation functions which only need to be run when the client is close-by to a tank. I set a configurable property that ensures the animation functions AnimateWheels, AnimateTreadsMaterial, AnimateTreadsSpline, etc. are run only if the client (in both standalone and networked games) is close-by, say 50 meters. This made the FPS go up from ~18 FPS to around ~36 FPS when the client went a little away. I think this optimisation is quite useful as usually at around 50 meters distance it is quite difficult to see the wheels spin anyways; after some gameplay testing I can confirm this: you do not notice it at all so the quality is not harmed in any way. So it seens a good idea to do distance based animations.

A third optimisation I tried is quite similar to the second approach; it works with occlusion culling. Before executing animations, it determines whether a tank is actually visible to the client. If it is not, we need not bother playing the animations. This yields a significant boost similar to the one in the second approach, optimally performing when you can only see your own tank. The performace then increases to ~35 FPS, again with 10 tanks. So it appears this optimisation is also a good idea.

The profiler has also told me that CheckWheelCollision and ApplyDriveForceAndGetFrictionForceOnSide are quite more expensive that the other ones all together. Reason for this is because those functions are run multiple times for every wheel and suspension. I tried minimising calling those functions using distance culling again. However, this yields quite funny behaviour. If I spawn my tank far away from them (>50 meters which is the configured culling value) my FPS is 120 for my tank on its own (awesome!), however if I drive to the other tanks they yield to simulate: the wheels are stuck in the floor. Once I ram them, they start to drive around until I exit the 50 meter sphere and they yield doing their phyiscs again. Now I admit what I tried was very adhoc and I have not tried all options yet, nor have I shared my setup with you yet, but maybe you have an idea to prevent those expensive function calls?

Also, do you have any other ideas to optimise vehicles both on client and on server? In our current game, their may be up to 100 tanks which are concurrently active, which would be quite expensive for the server. Of course, the server never has to run those animations and some of the physics code but it appears as soon as I do not run one of the physics functions handling movement, the tanks starting behaving in a weird manner. What are you plans for performance updates to the project?

As a side, I will continue on working on these optimisations and add them to the project as I have the time to do so.

[BoredEngineer]

Hello, BoredEngineer!

I am working on "Our Ghosts of War" (link here) and I want to use this kit to implement vehicles. Right now, I am focusing on tanks. I have set up a model of the Tiger I and physics are working great. Before integrating this into the project I have been testing performance and noticed that placing several of my tanks (10 in my case) has a significant drop on the FPS so I tried doing some optimisations, which you might be interested in. I managed to double the FPS, which sounds good but I wish I could further improve it. My tank is set up nearly the same as the M113 with the only differences being: 1. three additional wheels on each side 2. spline tracks were replaced with a skinned posable mesh whose bones are aligned with the wheels and moved up to make the tracks follow the wheels 3. the tracks movement is animated using UV animations. For debugging, I have added afunctionality which causes the tank to keep driving forward, so it does not go to sleep while debugging. All optimisations were run separetly for better analysis.

The simplest optimisation which works but yields only minimal improvements: For both tick functions, the main tick and the substepping tick function, I added added the option to configure that some ticks are simply skipped. For instance, I tried several configurations in which every 2nd, 3rd, etc up to 8th tick are skipped. Setting it too low causes the simulation too look jerky but setting it too high will hardly yield any performance boosts. Empircally I determined that without loss of the simulation quality skipping every 5th tick is fine. However, it turns out this hardly saves much performance, as might have been expected: With 10 tanks, it went from ~18 FPS to ~21 FPS so a rather small improvement but it still works.

Skipping ticks on physics simulation can lead to very bad results. It depends heavily on the landscape you are driving over - when landscape is smooth (like in War Thunder), you might not experience any major issues, but if tanks is going fast and encounters large obstacle during skipped tick, next tick can create much larger suspension force, effecting stability of the tank. I would rather skip some of the calculations when you believe they are not necessary, more on this later.

A second improvement is in the main tick: there are several animation functions which only need to be run when the client is close-by to a tank. I set a configurable property that ensures the animation functions AnimateWheels, AnimateTreadsMaterial, AnimateTreadsSpline, etc. are run only if the client (in both standalone and networked games) is close-by, say 50 meters. This made the FPS go up from ~18 FPS to around ~36 FPS when the client went a little away. I think this optimisation is quite useful as usually at around 50 meters distance it is quite difficult to see the wheels spin anyways; after some gameplay testing I can confirm this: you do not notice it at all so the quality is not harmed in any way. So it seens a good idea to do distance based animations.

A third optimisation I tried is quite similar to the second approach; it works with occlusion culling. Before executing animations, it determines whether a tank is actually visible to the client. If it is not, we need not bother playing the animations. This yields a significant boost similar to the one in the second approach, optimally performing when you can only see your own tank. The performace then increases to ~35 FPS, again with 10 tanks. So it appears this optimisation is also a good idea.

That is a good approach, I would setup some animation and skeletal mesh LODs together with this, to cut down some of the performance at closer ranges. I was looking at tank in Red Orchestra 1/2, which is made in older versions of Unreal Engines. It looks like devs change materials and complexity of the tread mesh at distance + animation is updated less frequently.

The profiler has also told me that CheckWheelCollision and ApplyDriveForceAndGetFrictionForceOnSide are quite more expensive that the other ones all together. Reason for this is because those functions are run multiple times for every wheel and suspension. I tried minimising calling those functions using distance culling again. However, this yields quite funny behaviour. If I spawn my tank far away from them (>50 meters which is the configured culling value) my FPS is 120 for my tank on its own (awesome!), however if I drive to the other tanks they yield to simulate: the wheels are stuck in the floor. Once I ram them, they start to drive around until I exit the 50 meter sphere and they yield doing their phyiscs again. Now I admit what I tried was very adhoc and I have not tried all options yet, nor have I shared my setup with you yet, but maybe you have an idea to prevent those expensive function calls?

These functions contain the core of movement simulation, they run on every tick and every physics sub-step. If you skip them, tank will fail to drive over the landscape as no suspension of friction forces (traction is part of it) will be generated. It should be possible to improve performance of these functions, but this is BP implementation - there is a limit to how fast it can run. New model that I'm working on has the most math heavy components implemented in c++. Moving friction component to c++ gave about x2.3 times boost in performance. Moving communication between components and the rest of the calculation into c++ should provide even better results.
What can be done here is some sort of check on rate of change of the form of the landscape, so if tank is keep driving in then flat field, some of the calculations can be skipped all together or can be done only on first wheel. The rest of the wheels would provide just the same force (in local space of the tank) as on previous frame. So if tank is driving forward and suspension force on the front roadwheels is not changing significantly, then the rest of the forces won't change significantly.
Another approach is similar, by comparing landscape in front of the tank on previous and current frame, decide if all wheels are needed and if not then drive it only on front and backward wheels, as if it would be a car. This would require adjusting stiffness of the springs which can be done with small adjustment in the code - there are some pre-calculations done in constructor.

Also, do you have any other ideas to optimise vehicles both on client and on server? In our current game, their may be up to 100 tanks which are concurrently active, which would be quite expensive for the server. Of course, the server never has to run those animations and some of the physics code but it appears as soon as I do not run one of the physics functions handling movement, the tanks starting behaving in a weird manner. What are you plans for performance updates to the project?

As a side, I will continue on working on these optimisations and add them to the project as I have the time to do so.

I'm not planning on touching code of A_Tracked_Vehicle. That implementation was made largely for studying the subject and uses similar approach to PhysX N-Wheeled Vehicle. For having something like a 100 tanks in the same scene, I would start with Nvidia's implementation, but I doubt that it can support that many with a reasonable performance. People did report that they could have 20+ tanks in the same scene without heavy performance impact.

For this project (Machinery Modelling Toolkit) I want to have something more modular than what Physx team have build and what I have build in Tracked Vehicle project. Having more detailed simulation would be nice too, but I don't think it would have a better performance than Physx's implementation. So it would be going more in the direction of having more features and modular design, rather than maximum possible performance. I don't think it's possible to have a generic model, that would be flexible in usage (in terms of what kind of vehicle you can build) and have a better performance than specialized implementations.
I don't know what kind of performance I will get with new c++ implementation, it will be faster but I don't think it will be 10x faster, perhaps with optimizations that you've tried in regards to culling and animations it will get over the 10x. So far only few components are moved to c++.
There are multiple prototypes that new c++ components but they are broken, each in their own way. One prototype, is using physics constraints for suspension and it's a dead end in terms of stability, getting it to work exactly as it should and quite costly performance wise. Second prototype uses AnimBP for suspension animation but it uses BP code to trace suspension against the ground, which leads to quite a performance hit but more stable and predictable than constraints implementation. Finally the latest prototype, is based on second prototype and extended with track simulation. Last two are being moved to c++ in a form of a single component per tracks, instead of 50+ as it was before. It's quite some work to do and I have no idea when this will be finished.


I thought you guys where using this thing:
https://forums.unrealengine.com/show...ent-Components
as I would recommend Physx implementation of N-Wheeled Vehicle for best performance. So far I've heard only good things when it comes to how much performance they need.

[OldRaven]

I'm still here

You mentioned somewhere , something about having to copy the project in order to be able to create an executable. Is this correct?
I cannot seem to build the project.. I keep getting an error.

I still need to update to 4.14 , my progress has been a bit slow.. mainly because the amount of things I need to do to get everything up and running is a bit overwhelming to do alone.. and it's hard keeping myself motivated to move on sometimes.
I've written a document with everything I want and need for a first proof of concept. I have a lot of ingredients ready, but adding all of them and making them work together is just.. well.. again... an overwhelming amount of work.

[BoredEngineer]

I'm still here

You mentioned somewhere , something about having to copy the project in order to be able to create an executable. Is this correct?
I cannot seem to build the project.. I keep getting an error.

Hi there, glad to hear from you!

So the situation with 3-rd party plugins is following - if you have a content only project (only BP code) and want to add a 3-rd party plugin (which is not Substance, or other plugins endorsed by Epic) then you will have to turn your project into c++ project, in order to be able to package it. It's easier than it sounds, but has a number of side effects, such as some complications when making game for IOS or Android. You can read more about this issue here:
https://forums.unrealengine.com/show...have-C-Project

So far, I was keeping MMT Content as content only project, so you can open it with just an editor and play with it. But you can't package it, because of custom c++ plugin - MMT Plugin. When you want to compile/package your project, you need to have Visual Studio installed and add a single dummy c++ class into your project. This process is irreversible as far as I know. So in my case, to get executable of MMT Content, I would just clone it and then turn into c++ project by adding a single c++ class from UE4 editor.

I wonder what wold happen if I turn MMT Content master branch into c++ project. Would it be possible for people without Visual Studio installed to open it in editor? - I'll check on this.

I still need to update to 4.14 , my progress has been a bit slow.. mainly because the amount of things I need to do to get everything up and running is a bit overwhelming to do alone.. and it's hard keeping myself motivated to move on sometimes.
I've written a document with everything I want and need for a first proof of concept. I have a lot of ingredients ready, but adding all of them and making them work together is just.. well.. again... an overwhelming amount of work.

I'm afraid we have to scrap constraint based setup for tank suspension. I wasn't able to get rid of jittering and overall we are rather limited in how constraints can be tuned. On top of that, they are performance heavy, in my last tests, about 30% of the frame time is spend on synchronizing positions of the rigid bodies and with constraint based setup we use quite a few rigid bodies just for suspension alone.
New approach is to animate suspension using AnimationBP (which hopefully supports culling and LODs) and calculate suspension using sweeps, sphere traces or ray traces.
If you focus on other features for now, I'll help you with setting up new system for suspension and traction when I'm done with it.

[BoredEngineer]

Could someone WITHOUT Visual Studio installed, please test this for me:
https://www.dropbox.com/s/70si3oz1u9...t_CPP.zip?dl=0
Just try to open it in UE4 Editor and package executable.

This is c++ version of MMT Content with compiled dlls included. Normally, "Binaries" folder is excluded from source repo, but if you can open this project and able to package it then we have a win-win situation. At least for Win64 it could work out of the box.

[OldRaven]

I'm afraid we have to scrap constraint based setup for tank suspension. I wasn't able to get rid of jittering and overall we are rather limited in how constraints can be tuned. On top of that, they are performance heavy, in my last tests, about 30% of the frame time is spend on synchronizing positions of the rigid bodies and with constraint based setup we use quite a few rigid bodies just for suspension alone.
New approach is to animate suspension using AnimationBP (which hopefully supports culling and LODs) and calculate suspension using sweeps, sphere traces or ray traces.
If you focus on other features for now, I'll help you with setting up new system for suspension and traction when I'm done with it.

I'm fine with that I'm not a big fan of constraints anyway too much hastle to setup.
Just a simple spring would be fine just like in the a_trackedvehicle blueprint.
The most important thing is what you wrote on the previous page.. the sprocket at the front and part of the track between the sprocket and the first wheel should be able to help you over an obstacle. Nobody will see that I'm not using a real torsionbar suspension setup

I cannot test the zip, I have visual studio installed.

[BoredEngineer]

I'm fine with that I'm not a big fan of constraints anyway too much hastle to setup.
Just a simple spring would be fine just like in the a_trackedvehicle blueprint.
The most important thing is what you wrote on the previous page.. the sprocket at the front and part of the track between the sprocket and the first wheel should be able to help you over an obstacle. Nobody will see that I'm not using a real torsionbar suspension setup

I cannot test the zip, I have visual studio installed.

No problem at all! My good friend helped me to test it yesterday:
- you don't need visual studio to open project in editor if c++ code is pre-compiled
- you need visual studio to package project
So basically it's just as it was before - need too have Visual Studio to publish project, but without it you can look around and develop BPs.

I'll convert MMT Content into c++ project then, on my side it will greatly speed-up development process, on users side nothing is changing.

[OldRaven]

Just for the fun of it.. decided to put on my oculus Rift.. since UE4 has support for it out of the box.
Guess what.. Driving a Tiger with your head from the Cupola is serious Fun in VR! I might make VR an option for controlling the tiger.
I did this a while ago in unity with the tiger, but driving from the commander position made me really sick. Now it does not.. how weird.. maybe better suspension this time
I need to throw in the interior, I think it would be epic to drive this thing from the driver perspective in VR.

[BoredEngineer]

Just for the fun of it.. decided to put on my oculus Rift.. since UE4 has support for it out of the box.
Guess what.. Driving a Tiger with your head from the Cupola is serious Fun in VR! I might make VR an option for controlling the tiger.
I did this a while ago in unity with the tiger, but driving from the commander position made me really sick. Now it does not.. how weird.. maybe better suspension this time
I need to throw in the interior, I think it would be epic to drive this thing from the driver perspective in VR.

Sounds fun

Not sure if this is because of suspension. If you see more chassis from driver position it can help to relief nauseous feeling.

[OldRaven]

no it was not because of the suspension I'm sure it was the camera. I remember in unity the camera was "connected" to the tank chassis, so your view rocked and moved when the tank moved.
The camera rotation in UE4 are disconnected from whatever the chassis is doing. But it is good to know that this works and you do not get sick as it opens possibilities for a vr mode.