[OPEN-SOURCE] Machinery Modelling Toolkit

[BoredEngineer]

nstallation:
Content example together with compiled plugin, can be found here:
https://github.com/BoredEngineer/MMT_Content
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]

I am lost here....Am I suppose to to copy the whole MMTContent folder into the plugins folder I made in the project folder?...What you have stated above... I see no Plugins folder other than the one I made.

MMT_Content is a UE4 project with examples on how to use plugin and MMT_Plugin is only the plugin itself.
So in order to use plugin in your own projects you need to copy contents of the MMT_Content repo into [your project main folder]/Plugins/MMT/
Or copy paste MMT_Content/Plugins/ folder into your project.

[BoredEngineer]

Ok, it seems it's a Microsoft problem. I am using Visual Studio 2019 and latest compilers (Silly me!). Adding some more logging the problem is that the SpringDirectionLocal vector is not being normalized in the non-debug version of the code. Tracking that back to the PreCalculateParameters function the SpringDirectionLocal.Normalize() call is actually generating somewhat random vectors in the case above turning a 0,0,-40 into 0,0,-199 rather than 0,0,-1 hence the large forces generated!

Disabling global optimizations for the PreCalculateParameters function seems to fix the issue, but who knows where else this will occurr!

Apparently working version of the release build function

//Recalculate parameters to save performance
#pragma optimize( "g", off )
void UMMTSuspensionStack::PreCalculateParameters()
{
//Shift spring offsets if custom position of the stack is used
SpringOffsetTopAdjusted = SuspensionSettings.bUseCustomPosition ? SuspensionSettings.StackLocalPosition + SuspensionSettings.SpringTopOffset : SuspensionSettings.SpringTopOffset;
SpringOffsetBottomAdjusted = SuspensionSettings.bUseCustomPosition ? SuspensionSettings.StackLocalPosition + SuspensionSettings.SpringBottomOffset : SuspensionSettings.SpringBottomOffset;

//Calculate spring direction in local coordinate system
SpringDirectionLocal = SpringOffsetBottomAdjusted - SpringOffsetTopAdjusted;
SpringMaxLenght = SpringDirectionLocal.Size();

//Normalize vector and check if normalization was successful
if (!SpringDirectionLocal.Normalize())
{
SpringDirectionLocal = FVector::UpVector;
GEngine->AddOnScreenDebugMessage(-1, 15.0f, FColor::Red, FString::Printf(TEXT("%s->%s distance between Top and Bottom offsets of the spring shouldn't be zero"), *ComponentsParentName, *ComponentName));
UE_LOG(LogTemp, Warning, TEXT("%s->%s distance between Top and Bottom offsets of the spring shouldn't be zero"), *ComponentsParentName, *ComponentName);
}

//Calculate line trace points in local space, taking into account road wheel radius and tread thickness
LineTraceOffsetTopLS = SpringOffsetTopAdjusted + SpringDirectionLocal * (SuspensionSettings.RoadWheelRadius + SuspensionSettings.TrackThickness);
LineTraceOffsetBottomLS = SpringOffsetBottomAdjusted + SpringDirectionLocal * (SuspensionSettings.RoadWheelRadius + SuspensionSettings.TrackThickness);

SphereCheckShape = FCollisionShape::MakeSphere(SuspensionSettings.RoadWheelRadius + SuspensionSettings.TrackThickness);

}
#pragma optimize( "", on )

note the "#pragma optimize( "g", off )" and "#pragma optimize( "", on )" block

Looks like time to roll back to Visual Studio 2017!

Ohh wow, had no idea that this is going on. I haven't made code in a way that it would work differently on debug or non-debug. Is there are a way to combat this more permanently? I mean it will probably effect a lot of other code, not only this function alone.

[wuzzy]

Ok, it seems it's a Microsoft problem. I am using Visual Studio 2019 and latest compilers (Silly me!). Adding some more logging the problem is that the SpringDirectionLocal vector is not being normalized in the non-debug version of the code. Tracking that back to the PreCalculateParameters function the SpringDirectionLocal.Normalize() call is actually generating somewhat random vectors in the case above turning a 0,0,-40 into 0,0,-199 rather than 0,0,-1 hence the large forces generated!

