[OPEN-SOURCE] Machinery Modelling Toolkit

[BoredEngineer]

I took a quick screenie. The 'wheels' (not the right name probably) marked in red. They move, or flip, just between two frames and therefore appear to have zero mass.

[ATTACH=CONFIG]89790[/ATTACH]

They have little mass compared to the weight which pushes on them, this can be tuned. Visual wheels are attached to invisible mesh with collision, adjusting mass of collider, bogie which connects them and handle to which bogie is connected - changes quite a bit. It's a matter of tuning I think. Will look into it

Btw, you are looking at 30fps video, so that have effect on smoothness too.

[StanleyTurner]

Hello Bored Engineer,

Great work and thanks for all your effort in developing the MMT! You are a rockstar!!

So I'm working on an SdKfz 251 that I got up and running thanks to OldRaven's tutorials. You'll notice that I attached the front wheels and they are rotating nicely and have working suspension.

https://youtu.be/7EOcOyDaEAk

I decided to use your method for adding yaw rotation to the Fokker rudder (Steer Rudder function) as a method for 'turning' the front wheels of the half-track:



However, when I add an Event Tick node to my A_TrackedVehicle blueprint's event graph to pass delta seconds to the Steer Wheels function, the front tires 'turn' appropriately but all tread rotation ceases:



https://youtu.be/SnvesnBYaKI

Any thoughts on what's happening here?

[BoredEngineer]

Hello Bored Engineer,

Great work and thanks for all your effort in developing the MMT! You are a rockstar!!

So I'm working on an SdKfz 251 that I got up and running thanks to OldRaven's tutorials. You'll notice that I attached the front wheels and they are rotating nicely and have working suspension.

https://youtu.be/7EOcOyDaEAk

I decided to use your method for adding yaw rotation to the Fokker rudder (Steer Rudder function) as a method for 'turning' the front wheels of the half-track:


However, when I add an Event Tick node to my A_TrackedVehicle blueprint's event graph to pass delta seconds to the Steer Wheels function, the front tires 'turn' appropriately but all tread rotation ceases:



https://youtu.be/SnvesnBYaKI

Any thoughts on what's happening here?

I guess your half-track is a child of A_TrackedVehicle blueprint. In this case, on EventTick event of the child you need to call EventTick of the parent first. Right click on EventTick and there should be option "Call Parent Function" or something like that. This will add new node to the graph, just call it before you call SteerWheel function.

[Dealman]

Awesome update! I'll be checking it out later, makes me want to add a Sherman which has a rather fancy suspension.

[BoredEngineer]

Awesome update! I'll be checking it out later, makes me want to add a Sherman which has a rather fancy suspension.

Be aware that new tank is made out of about 100 components
I just didn't used any skeletal meshes to be sure that everything is assembled exactly as it should and works together. Need to look into how it can be done in more manageable way. A bit of complexity comes from the fact that visual representation of the road wheels, sprocket and idler is different from their physics body and it can't be the same static mesh. Collision meshes, which are invisible, connected to a bogie (in case of road wheels) and not allowed to rotate. Visible meshes of the road wheels, have to rotate, so they are placed as children of physics mesh in hierarchy and animated using AddLocalRotation. Suspension can be made in principal as a skeletal mesh but you will still have to attach physics mesh separately as we need to process individual collision hit events.

[TiagoTiago]

Btw, would it be possible to have it iterate thru all the objects in the BP, and automatically add objects to their respective parts of the BP code (inside an array I guess) based on a prefix in the name, instead of requiring things to be manually added? (like for example "Wheel Left-", "Sprocket Right-" etc; or maybe even skip the "left" and "right" part, and use their Y coordinate to calculate how they should behave)

[BoredEngineer]

Btw, would it be possible to have it iterate thru all the objects in the BP, and automatically add objects to their respective parts of the BP code (inside an array I guess) based on a prefix in the name, instead of requiring things to be manually added? (like for example "Wheel Left-", "Sprocket Right-" etc; or maybe even skip the "left" and "right" part, and use their Y coordinate to calculate how they should behave)

Ideally, you should be able to directly provide references of components to other components in the same BP. But this is technically not possible because some components can be created before others.
Automatically finding them could be done using tags for example, like to locate a gearbox component for example. But then assumption would be that you have just one gearbox, which is not the case for some tanks.
My point is that "automatic" referencing of components can be done only if you have more or less the same configuration for each tank. But in this case nothing stops from just duplicating a BP and setting different meshes.
Referencing of components can be improved in some cases by using hierarchy of components. For example friction component almost always uses root as component to which forces are applied and direct parent as a reference for velocity and coordinate system. I'm just not sure that adding such automation worth the price of loosing flexibility.

[TiagoTiago]

Ideally, you should be able to directly provide references of components to other components in the same BP. But this is technically not possible because some components can be created before others.
Automatically finding them could be done using tags for example, like to locate a gearbox component for example. But then assumption would be that you have just one gearbox, which is not the case for some tanks.
My point is that "automatic" referencing of components can be done only if you have more or less the same configuration for each tank. But in this case nothing stops from just duplicating a BP and setting different meshes.
Referencing of components can be improved in some cases by using hierarchy of components. For example friction component almost always uses root as component to which forces are applied and direct parent as a reference for velocity and coordinate system. I'm just not sure that adding such automation worth the price of loosing flexibility.

