[OPEN-SOURCE] Machinery Modelling Toolkit

[BoredEngineer]

Btw : How did you move the M113 over to MMT?
Did you re-setup the whole thing? Or did you import the Blueprint from the N-Wheeled project and did some minor tweaking?

Just in case I do something stupid, or re-doing things I don't need to re-do

I've migrated them as assets into MMT. In principal you could try to migrate tank that you already have the only issue is that it will try to bring assets which are already there like A_TrackedVehicle BP and meshes. Give it a try after making backup copy

EDIT: Second thought on how to deal with all this in feature. Instead of being locked into MMT_Content as a basis for your project. You can migrate just specific components/BPs which you want to use as a basis. Copy/paste C++ portion of the plugin and you are good to go. Anytime components or BP is updated, you just migrate it's fresh version into your own project and overwrite existing content. Eventually the most common components will be moved into C++. It's not only better performance wise but update of functionality of component becomes transparent to you. Kind of how A_TrackedVehicle worked but on a smaller scale - on a scale of specific component. Non C++ components made in BP have to be migrated.

[BoredEngineer]

Update

Fresh update of plugin and content example.

0lento contributed an improved version of the function that can return valid transform of components during physics sub-stepping. I've added some small features to it and replaced old implementation. Thank you, 0lento!

- New implementation of "MMT GetTransform -Comp" returns transform of any component (starting from SceneComponent and higher in class hierarchy) and optionally returns transform of socket. This shrinks amount of code which need to be written when working with locations of components and makes code and components a tad more reusable
- Switched code to use new implementation of MMT_GetTransform_Component, removed several BP functions and node which became redundant as a result of using new implementation.
- Fixed lag of air-cushion skirt animation. Now bones are animated in the local space instead of setting their world position as it was before. This removed the lag of animation and it can be updated just a single time per frame.
- Deprecated PropellerEngineForNonPhysicalComponents as physical version now works with all components.
- Added a check to invert signal of PID controller if engine is working in reverse. Previous PID controller weren't capable of steering hovercraft properly when going in reverse.

Fresh executable: https://www.dropbox.com/s/55dazkm8q4...ntent.zip?dl=0

So this is how BP looked before if we needed to retrieve a socket transform during sub-stepping:

this is how it looks now:


SpringAndDampener components are suppose to be re-usable and this is what I had to do to retrieve transform of attachment points with optional attachment to the socket:

and now I need to do just this:


The best part is that new implementation removes necessity to think about what your components are. For example you couldn't get a proper sub-step transform for scene component if you didn't deliberately made a BP to gather all transforms in chain to the next physics simulating parent, now all this is handled in C++.

[DanaFo]

This is all pretty rad! I'm currently extremely miffed with the physx constraints so it's nice to see there's options out there!

[BoredEngineer]

Update

This is all pretty rad! I'm currently extremely miffed with the physx constraints so it's nice to see there's options out there!

Enjoy!


New additions:
- Anisotropic friction component - simulates static and kinetic friction. Uses different friction coefficients along X and Y axis of the contact point. Must have to simulate behavior of ice-skates, sled, ski or simplified version of tires.
- Simple friction component - is a simplified version with a single friction coefficient applied equally in all direction. Useful to add friction when you can't provide it using collision mesh. For example, Hovercraft uses this component to simulate friction of air-cushion skirt with the ground.
- Air drag component - first aerodynamic component added to MMT. Provides velocity dependent air drag, take into account air density, surface area and shape of the object. Shape influence is approximated using drag coefficient: https://en.wikipedia.org/wiki/Drag_coefficient

Hovercraft is now using simple friction component to simulate friction of the skirt. The amount of friction depends on the mode of the engine: the higher hovercraft hovers the less friction is there. Some tweaking is still required but basic behaviour is there. Another addition is air drag. Addition of air-drag placed a limit on vehicle top speed and removes part of the skidding inertia at high velocity.

Fresh version is uploaded to github and compiled version is here: https://www.dropbox.com/s/55dazkm8q4...ntent.zip?dl=0

[0lento]

Air drag component - first aerodynamic component added to MMT. Provides velocity dependent air drag, take into account air density, surface area and shape of the object. Shape influence is approximated using drag coefficient: https://en.wikipedia.org/wiki/Drag_coefficient

I briefly looked at your BP drag equation and there was few things that seemed off to me. First the speed in the equation should be m/s, not km/h (although in unreal we have cm's). Other issue is that you don't square the velocity, instead there's normalization (?). To get that u^2 so that you can use it for drag counter force, you can do -Velocity * Abs(Velocity).

edit-> I realized what I wrote initially didn't make any sense (you can't abs vector), but what I explained on the next paragraph will work

I do this separately for each local velocity component (surface area usually differs based on the direction). If you do that, then local X velocity will be (-LocalVelocity.X * Abs(LocalVelocity.X) and so on, you then just need to transform that into world space in the end.

Btw, you can use terminal velocity to verify that your aero drag equation works right. You can calculate it manually but I've used just built in calculators, they all seem to give same results for me, for example www.calctool.org/CALC/eng/aerospace/terminal . I've tested this myself by placing the simulated object at 10km height on level, set initial velocity near the calculated terminal velocity value, put a print of the velocity on tick (to see if the value tries to reach the exact terminal velocity, tries to slow down or tries to get faster) and just started the simulation.

[BoredEngineer]

I briefly looked at your BP drag equation and there was few things that seemed off to me. First the speed in the equation should be m/s, not km/h (although in unreal we have cm's). Other issue is that you don't square the velocity, instead there's normalization (?). To get that u^2 so that you can use it for drag counter force, you can do -Velocity * Abs(Velocity).

I do this separately for each local velocity component (surface area usually differs based on the direction). If you do that, then local X velocity will be (-LocalVelocity.X * Abs(LocalVelocity.X) and so on, you then just need to transform that into world space in the end.

Btw, you can use terminal velocity to verify that your aero drag equation works right. You can calculate it manually but I've used just built in calculators, they all seem to give same results for me, for example www.calctool.org/CALC/eng/aerospace/terminal . I've tested this myself by placing the simulated object at 10km height on level, set initial velocity near the calculated terminal velocity value, put a print of the velocity on tick (to see if the value tries to reach the exact terminal velocity, tries to slow down or tries to get faster) and just started the simulation.

I've copy pasted it from my old code and I do recall some sort of unit conversion done there. Have to check why it was done, converting to km/h indeed sounds strange.
As to square of velocity, I think it's just plugged twice into equation, so V^2 = V * V. Or do you mean something else?

Thank you for the link, I'll validate the calculations.

[BoredEngineer]

Update

Added links to OldRaven's tank tutorials from Tracked Vehicles project to the first post.

Math of air drag was indeed wrong. Thank you, 0lento for spotting it!

- Fixed simple air drag implementation and constants are pre-calculated as we are not dealing with variable air pressure (at least right now)
- Added 3D Air Drag. It helps hovercraft to lose side velocity while skidding as sides less aerodynamic and have higher air drag than the front of the vehicle
- Hovercraft's propeller engine power is heavily nerfed. Friction set to more realistic coefficient of rubber. Now it's easier to slide sideways as real hovercrafts do. Addition of air drag helps with making it more controllable in turns and caps top speed.

For gameplay purposes it's very easy to make hovercraft slide much less and get behaviour similar to handling of hovercraft in Battlezone. But challenge here was to get this thing moving and steerable with a single physics based control!

Fresh executable: https://www.dropbox.com/s/55dazkm8q4...ntent.zip?dl=0

[BoredEngineer]

My apologies to whoever used GitHub repository of MMT_Content - for at least a week source code on github was broken. Not sure why, but git plugin for UE4 didn't handled re-directors properly and I've missed that they were not committed properly to repository. Fortunately my local repository is working fine and now I've properly merged everything with master branch. I've tested both cloning from master branch and downloading as archive, both work properly. Enjoy!

[BoredEngineer]

Update

Tracked vehicles now fully support physics sub-stepping. Suspension and handling don't freak out anymore if FPS changes:

Dust particles are now working again, previously I forgot to add physics materials to Project Settings->Physics->Physics Surface settings.
Steering is still problematic at the end of the 1-st gear and higher. Engine simply doesn't not produce enough torque to overcome inertia of the track. To steer, you have to press on brakes first, to slow down tracks and only then you can do a sharp turn.
It's possible that I'm missing some vital physical connection between rotation of the axle and engine and in real life axle wouldn't be able to accumulate so much velocity. Either I need to fix this aspect or simply change steering. As far as I know M113 is using breaking steering, not a differential steering that I'm using right now. Breaking steering will allow sharp turns and I'll figure out later how proper differential steering is suppose to work.

Master branch on Github repository is updated and this is the link to latest executable: https://www.dropbox.com/s/55dazkm8q4...ntent.zip?dl=0

[DanaFo]

Forgive my ignorance, is this being developed as a plug-in or as a full engine extension? I'm just curious as to how to integrate this in a project that may change as UE4 produces newer versions?

Looks awesome either way, keep it up!

[OldRaven]

Nice, curious about the difference with sub stepping enabled for tracked vehicles.
I'm a bit busy with another project.. but will continue moving my stuff over to MMT soon.

Thanx for adding the video links again , I will update a video if necessary in the future.

[BoredEngineer]

Forgive my ignorance, is this being developed as a plug-in or as a full engine extension? I'm just curious as to how to integrate this in a project that may change as UE4 produces newer versions?

Looks awesome either way, keep it up!

Thank you!
It's developed as a plugin, so it can be copy/pasted into any project to provide essential functions for custom physics calculations. C++ code of the plugin is always included, to be able to compile it for different platforms and any version of the engine.

As a note, there are two parts:
1) Plugin - contains basic classes and functions which provides means to do your own calculations during physics sub-stepping in blueprints
2) Content example - provides examples of custom BP components which can be used to model machines

Regarding integration in general. I'll be upgrading both plugin and content examples when 4.11 is released, 4.10 version will go into a separate branch. Same will happen to 4.11 when 4.12 is released. But nothing prevents you from using plugin and content examples with the latest version of UE4, it's just certain things might not work as expected. If something works differently in latest version it can be always patched up.

Long term plan is to move the most re-usable components into C++, like PID controller for example. Some components will stay implemented only in BP, so it's easier to make a copy of them and customize for a specific machine. For example, air pressure thruster component is very specific to hovercrafts and hardly can be used on anything else. Something like a propeller engine, can be used on many different machines, so it makes sense to move it to C++ and leave BP code as reference.
The reason why I'm saying this ^ is because I'm not sure how someone can integrate with BP project. With plugin it's easy, you just copy/paste a fresh version into your project and its done. In some cases you might need to re-compile BPs.
With BP projects you need to migrate assets and while engine will pickup all dependencies himself, I'm not sure how something like hovercraft can be used as a basis. For example with Tracked Vehicles, there is a base BP class A_TrackedVehicles, which contains minimal amount of visual elements but contains almost all code. One can create a child of it and provide it with their own models and settings of variables. Later when you want to update to latest version of A_TrackedVehicles, you simply migrate it into your project and re-compile child blueprint. With hovercraft this is not the case - making a child of it will inherit all visual and logical components which can't be removed, only their settings can be altered. Most of the logic is inside of the components and those can be updated by migrating fresh version. The "glue" code is in the pawn itself, could be migrated if you don't change it in your custom machine, otherwise can be copy/pasted if you know what exactly was changed. Tool for comparing BPs can help here but all this sounds like a lot of work to stay up-to-date.

Ideally, we would have components such as engine, wheels, gear-box and etc. You add them to the pawn or actor and other components would automatically find them and work with them using interface calls. Practically speaking, I think this can be achieved only partially. To have a better control over what is going on you need to write glue code. For example to make sure that component's physics update is done in desired order or to track if some components like a wheel where blown off by explosion/collision. For this glue code to be easily portable, machines have to be build in a more abstract way and it makes sense to do it only if you are planning to have multiple designs of the same type of vehicles in your game.

Maybe someone can have a better idea how this can be approached. Approach of building everything in C++ and be able to change only data portion in BP, like its done in VehicleComponent, doesn't sound too appealing. But building everything out of "smart" components might tax performance more than necessary. Some hybrid approach is needed.

[BoredEngineer]

Nice, curious about the difference with sub stepping enabled for tracked vehicles.
I'm a bit busy with another project.. but will continue moving my stuff over to MMT soon.

Thanx for adding the video links again , I will update a video if necessary in the future.

It became smoother. On my main machine, when I run it from the editor I can see that sometimes fps goes under 60 fps. Most likely it's because of the hovercraft being there in the scene (hovercraft is not really optimized and doesn't have sleep functionality). In Tracked Vehicles project, there is a pile of physical wheels, which are taxing performance too. The importance of sub-stepping will become more obvious with cars. Tanks suspension is distributed along many components, this provides smoother and more stable behavior by itself. Even if some suspension length rapidly changes, it's own force is not enough to push vehicle too much. With cars, as you have just 4 wheels, in most cases, glitches in physics will be more visible.
Btw, we can get it even smoother, I'll try to set physics sub-stepping to 120 updates per second. Just need to check how much it will effect performance.

[Luftbauch]

Very cool stuff [MENTION=12960]BoredEngineer[/MENTION]
I like the rodeo tank!

[BoredEngineer]

Very cool stuff [MENTION=12960]BoredEngineer[/MENTION]
I like the rodeo tank!

Thank you!

I need to check how suspension of tank transfers force to the ground too. That vehicle is about 3 tons, it should have pressed hovercraft to the ground much harder.