Disabling global optimizations for the PreCalculateParameters function seems to fix the issue, but who knows where else this will occurr!

Apparently working version of the release build function

//Recalculate parameters to save performance
#pragma optimize( "g", off )
void UMMTSuspensionStack::PreCalculateParameters()
{
    //Shift spring offsets if custom position of the stack is used
    SpringOffsetTopAdjusted = SuspensionSettings.bUseCustomPosition ? SuspensionSettings.StackLocalPosition + SuspensionSettings.SpringTopOffset : SuspensionSettings.SpringTopOffset;
    SpringOffsetBottomAdjusted = SuspensionSettings.bUseCustomPosition ? SuspensionSettings.StackLocalPosition + SuspensionSettings.SpringBottomOffset : SuspensionSettings.SpringBottomOffset;

    //Calculate spring direction in local coordinate system
    SpringDirectionLocal = SpringOffsetBottomAdjusted - SpringOffsetTopAdjusted;
    SpringMaxLenght = SpringDirectionLocal.Size();

    //Normalize vector and check if normalization was successful
    if (!SpringDirectionLocal.Normalize())
    {
        SpringDirectionLocal = FVector::UpVector;
        GEngine->AddOnScreenDebugMessage(-1, 15.0f, FColor::Red, FString::Printf(TEXT("%s->%s distance between Top and Bottom offsets of the spring shouldn't be zero"), *ComponentsParentName, *ComponentName));
        UE_LOG(LogTemp, Warning, TEXT("%s->%s distance between Top and Bottom offsets of the spring shouldn't be zero"), *ComponentsParentName, *ComponentName);
    }

    //Calculate line trace points in local space, taking into account road wheel radius and tread thickness
    LineTraceOffsetTopLS = SpringOffsetTopAdjusted + SpringDirectionLocal * (SuspensionSettings.RoadWheelRadius + SuspensionSettings.TrackThickness);
    LineTraceOffsetBottomLS = SpringOffsetBottomAdjusted + SpringDirectionLocal * (SuspensionSettings.RoadWheelRadius + SuspensionSettings.TrackThickness);

    SphereCheckShape = FCollisionShape::MakeSphere(SuspensionSettings.RoadWheelRadius + SuspensionSettings.TrackThickness);

}
#pragma optimize( "", on )

note the "#pragma optimize( "g", off )" and "#pragma optimize( "", on )" block

Looks like time to roll back to Visual Studio 2017!

[wuzzy]

I added a log message to the suspension force calculation and set debug mode on the SuspL01 wheel

in the function: void UMMTSuspensionStack::CalculateAndApplySuspensionForce(const float& DeltaTime)

if (SuspensionSettings.bEnableDebugMode)
    {
        UE_LOG(MMT_Log, Error, TEXT("delta time:\t%s Spring Force\t%s Damping:\t%s Spring delta:\t%s SuspensionForceMagnitude\t%s Suspension Force:\t%s"),
            *FString::SanitizeFloat(DeltaTime, 6),
            *FString::SanitizeFloat(SpringForce, 6),
            *FString::SanitizeFloat(SpringDamping, 6),
            *FString::SanitizeFloat(SpringDelta, 6),
            *FString::SanitizeFloat(SuspensionForceMagnitude, 6),
            *FString::SanitizeFloat(SuspensionForceWS.Size(), 6)
        );

        DrawDebugLine(ParentComponentRef->GetWorld(), ReferenceFrameTransform.GetLocation(), ReferenceFrameTransform.GetLocation() + SuspensionForceWS * 0.0001f, FColor::Blue, false, 0.0f, 50, 1.0f);
        DrawDebugString(ParentComponentRef->GetWorld(), ReferenceFrameTransform.GetLocation(), FString::SanitizeFloat(SuspensionForceMagnitude), 0, FColor::Blue, 0.0f, false);
    }

Looking at the output I can see a significant difference in the final forces being calculated.

In this set of entries from around first contact with the ground: (debug "stable" first, non-debug "unstable" second)

MMT_Log: Error: delta time: 0.011111 Spring Force   0.000000 Damping:   0.000000 Spring delta:  0.000000 Suspension Force:  0.000000
MMT_Log: Error: delta time: 0.011111 Spring Force   0.000000 Damping:   0.000000 Spring delta:  0.000000 Suspension Force:  0.000000
MMT_Log: Error: delta time: 0.011111 Spring Force   546858.000000 Damping:  -546858.000000 Spring delta:    0.841320 Suspension Force:  1093715.875000
MMT_Log: Error: delta time: 0.011111 Spring Force   713410.187500 Damping:  -713410.187500 Spring delta:    2.121735 Suspension Force:  1426820.250000
MMT_Log: Error: delta time: 0.011111 Spring Force   738128.000000 Damping:  -738128.000000 Spring delta:    3.338608 Suspension Force:  1476255.875000

MMT_Log: Error: delta time: 0.011111 Spring Force   0.000000 Damping:   0.000000 Spring delta:  0.000000 Suspension Force:  0.000000
MMT_Log: Error: delta time: 0.011111 Spring Force   0.000000 Damping:   0.000000 Spring delta:  0.000000 Suspension Force:  0.000000
MMT_Log: Error: delta time: 0.011111 Spring Force   546855.562500 Damping:  -546855.562500 Spring delta:    0.841316 Suspension Force:  217897360.000000
MMT_Log: Error: delta time: 0.011111 Spring Force   1462500.000000 Damping: -1462500.000000 Spring delta:   39.998283 Suspension Force: 582740480.000000
MMT_Log: Error: delta time: 0.011111 Spring Force   1462500.000000 Damping: -481.977570 Spring delta:   39.998821 Suspension Force: 291466272.000000

Comparing the two lines:

MMT_Log: Error: delta time: 0.011111 Spring Force   546858.000000 Damping:  -546858.000000 Spring delta:    0.841320 Suspension Force:  1093715.875000
MMT_Log: Error: delta time: 0.011111 Spring Force   546855.562500 Damping:  -546855.562500 Spring delta:    0.841316 Suspension Force:  217897360.000000

The spring movement, force and damping calculations are almost identical, but the final vector magnitude differs wildly

[wuzzy]

I had an issue in my project so I went back to the MMT_Content project and seem to have reproduced it there as well. There seems to be a difference between Debug and Non-Debug built versions of the code. In the Debug version the springs behave as expected, in the Non-Debug build they are permanently active and move the tank around the map. Problem is with the LightTankTraceWheelsWithAnimBPPrototype vehicle.

This is a link to a youtube video of a PIE session built with the Visual Studio editor project in "Development Editor" Non-Debug C++ build, as you see the tank collapses the suspension and moves on it's own around the level.

https://youtu.be/Z60T_R-hU-8

This is the same project but with the editor project compiled for "DebugGame Editor" ie with C++ Debug on. At run the suspension takes the weight and relaxes but the tank remains in place.

https://youtu.be/2nXEjraFAYw

Not sure where to look for this one? Is there some limit checking code with side effects, compiled only in the debug build?

[8inkolot]

nstallation:
Content example together with compiled plugin, can be found here:
https://github.com/BoredEngineer/MMT_Content
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]

I am lost here....Am I suppose to to copy the whole MMTContent folder into the plugins folder I made in the project folder?...What you have stated above... I see no Plugins folder other than the one I made.

[BoredEngineer]

Sort of what I was thinking, but I can't see how you specify a channel for the sweep, can't see anything in the code, only custom trace channel appears to be "Tread". which I have duplicated. I have also duplicated the Object channels Suspension, Chassis, Wheels and Tracks.

Ahhh, now I remember. You can select channel as property of the SuspensionStack component for Ray and Sphere trace. For shape trace it uses settings of the "shape" itself. I don't remember why it's like that, maybe for simplicity or there where some cases where this was needed.

I think I may have found my issue, but I can't explain how or when it happened. In the migrated blueprint the collision section of all of the RoadWheelPhysics... components had the object type in the custom collision section changed from "Wheels" in the MMT project into "Suspension" in my new project! (I do hate the way these sort of things randomly happen with this blueprint stuff). Changing them all back to "Wheels" seems to work, They are now "Query only" collisions that do "Block" on the floor slab which does make sense. I just have to hope nothing else was changed in the migration process!

