[OPEN-SOURCE] Machinery Modelling Toolkit

**No C++ is needed, this works as Rama’s Victory plugin - it adds extra nodes and classed to BP. There is no need to write C++ code unless you really want to :smiley: **

Feature plans
The long term plan is to extend plugin with more functions which a necessary for physics calculations and add more components that can be used as building blocks to model whatever you want. Components such as wheels, tracks, springs, suspension, airfoil, engine, gear box and many more. Small building blocks which can be assembled into a working machine, be it a regular vehicle, tank, airplane, spaceship and etc. I’m personally interested in all kind of unusual and not too common machines and vehicles. When it comes to modelling them you find that pre-canned solutions are not too useful. Hopefully a toolkit like this will make it easier.

Content example together with compiled plugin, can be found here:

You don’t have to use Git to get a copy of it, there is a button "Download ZIP "to get a zip archive of the repository.
C++ source code is included for your convenience, you don’t have to do anything with it.
To use plugin in your own project just copy folder “Plugins” from this repository into main folder of your project. Blueprint projects will pick it up automatically. For C++ project you need to regenerate your solutions file.
Compiled version of the MMT_Content can be downloaded from here:
[MMT Content Compiled]](Dropbox - MMT_Content.zip - Simplify your life)

Plugin only repository, if you want to track changes in plugin code only:

Wiki for Plugin:

Wiki for Content Examples:

Content examples
Examples are split into two levels:
Simple Examples - are minimal pieces of code to show particular functionality
Land Vehicles - are more feature complete examples of physically simulated vehicles
Airplanes - simple landscape of 8 x 8 km size with two landing strips for airplanes

Ground deformation (WIP):
Machinery Modelling Toolkit: Ground Deformation (old feature) - YouTube](Machinery Modelling Toolkit: Ground Deformation (old feature) - YouTube)

New type of sprocket and support for two-piece link tracks:

Improved track animation:

Announcement post: https://forums.unrealengine.com/comm…514#post968514

Track simulation (WIP)

Announcement post: https://forums.unrealengine.com/show…l=1#post642895

Steering tank with clutches:

Modular Drive Train (WIP)

Announcement post: https://forums.unrealengine.com/show…l=1#post526489

Fokker DrI - WW1 fighter airplane

Announcement post: https://forums.unrealengine.com/show…l=1#post499612

Aerosled RF-8
Video: Machinery Modelling Toolkit: Aerosled RF-8 is back! - YouTube
Announcement post: https://forums.unrealengine.com/show…l=1#post494846

Previous project “Tracked Vehicles” merged into MMT and supports physics sub-stepping:
Video: Machinery Modelling Toolkit: Testing tracked vehicles with physics sub-stepping - YouTube
Announcement post: https://forums.unrealengine.com/show…l=1#post487582

Video: Machinery Modelling Toolkit: Hovercraft steering test [Part 2] - YouTube
Announcement post: https://forums.unrealengine.com/show…l=1#post484620

Using PID controller for steering
Video: Machinery Modelling Toolkit: PID Controller Test - YouTube
Announcement post: https://forums.unrealengine.com/show…l=1#post476609

Some things are not meant to fly but they can
Video: Machinery Modelling Toolkit: Teaching Aerosled to fly (part 2) - YouTube
Announcement post: https://forums.unrealengine.com/show…l=1#post495946

All this won’t be possible without contribution of the following people:
PhoenixBlack, added changes to the engine which allow to run custom physics during sub-stepping using C++: https://github.com/EpicGames/UnrealEngine/pull/585
0lento, for providing example and explanation on how calculations for custom physics during sub stepping can be executed from blueprints: https://forums.unrealengine.com/show…l=1#post454068
Thank you, guys!

Video Tutorial - How to get your own tracked vehicle plugged into the system
OldRaven made this great video tutorial on how to setup your own tank using these blueprints. Thank you, OldRaven!
Tutorial is build on the basis of Tracked Vehicles project and should work exactly the same in MMT.
First part - how to change visual model: UE4 Tracked Vehicle Setup Part1 (Tank) - YouTube
Second part - wiring of wheels and suspension: UE4 Tracked Vehicle Setup Part2 (tank) - YouTube
Third Part - setting up the splines for track animation: UE4 Tracked Vehicle Part3 (Tank) - YouTube