Can't you have it not assume the number of anything, and just count the instances once it reaches the last item? Or am I understanding the issue wrong?

[BoredEngineer]

Can't you have it not assume the number of anything, and just count the instances once it reaches the last item? Or am I understanding the issue wrong?

I'm not sure what you mean, what it's suppose to do with a number of instances?

[TiagoTiago]

I'm not sure what you mean, what it's suppose to do with a number of instances?

Maybe that was a poor choice of words. You said it could see one gearbox, and stop there even when there is actually more than one; so I asked if it would be possible to always check for more until all objects have been checked.

[StanleyTurner]

I guess your half-track is a child of A_TrackedVehicle blueprint. In this case, on EventTick event of the child you need to call EventTick of the parent first. Right click on EventTick and there should be option "Call Parent Function" or something like that. This will add new node to the graph, just call it before you call SteerWheel function.

Thanks that did the trick!

[BoredEngineer]

Maybe that was a poor choice of words. You said it could see one gearbox, and stop there even when there is actually more than one; so I asked if it would be possible to always check for more until all objects have been checked.

Ohh, I see now. Apology for confusion. What I was trying to say is that if you have for example two gearboxes, which are connected to two separate tracks. Each track would have to find a "proper" gearbox. As you will be providing input into left or right gearbox depending on the direction of steering.
Components which require the most of manual name references right now are track friction points. For them I could do a simple fix where you have to provide only name of the "effected" component (which would be root static or skeletal mesh) and for reference component it can automatically pickup its parent. But this might not be explicit enough, especially with the way how hierarchy is presented right now in editor GUI - just by name indent, where it could draw a bit of lines, as a ts done in Unity I don't think.
At the same time, there are other unrelated to tank components which won't work like that.

Long term solution is to start moving components into c++ implementation. Then they can include both logic and necessary meshes inside of a single component.

[BoredEngineer]

Update

Found a very simple but powerful fix for the friction simulation. Previously it was difficult to settle simulation when vehicle was standing still. It comes from the fact that simulation of the friction force is done in reactive way, meaning that friction force is created after some change in velocity was detected. That's unfortunate limitation of how we can work with PhysX engine without going deep into a source code:
https://answers.unrealengine.com/que...get-force.html
When vehicle is driving, reactive friction works just fine. The problems start when vehicle is standing still on the ground and we get a little bit of velocity from the suspension pushing wheels around. Just a small amount of such velocity leads to a friction force pushing wheel back into place, which creates velocity by itself, to which friction reacts again but now in opposite direction. So we end up with friction forces indefinitely pushing wheels left and right, which leads to a jittering of the vehicle and prevents it from setting physics objects to sleep:

Pink vectors are friction forces. One of the fixes to this, is to rely on build-in friction model on very low speeds. For this, all collision objects that need to simulate anisotropic friction (wheels/sprockets/ski) are given physics material with very low coefficient of friction, instead of "no-friction" material as it was before. now we just need to disable our custom anisotropic friction when relative velocity between wheel and ground is very low (like less than 1cm/s) and build-in physics friction will stop vehicle completely and put physics to sleep. Unfortunately this doesn't work because of mentioned earlier issue with settling forces. Forces shown earlier on the screenshot, create relative velocity of about 10 cm/s for that specific vehicle, which is significant amount for this particular application. When tank is moving full speed ahead, it's tracks can have almost zero relative velocity with the ground if they are moving in opposite direction almost as fast as tank itself. So disabling custom friction calculation at small relative velocity can take away important physics simulation when tank is in motion. So by trying to fix a "standing still" issue with brake dynamic case of simulation which is obviously more important.
Solution to all this is rather simple - average relative velocity of the friction point over last two updates. This almost completely removes any reaction of friction force to jittering of the vehicle (springs and physics constraints can have small barely visible vibration even with good damping settings, this is more related to collision detection and respecting of constraints). This is how the same situation looks like after averaging relative velocity:


Together with addition of very small velocity threshold and "small friction" physics material, vehicles will now stop properly and get into sleep state. Which is great for performance and ability to find you car in the same spot as you have parked it


I'm still working on drive train:
Got most of the code done for simulation of engine, gearbox, clutch and a simple wheel. Drive train components are modular, so you can just add as many of them as you want and describe how they should be connected to each other. The rest is done automatically - how much torque, angular velocity or moment of inertia you have at specific parts of drive train. The wiring of components is minimized to calling two types of update functions, it can look like a train of nodes in real drive train but practically you can always just copy paste it from one car into another. Right now I have some issues with the settings of parts of drive train, clutch force is too large and moment of inertia on wheel is too high. I'll do a proper update when this is finished

[OldRaven]

this just keeps getting better and better.

Finally done with a 2 month assignment so can pick this up again..

One thing I really need to start looking into now is if this works in multiplayer and if no.. why not and what needs changing.

[BoredEngineer]

this just keeps getting better and better.

Finally done with a 2 month assignment so can pick this up again..

One thing I really need to start looking into now is if this works in multiplayer and if no.. why not and what needs changing.

Good question. I would add it out of the box if I knew how. I think [MENTION=16712]Dealman[/MENTION] managed to make it work in multiplayer.
So if someone know what need to be done, I can add it into the project by default. For example, if we are looking for the simplest case of running physics on client with client authority.