[OPEN-SOURCE] Machinery Modelling Toolkit

[Thunder_Owl]

Just pushed 4.24 version to the master. There are some small changes. What would be cool is to get rid of all warning about PCHs.

Thank You!

[BoredEngineer]

Hello. I did check on github, is it so that 4.24 version of plugin does not exist yet? Or am I looking wrong place maybe Thank You!
EDIT: hmm looks like i got it recompiled myself for 4.24. Will test later. If looks okay, can upload binaries to Gdrive.

Just pushed 4.24 version to the master. There are some small changes. What would be cool is to get rid of all warning about PCHs.

[Thunder_Owl]

Hello. I did check on github, is it so that 4.24 version of plugin does not exist yet? Or am I looking wrong place maybe Thank You!
EDIT: hmm looks like i got it recompiled myself for 4.24. Will test later. If looks okay, can upload binaries to Gdrive.

[HEILVH]

BEST PLUGIN EVER !

It's exactly what i need for years ! Now I can use sub-stepping to make some car physics simulations in BP, really need a 4.24 version !

[wuzzy]

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.

From what I have read there have been a number of issues with optimizations and VS 2019, Nothing much we can do, but the developers are fixing them. From what I can see this one is now fixed (I am now on VS 2019 Preview 16.5.0 Preview 1.0) I have been able to remove the pragmas and the model seems stable in release mode now!

Many thanks for making the code available, keep up the good work!

[BoredEngineer]

With 4.23.1, MMT_Content still crashes on opening project. This project consist largely of BPs and was migrate through 15 versions of UE4. As its meant for education, you can study it in 4.22 and migrate individual content into feature version of UE4.
Maybe crashing will be solved with migrating to 4.24, will see.

[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_Plugin 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.