Interesting… since I have more than tanks to play with.

I’m not familiar with C++ in projects on UE4 so will have to look into that if I can get this to work…

The only limitation is to have Visual Studio installed so Unreal Engine can package the game. This limitation might be lifted with 4.11 or 4.12 when plugins becomes available on marketplace, to my understanding this is one of the reason why there not there already. Let me know if this raises any concerns!

Hi BoredEngineer,

I see you’ve cleaned up things from my example nicely there :slight_smile: (it was a bit of a mess, I admit).

This is actually a pretty good plan, especially as nothing in the plugin itself is BP specific. It would make sense to keep it that way as that would mean that everyone can use it also for c++.

If we plan to develop these tools into that direction, it would be best to describe the model as generic solution for both c++ and BP and not only focus on exposing things for BP but keeping things BP compatible, that way this would benefit the whole community here.

You could just add a separate branch to the github repository but I’m not sure if maintaining two separate branches/repositories would be that helpful. If someone uses git for their version control, it would still be difficult to handle two repositories inside single project folder. In such case it would be better to just sync the plugin on a separate directory and for example use symbolic linking for the plugin folder to get the changes into the main project.

You don’t have to make those getters for substepping separately, current BP nodes for those work as is. Only AddTorque is needed and you can see it already on my example project (I did post update it so if you grabbed previous version it may have not been there).

Just to make this clear, only problematic bits are reading transforms, locations, rotations etc using built in getters (as they are not updated for each substep) and adding forces and torques (as they don’t send the forces directly to physx by default if substepping is enabled).

If the node is specificly about getting the value for physics, it’s ok for using on sub-steps as well. Those physics getters read those values from physics scene already via BodyInstance. Same thing also applies to all traces etc (it’s safe to use traces from physics ticks/on sub-stepping).

edit-> Add Impulse and Add Angular Impulse also work as is as they fire only once, they are internally dealt the same regardless if sub-stepping is enabled or not.

As additional note, you can read relative values using regular BP nodes as long as the components itself don’t simulate any physics (have simulate physics enabled, are constraints etc). As long as they don’t simulate physics, relative values are updated only on tick, therefore they are always up-to-date and are safe to use on physics ticks too.

This all can sound pretty confusing but there really are only three specific rules when you use sub-stepped physics ticks:

  • Don’t add force (including torque) using regular engine nodes (impulses are fine).
  • Don’t get any transforms/locations/rotations using regular engine nodes for actors/components that simulate physics themselves.
  • Don’t directly change any transforms/locations/rotations on physics tick (you can still store data on variables and pass it to regular Tick). Only use physics tick to interact with the physics scene using forces, velocities etc.

Thank you for clarification, I don’t have to re-invent the wheel then! So only AddTorque is missing from basics. This is really good news. I didn’t added all of them at ones as it was a gradual re-factoring process and figuring out how to make everything more readable in BP.

For plugin itself I keep a separate project so I could make a separate repo for it, at least on my side. This way it should be easier for someone to see only plugin updates if they are not interested in example content. Plus, it should be easier to roll back to a specific version of the plugin. What do you think?

In my opinion, I think it’s ok to have example project in the same repo but it’s really up to you. :slight_smile: It’s still relatively easy to just copy/paste or symlink the actual plugin folder to your own project.

hi, is there any video to see early features in action?

I want to place a second repo just for the plugin so people can easily track changes of plugin only. Just to be clear what I mean by “Content Examples”, there will be some simple examples, like current StayUpRight pawn, together with more complicated ones, like a tank and aerosled that I need to port here.

Not yet. What you can do now is just start the project and interact with pawns placed in the level. “F” will push self balancing cone.
Logic for self balancing cone is done in BP, its a simple example on how to do custom physics during physics sub-stepping.
To feel the difference of what will happen without physics sub-stepping, you simply need to switch it off in project settings:

and then type “t.maxFPS 15” in the console after you start game. FPS will drop and behavior of cone will change as physics is not updated frequently enough. Now you can enable sub-stepping again and even at 15 fps it will work just fine. Set “t.maxFPS 300” to get it running back as normal.

t.maxFPS -1 is default value I think. I’ve used it like that to get it back to normal :slight_smile:

Added to the first post!

I should add more detailed guideline regarding choosing sub-stepping. Normally we care only about what happens when FPS drops but there is the same problem when it get’s too high. Like for example, if your game performs really well and player is not using v-sync, FPS can go up beyond typical testing rates and then all physics relying on size of delta time get screwed. So far the only idea I have is to cap max FPS to something that you expect people to run it on. Like for example you cap FPS to 60 and leave default sub-stepping settings, which are set to update physics approximately 60 frames a second.
Downside of this approach is that people who have higher refresh rate monitors won’t be able to enjoy their 100+ fps on their 120hz-plus monitors. In this case you could go with smaller Max SubStep Delta Time, like 0.0083333333 for 120 physics updates a second and at least 8 Max Substeps so all substeps could be executed even if fps drops to 10. This will get you smoother physics too, but it will cost performance.

Trying to package copy of MMT_Content. Added an dummy C++ class, but getting some linking error:
MainFrameActions: Packaging (Windows (64-bit)): UnrealBuildTool: UELinkerFixups.cpp.obj : error LNK2019: unresolved external symbol “void __cdecl EmptyLinkFunctionForStaticInitializationMMT(void)” (?EmptyLinkFunctionForStaticInitializationMMT@@YAXXZ) referenced in function “void __cdecl UELinkerFixups(void)” (?UELinkerFixups@@YAXXZ)
MainFrameActions: Packaging (Windows (64-bit)): UnrealBuildTool: D:\Unreal\Unreal Projects\MMT_Content2\Binaries\Win64\MMT_Content2-Win64-Shipping.exe : fatal error LNK1120: 1 unresolved externals

what it can be? because I do have MMT.h and MMT.cpp but class inside is not MMT, mentioning it because it seams to referee to …MMT(void)

If you test low FPS often, something like this can be handy while prototyping:

Ideally you’d also check if game is running in the editor but I’m not sure if you can do that with BPs.

Ok, bug fixed. Now packaging works. I’ve added link to compiled version.

Thank you, 0lento! I’ll add this into project together with some basic GUI.

Do you know if this was fixed in 4.11 or master? If not, would you mind if I try to base a fix off of this plugin?

I’ve talked to 0lento about this some time ago and we came to conclusion that as this feature is hardly documented and perhaps even experimental, we won’t see it as a first citizen anytime soon.
It would be splendid if it get’s accepted! Please do! The plan is to build up components to build machines, from this perspective it would be much easier if sub-step friendly function are provided out of the box by the engine, instead of rely on plugin which have to maintained.

I was looking for some real-life or sci-fi machine. Which would be not too difficult to model in the sense of code and necessary math. It’s purpose is to be a sort of tutorial/example on how to use plugin. Potentially with building few components that can be re-used later on other machines. So far I’ve boiled it down to Hovercraft, a prototype of the real one with an air-cushion, not magnetically levitating or using thrusters to move around.
Basic model is almost done, just need to rig the “skirt” so it could be compressed and animated:

Steering and moving forward will be done using the engine on the back, which can be rotated to steer left/right. Air-cushion is going to be modeled as a set of invisible primitives to provide friction with the ground and some simple animation of the skirt. The physical effect of hovering will be done with a component which will approximate air pressure at some selected point under the aircraft. Most likely we will need a couple of PD or PID controllers to help driver with steering.
So far my only concern is adequate collision of the skirt with surrounding objects. Skirt is done as a skeletal mesh, so it can be infated/deflated and animated when hovercraft goes over obstacles. Animation can be done by placing physics primitives attached to the chassis using constraints, movement of these primitives will drive bones of the skirt, which should animate surface. For collision of the skirt itself, like when two hovercrafts collide, we can use copy of the skirt mesh as static mesh, if we set it to ignore landscape or ground then it should work.

sounds neat! :slight_smile: