[OPEN-SOURCE] Machinery Modelling Toolkit

What do you mean by “Copying the plugin folder didnt do the trick.”. Plugin just adds some essential functions and classes to allow doing calculations during physics sub-stepping in blueprint. There are no “content” in the plugin, aka modelling of suspension or friction.

Sorry I couldnt explain myself clearly before. I couldnt import the plugin into my project folder succesfully (which i should have do before migrating the content). It was a version problem tho. Now i figured out all and plugin is working and content is migrated into my project as well.
Thank you.

I re-setup the tiger in the latest MMT… so I’m good to go and continue fleshing it out.

I’m currently implementing all the interior camera controls and crew switching.

I read somewhere that you added support for adding the main sprocket as a collision wheel.
With the way it is setup right now (based on the M113) there is no collision with the sprocket and any object or the ground in general.
As the Tiger has such a big front sprocket it needs to also help out as a drive wheel… since the sprocket is the first “wheel” to hit an obstacle.

How can I set that up?

Same question for the Idler…

The idler is also pretty big and with obstacles and ditches… it also needs to “hit” the ground and sometimes help out drive wise (although collision would be more that adequate I guess)

erm…

So I have been puzzling for 2 days… fleshing out interior cameras…

And now all of a sudden all the dynamics don’t work anymore.
It worked like 5 minutes ago… didn’t change anything.

So… no suspension, wheels don’t turn. tracks don’t move…

Is there something I could have ticked accidently?

ok… this makes no sense to me… maybe some of you coding wizards can tell me what’s wrong.

When I remove this piece of blueprint the physics work again.

The only thing this parts does is handle a smooth transition when the camera goes from the default position to a zoomed in position for the driver.
The driver default and driver main visor are collision spheres. When you press the right MB a trace get’s thrown in the world … when it hits the main visor collision sphere… the camera smoothly transitions from the default position to the location of the main visor collision sphere.
The driver boom is a spring arm.

Could it have something to do with the collision spheres?

Wait… woke up this morning and it hit me. It’s the Event Tick…

Doh… I had to add a call to the parent function for the Event Tick… learning every step of the way here :smiley:

Regarding idler and sprocket. You need to use new component based model (T-26) to get them working. In principal it’s possible to combine raytraced wheels, as on M113 and traction-able sprocket and idler but I would do it with a component based setup. It would take quite a lot of work to add this properly into existing M113 code. Much easier to get it done in component based approach.

aha…

Can you give me a step by step workflow like you did for setting up the m113 in the beginning… so I can use that for the tiger.
If I understand how it works I can create a new setup tutorial video with this setting.

Sure! I need some time to review the steps as there is a an order of which components need to be added and connected. I was planning to make tutorial using MLRS model, just don’t have much time for this.

great! I plan on doing one from scratch if I understand how you did it. And create a tutorial for it… could be helpfull.

Tank modelling guide

Let’s start with a draft guide and polish it as we go. We need to split it into multiple parts not only to make it easier to digest but to define a scope of features, starting from a simpler/arcade model and moving toward “simulator” like behavior.

Overall picture of parts that we need to handle:

  • Suspension system. Suspension is necessary for tank to move smoothly over the obstacles or rough terrain and to distribute dynamic weight of the tank among the road wheels. The most common type of suspension on late WW2 and post WW2 tanks is suspension bars. The simplest way to model them is by using physics constraint with an angular drive.
  • Friction of the track with the ground. In component based approach, friction is decoupled from suspension and the way how suspension is made is largely irrelevant. This allows us to build anything that barely has any suspension at all, as first tanks in WW1 to a more visually sophisticated setups such was used on Shermans or interwar British tanks. What is important for track friction is to know how hard road wheels (sprocket/idler) are pushing against the ground or obstacle. For this we will use OnComponentHit events of roadwheels/sprocket/idler collision meshes which will provide all necessary information.
  • Animation of track and wheels. We will handle animation by using “TrackAnimationDrive” component (in current version of MMT). TrackAnimationDrive is made to render treads of the tracks using Instanced Static Meshes, later it can be swapped by another component which will use skinned mesh (looks less defined but is better for performance as can use LODs).
  • Engine and transmission. This is the part where one would make a choice for going with more of a simulation like approach or arcade behavior. Simulation will require quite a bit of tuning and gathering of information about tank in question. Simulation will make it harder to make tank behave as you want but can easily highlight differences in handling and steering of different tanks, especially in cases when different principal of transmission is used, for example clutch and brakes or geared differential. Arcade approach will allow you to get exact behavior that you need - how fast tank will accelerate, how fast it will steer and etc. You would need to decide on arcade behavior for yourselves. For example, most of the tanks in WarThunder, even on realistic difficulty are steered by applying brakes to one of the tracks. This is not how it was done in real-life but it is a nice approach to make controls of the tank familiar for all of the tanks in the game, the downside is that you are loosing ability to do a proper neutral turn and tank will loose speed when cornering. Neutral turn can be added with a some code logic (check M113 for example).

Suspension
Suspension of tank consist of two parts “visual” and “physical”. We will use separate meshes for them as we need a much “wider” coverage for collision than what visual roadwheels and sprocket can cover. This is an example of collision contour for Tiger tank:


Red is a collision of sprocket and blue is a collision of a front road wheel. Notice how collision extends all the way over the track as this is the point where we want tank to stand on the ground or collide with obstacles. Wheel collision is extended to the front to cover a gap where track is not supported. This will prevent objects from penetrating track and will engage suspension of the wheel just as it should in real-life.
The hierarchy of components in such setup is following from top parent to last child:

  • scene component (optional but makes it easier to keep everything organized in the list of blueprint components)
    • torsion bar lever mesh with some collision primitive (has a road wheel attached on one side and connected to chassis on other side)
      • roadwheel collision mesh
        • visual road wheel mesh (no collision primitive) it will follow movement of the wheel collision mesh just by being a child of it and rotation we will handle separately later
        • track anisotropic friction component, will handle friction of this road wheel with the ground and obstacles
      • physics constraint for road wheel which firmly attaches collision mesh of wheel to the end of the torsion bar lever
    • physic constraint for torsion bar lever (connects lever to chassis and has angular motor to imitate suspension)

Some typical settings for the physics constraints.
Torsion bar lever physics constraint with angular motor should restrict any linear movement of the lever but allow limited rotation of the lever in a single axis:
ebf6e08bbf328d693f43be8dec376768018835ed.jpeg
In this case, the name of the chassis component is “Root” and name of the suspension lever static mesh is “SuspensionHandleFrontFR”. Variable “Angular Motor -> Angular Position Strength” is responsible for overall force of the spring, the heavier the tank the more force you will need to keep proper clearance between bottom of the tank and the ground. Variable “Angular Motor -> Angular Velocity Strength” is a dampener and is responsible for how “wobbliness” of suspension. The higher the values the faster oscillation will stop and suspension will come to rest. It’s important to always have some higher than zero value for this variable as otherwise motor will behave weirdly in respect to the strength of the suspension.

Typical physics constraint that attaches collision wheel to the torsion bar lever is this:

Collision meshes of the roadwheel/sprocket/idler need to use a special physics material called “SmallFrictionMaterial” in MMT_Content. This material has following default settings:
059cecce6b060432c39f6e70e8c268e6bb0b512a.jpeg

The easiest way to make sure that material is assigned to static mesh is by opening static mesh in editor and selecting SmallFrictionMaterial in “Static Mesh Settings -> Simple Collision Physical Material”:
97c1484566cd407a88e28f642b7a50241ced6494.jpeg
Another important detail visible here is a socket “Tread” which is later used by track spline to “follow” the wheel as it moves up and down. As you can see, socket is not placed on the edge of the collision as collision extends all the way to the far side of the track and spline control points are expected to be in the middle of the track thickness.

Thanx !

I will store this information and start on creating the additional geometry needed for the physics part.

I will first move the Tiger to the new MMT system, and when it is up and running break it down to create a setup tutorial video like with the n-wheeled blueprint.

When I encounter any questions in the first part I will let you know.

Peter

Friction

There are couple of things we need for track friction. A set of “Track Anisotropic Friction” components, one per each roadwheel, sprocket and idler. The rotation and position of these components is important, in local space of the tank, their Y coordinate should be exactly in the middle of the track and X and Z coordinates should match the center of the roadwheel/sprocket/idler. The easiest way to achieve this is by making Track Anisotropic Friction component a child of the roadwheel/sprocket/idler and set their position to zero, with some offset in Y coordinate in case if pivot of the roadwheel/sprocket/idler is not centered to the track. In case if roadwheel/sprocket/idler were turned around 180 degrees (placing right element on the left side for example) then Track Anisotropic Friction component should be rotated locally 180 degree, so it’s X axis matches with the tank’s X axis. Example of such positioning and settings for the friction are following:


On a screenshot, component is a child of RoadWheelPhysicsLeft03 static mesh, which is used for collision of the track with the ground. Friction parameters MuX/MuY Static and MuX/MuY dynamic are symmetrical indicating that track will have the same friction regardless if it’s sliding sideways or not. But it’s common for tracks to have a higher coefficient in X axis than Y as they can have “grabber” element which improve traction of the track on a soft ground. “Effected component name” variable is the name of the root component or a body to which friction should be applied.

To process friction we need two auxiliary functions to glue the logic. One is “Reset Friction Points” which is called by a first OnComponentHit event of any collision mesh of roadwheel/sprocket/idler. When we use physics sub-stepping a number of collisions and OnComponentHit events will happen for each collision mesh. These events are not send per sub-step but rather per tick. For this reason, data that we capture on each OnComponentHit event is stored in array in each appropriate TrackAnisotropicFriction component. The purpose of the ResetFrictionPoints function is to make sure that on every tick, all arrays of data in TrackAnisotropicFriction components are empty, as sometimes more OnComponentHit events will happen than there are physics sub-steps to process them.
Typical implementation of ResetFrictionPoints function is following:
275d8afcfe63a6764ff4a0362ae458f1cfc66b1b.jpeg