Yes, I think it happens because of the custom collision/query channels and I'm not sure if it matters if you add them upfront or not, they might not work anyway until you manually set it again.

[wuzzy]

I think I may have found my issue, but I can't explain how or when it happened. In the migrated blueprint the collision section of all of the RoadWheelPhysics... components had the object type in the custom collision section changed from "Wheels" in the MMT project into "Suspension" in my new project! (I do hate the way these sort of things randomly happen with this blueprint stuff). Changing them all back to "Wheels" seems to work, They are now "Query only" collisions that do "Block" on the floor slab which does make sense. I just have to hope nothing else was changed in the migration process!

[wuzzy]

Sort of what I was thinking, but I can't see how you specify a channel for the sweep, can't see anything in the code, only custom trace channel appears to be "Tread". which I have duplicated. I have also duplicated the Object channels Suspension, Chassis, Wheels and Tracks.

[BoredEngineer]

I have migrated the assets from the MMT_Content project for the "LightTankTraceWheelsWithAnimBPPrototype" into another new project where I have the latest MMT Plugin installed. The new project is using UE engine version 4.23, and I have the latest plugin.

The assets for the LightTankTraceWheelsWithAnimBPPrototype have come across and appear to compile without error. I believe I have taken the required collision and Physiscs substepping settings from the MMT_Content project across to my new one.

But when I run in editor, the tank sinks through the ground and sits on the bottom of the hull. I have debugged the "ShapeSweepForContact" in "UMMTSuspensionStack" and there are no hits detected.

I am currently using a flat plate floor in a test level. This has the default collision, in particular the "Suspension" Object response is set to ignore as per the MMT_Content example.

If I change the floor slab collision for "Suspension" object response to "Block", the "ShapeSweepForContact" registers hits and the tank sits correctly on the floor.

My problem is I don't understand why the original MMT_Content project hits do register, as the floor there seems to "Ignore" hits from "Suspension" objects?

What am I missing? There must be something in my project setup I have not done!

Most likely it used some custom collision channel. Compare project settings for this.
I think, suspension should work only against the selected query channel and that channel should be blocking as there physically suspension doesn't collide, it just runs a shapetrace.

[wuzzy]

I have migrated the assets from the MMT_Content project for the "LightTankTraceWheelsWithAnimBPPrototype" into another new project where I have the latest MMT Plugin installed. The new project is using UE engine version 4.23, and I have the latest plugin.

The assets for the LightTankTraceWheelsWithAnimBPPrototype have come across and appear to compile without error. I believe I have taken the required collision and Physiscs substepping settings from the MMT_Content project across to my new one.

But when I run in editor, the tank sinks through the ground and sits on the bottom of the hull. I have debugged the "ShapeSweepForContact" in "UMMTSuspensionStack" and there are no hits detected.

I am currently using a flat plate floor in a test level. This has the default collision, in particular the "Suspension" Object response is set to ignore as per the MMT_Content example.

If I change the floor slab collision for "Suspension" object response to "Block", the "ShapeSweepForContact" registers hits and the tank sits correctly on the floor.

My problem is I don't understand why the original MMT_Content project hits do register, as the floor there seems to "Ignore" hits from "Suspension" objects?

What am I missing? There must be something in my project setup I have not done!

[BoredEngineer]

Well, MMT_Content crashes on editor load, on one of the map objects:

Assertion failed: Pair != nullptr [File:D:\Build\++UE4\Sync\Engine\Source\Runtime\Core\Public\Containers/Map.h] [Line: 495]

Will see what can be done about this.

EDIT: And again debug symbols where not installed and can't install them because - error: IS-0001 in the launcher...

[BoredEngineer]

The plugin was ported earlier this week. For Content it's enough to drop new plugin in and then upgrade uproject. But I'll port it anyway.
In 95% of cases there are no changes with UE4 version as far as plugin is concern, you just have to change engine version in .build and recompile.

[Sound_Priest]

Hi BoredEngineer! When can we expect 4.23 adaptation ?

[Telapicus]

Anyone ever get this working in multiplayer, whatever i try to do it either doesn't move, moves on client but not server side, or just spazzes out, any help?