and this is how collision data is captured on example of a single collision body:


Each collision event with call ResetFrictionPoints, but only first one will empty arrays from left over data of previous frame. RegisterFrictionPoint is a member function of TrackAnisotropicFriction component that will store new collision data into array, to process it later on UpdateFriction cycle which will actually calculate and apply friction force.

In the next step we will look into second auxiliary function - UpdateFriction.
[to be continued]

I used MMT plugin to move Abram M1 tank and build a firing system on top of it. Here you can see some basic main turret firing in action. Thanks for the great plugin (and of course everyone else who spent some time on this)

Looking good Kyillene! Did you use the m113 setup?
@ : I’m starting to move the wheels,idler and sprocket in the new modular setup. Am creating a suspension arm since I want to set it up like a real torsion bar suspension. just have to check all my technical drawings for the dimensions and location.
I see now what you mean with the angular motor in the Physics Constraint… this is a great way for now to do the Torsion bar. Do you have plans to turn these constraints into some sort of MMT node as well? Or do you keep using the physics constraints that are in UE4 right now?

I also have sound clips now for the maybach engine… starting sound, idle, rev up, etc. Just need to figure out where to put them… If you have any suggestions based on the outputs of the various engine and transmission nodes… just let me know.
I know sound comes later…

Peter

hey

Here’s a start with the wheel setup.

Do you have a simple way of copying an entire Hierarchy for a wheel?
As you can see when you look at 1 roadwheel setup… it’s Hierarchy is like this.

-SuspensionRight_01 (Scene component)
—SuspensionArmRight_01 (Static mesh with collision volume and collision enabled)
------SuspensionArmRight_01PC (This is the Physics constraint holding the suspension arm to the Hull, This one has the angular drive enabled and is limited in Y only, rest is locked)
------RoadwheelPhysicsRight_01 (Physics Collision mesh for the Wheel, collision and physics enabled)
---------RoadWheelVisualRight_01 (Static Visual Mesh)
---------RoadWheelPhysicsRight_01PC (This is the Physics constraint holding the Roadwheel to the SuspensionArm
---------RoadWheelPhysicsRight_01TAF (This is the track Anisotropic Friction component)

The Tiger has 16 of these road wheels, and If I cannot duplicate the entire wheel Hierarchy … it’s going to be a hell to setup and tweak.

For now I added simple Cylindrical Physics Collision Wheels… I will replace them later with a better shape. I just need to get all the wheels working and suspension functioning first.

Nice work! Happy to see the results :slight_smile:

For the torsion bar I haven’t decided yet. Most likely there will be a separate component as there is one for springs, but I haven’t decided yet on all of the implementation details for it. Physics constraints should be working fine for this purpose, the only issue with them is that they press on wheels with the same force as on chassis, which is physically correct but can lead to some undesirable effects. In any case, it will be easy to replace them.

With sounds situation is following - if you check modular drive train (press 8 to posses) it has sounds on everything except tracks and rotation of sprocket/roadwheels. It’s very easy to add even more sounds and I’m pretty sure it can be done much better than what I did as I have little experience with it. For an “arcade” version of tank they can be added too, like sound of engine can be driven just by throttle, I think this is how it’s done in WarThunder and it seams to be working just fine.

Unfortunately I haven’t found an easy way to copy components, UE4 does rather bad job in this respect, it doesn’t auto-iterate names and looses hierarchy when you copy a set of components. It took me more than a day to assemble T-26 fully because of this.
I was looking into options where components would be added in constructor from some sort of configuration, but there is issue with it too - OnComponentHit events have to be assigned manually, there might be some way to do it from c++ but I’m not sure how to do it properly and still be clear for BP.
The fastest and safest way was to copy components one by one, drag them into new position and rename.

Hierarchy looks fine except Physics Constraints, place them on the same level of hierarchy as the 2-nd component that they connect. Meaning SuspensionArmRight_01PC should be a child of SuspensionRight_01 (Scene Component) and RoadWheelPhysicsRight_01PC make a child of SuspensionArmRight_01 (Static mesh with collision volume and collision enabled). I know that in T-26 I did it differently but I don’t think that it’s the right way as in such case constraint is moving together with object it constraints.

I want to test if it’s possible to use Skeletal Meshes as elements of the suspension, something like all collision and visual components of a single suspension stack would be a single static mesh. I don’t think it will work but if it does it will save a lot of this labor.

Thanx,

I would not bother with Skeletal meshes just yet.
I like the fact that you add all meshes as seperate objects in the blueprint.
Doing that with a skeletal mesh makes it more of a hastle to prepare everything… since you must make sure everything is setup right in Modo already.

With the current way it is very easy to start setting up everything without having the final model ready.
Just like I’m currently setting it up with low resolution standin objects… and can later replace the parts with the Final Highres geometry as I move along.

I changed the Hierarchy with the constraints… and will just continue manually copying and renaming the rest of the wheels.

I’ll report back when the wheels are in place.

This is the current wheel hierarchy for the Tiger

ice_screenshot_20160620-232342.png

This should be fine.