[OPEN-SOURCE] Machinery Modelling Toolkit

[BoredEngineer]

Another alternative is to merge only Plugin. This will simplify process but you would have to wait for necessary components to be ported to c++.
Overall the closer you are to the latest version the less issue you are going to have with updates, except if you are using experimental components such as modular drive train.

[BlueBudgie]

The only problem with this approach as far as I see is default values of variables in BP components - if default value is changed in the source of component, it switches custom value to default in each instance of component.

Not sure if it is applicable here, but we initialize all variables in blueprints as we do in Code. Just one large macro or function in your BP that fires once when you press the play button and all variables are set in it. Then, after it has run, the rest of the blueprint is executed.
Pretty much what you do with every code based program as well. Then you do not need to rely on the default values actually working properly in BP.

[BoredEngineer]

Not sure if it is applicable here, but we initialize all variables in blueprints as we do in Code. Just one large macro or function in your BP that fires once when you press the play button and all variables are set in it. Then, after it has run, the rest of the blueprint is executed.
Pretty much what you do with every code based program as well. Then you do not need to rely on the default values actually working properly in BP.

That would work. I can test another option too - making a child of necessary component and setting defaults there.

[OldRaven]

One thing I forgot to ask a while ago.

Do you plan on adding torsion bar suspension?
Basicly the M113 now uses a simple spring.. but like a lot on tracked vehicles .. it has a torsion bar suspension.

Or is there already a way to do a torsion bar suspension that I am not aware of
(I see most vehicles on my list all have torsion bar suspension)

[BoredEngineer]

One thing I forgot to ask a while ago.

Do you plan on adding torsion bar suspension?
Basicly the M113 now uses a simple spring.. but like a lot on tracked vehicles .. it has a torsion bar suspension.

Or is there already a way to do a torsion bar suspension that I am not aware of
(I see most vehicles on my list all have torsion bar suspension)

The easiest way to do is using angular motor on physics constraint. It's not the most elegant solution as torsion bars don't have a linear response as angular motor will have but its good enough for prototype. Later you could add torsion bar component and just remov angular drive.

[OldRaven]

The easiest way to do is using angular motor on physics constraint. It's not the most elegant solution as torsion bars don't have a linear response as angular motor will have but its good enough for prototype. Later you could add torsion bar component and just remov angular drive.

Sounds good.. but that's way over my head.
I will for now stick with the simple suspension.

yesterday was playing with your Modular Drive train.. Brings back memories ! Great Job! This is exactly what it was like driving the Tiger in T34 vs Tiger .. and this is definitely something I would like to add when you are in the driver seat.
When switching to the commander seat I want it to just be more of a commanding the vehicle mode where it switches to automatic mode and the wasd keys turn into a move forward command etc.. just like in Steel beasts.
As the commander you want to focus on the surroundings.. and when you tell the driver to go forward.. you just want him to continue going forward without having to keep reminding him to go forward.

basically that is the most annoying thing in ArmA right now.. when you tell the ai driver to go forward.. the driver will also decide to evade obstacles and start steering left and right.. you're in a freaking tank! Stop Steering! When I tell you to go forward.. GO FORWARD!

[BoredEngineer]

Sounds good.. but that's way over my head.
I will for now stick with the simple suspension.

yesterday was playing with your Modular Drive train.. Brings back memories ! Great Job! This is exactly what it was like driving the Tiger in T34 vs Tiger .. and this is definitely something I would like to add when you are in the driver seat.
When switching to the commander seat I want it to just be more of a commanding the vehicle mode where it switches to automatic mode and the wasd keys turn into a move forward command etc.. just like in Steel beasts.
As the commander you want to focus on the surroundings.. and when you tell the driver to go forward.. you just want him to continue going forward without having to keep reminding him to go forward.

basically that is the most annoying thing in ArmA right now.. when you tell the ai driver to go forward.. the driver will also decide to evade obstacles and start steering left and right.. you're in a freaking tank! Stop Steering! When I tell you to go forward.. GO FORWARD!

It's actually pretty simple, T-26 uses angular motors on levers of suspension (arched parts to which bogies with wheels are connected).

Regarding drive train, I've uploaded new version with a locked differential last week. Added sound for shifting gear too. Still need to clean up code and add open differential and add rolling friction for tracks.
Commander mode can be added on top of such system. Need to decide on some sort of component and interface which will handle input from keyboard/mouse/gamepad and an automatic mode on top of it. Right now input code is handled in pawn, which is not good for modularity.

[BlueBudgie]

The easiest way to do is using angular motor on physics constraint. It's not the most elegant solution as torsion bars don't have a linear response as angular motor will have but its good enough for prototype.

The linear response of joint motors can be exchanged for other responses by changing the strength of the linear/angular motor during runtime. Like for linear motors, to turn them into proper springs/shocks, you would feed the spring equation into the position strength pin of the 'set parameters' node. The spring equation is simply F=k*x, with x being the amount of stretch or compression (if I remember correctly). The distance from a reference point (e.g. wheel to chassis) gives you stretch/compression. That's how we did it, or at least it was something like this as I remember, for the shocks of the carrier in our little nonsense game. Still not a 100% vehicle simulation, but a good start.

[BoredEngineer]

The linear response of joint motors can be exchanged for other responses by changing the strength of the linear/angular motor during runtime. Like for linear motors, to turn them into proper springs/shocks, you would feed the spring equation into the position strength pin of the 'set parameters' node. The spring equation is simply F=k*x, with x being the amount of stretch or compression (if I remember correctly). The distance from a reference point (e.g. wheel to chassis) gives you stretch/compression. That's how we did it, or at least it was something like this as I remember, for the shocks of the carrier in our little nonsense game. Still not a 100% vehicle simulation, but a good start.

Yes, you can dynamically alter stiffness to get the desired effect.

There are couple of thing that I'm not too happy about in regards to angular and linear drives of physics constraints as a basis for suspension spring (they are totally cool for attaching things together!).
1) Symmetry of damping - most of the real life dampeners have asymmetric response to suspension compressing or extending, this is very important for proper behavior of the cars, not too important for modern tanks. Asymmetric damping allows wheels to react very fast to obstacles protruding from road surface - this compresses suspension, at the same time reaction to ditches in the road is much slower (suspension expanding) and wheel can "fly over" the hole in the ground. Aesthetically this works rather well for tanks too.

2) Physically accurate application of force - yeap, not happy about this Let me explain what I mean. Aerosled is a very good example where accuracy can lead to undesirable behavior. Chassis of the machine is 1100 kg, each of four ski is 50 kg. At rest, four suspension springs will push on chassis to keep it up, but the same force is pushing on ski too. Unfortunate part with solid body physics is that as there is no loss of energy by means of heat or deformation. This leads to a relatively light body being pressed by relatively large force against the ground. In case of aerosled it leads to one of the skii piercing the ground on one frame and being pushed out on the next frame, the end result is annoying shaking of the vehicle. What I do to solve it is rather simple - a spring which can push on chassis and ski with a different force. If I want to place Aerosled on the back of another vehicle and have it's suspension properly react to weight of the aerosled, I can pass as much force to vehicle as I want. And again, it doesn't have to be physically correct especially if it creates more pleasing and stable result.

3) On this point I might be wrong, but I have impression that springs and dampeners of physics constraint operate on a relative scale. I want to iterate over the code of my custom springs to make sure that they have a consistent scaling. What I mean by that is stiffness of the spring should depend only on engineering properties of it - material, manufacturing, design but not on it's length. This is very helpful in long term when you have to deal with many vehicles and allows to find proper values by simple calculations instead of tweaking it 30 times until you get good results. Another benefit from proper scaling is that you don't have to iterate over the stiffness of the spring every time you adjust it's length.

This is not a rant or a critique to how physics constraints work. They are made to be used for variety of different use cases and more accurate simulation just needs a bit of custom touch to it.

[BlueBudgie]

Good points!

1) Asymmetry of constraint stiffness/strength can be included by considering the direction of movement of the constrained component relative to its relaxed constrained reference point, i.e. compression and stretching have different signs and this sign input can be used to branch two different equations for asymmetric strength/stiffness into the 'set parameters' node.

2) Yes, I absolutely agree on the problem of mass differences in the current implementation of the PhysX Code base. Are you saying you tweaked the PhysX constraints in a way that they apply different forces in each direction? Or do you mean a double spring composed of two out-of-the-box PhysX constraints.

3) Well, there seems to be something like this going on. The actual spring force also scales with the attached masses. For example our nonsense robot: Body is always the same weight, but you can choose different leg/arm/feet/hand parts with different weight each. Now here it comes: Lighter legs are wobblier, while heavy legs are stronger because the constraints (hip/knee/ankle) react different when different masses are constrained together. We never cared too much about it because it actually makes a nice gameplay feature, but it shows clearly that something is on relative scales under the hood. If constrains were on an absolute scale, i.e. for example same strength for all mass combinations that are constrained, that would make it easier to control.

[BoredEngineer]

Good points!

1) Asymmetry of constraint stiffness/strength can be included by considering the direction of movement of the constrained component relative to its relaxed constrained reference point, i.e. compression and stretching have different signs and this sign input can be used to branch two different equations for asymmetric strength/stiffness into the 'set parameters' node.

2) Yes, I absolutely agree on the problem of mass differences in the current implementation of the PhysX Code base. Are you saying you tweaked the PhysX constraints in a way that they apply different forces in each direction? Or do you mean a double spring composed of two out-of-the-box PhysX constraints.

3) Well, there seems to be something like this going on. The actual spring force also scales with the attached masses. For example our nonsense robot: Body is always the same weight, but you can choose different leg/arm/feet/hand parts with different weight each. Now here it comes: Lighter legs are wobblier, while heavy legs are stronger because the constraints (hip/knee/ankle) react different when different masses are constrained together. We never cared too much about it because it actually makes a nice gameplay feature, but it shows clearly that something is on relative scales under the hood. If constrains were on an absolute scale, i.e. for example same strength for all mass combinations that are constrained, that would make it easier to control.

All three points are just easier to implement using custom component. The solution is rather simple, use physics constraint to establish limits of the movement - for example spring can compress not more than 15cm and expand not more than 30cm, which is just a limit of 15cm on linear constraint with some offset of pivot if necessary. Then spring and dampener forces are added using custom component where scaling can be done properly and you can handle how and where forces should be applied, what their scale should be and etc. First two points are implemented for suspension on Aerosled RF-8 example already. Proper scaling is still missing and handling of other objects being properly pushed by skii.

[BlueBudgie]

All three points are just easier to implement using custom component. The solution is rather simple, use physics constraint to establish limits of the movement - for example spring can compress not more than 15cm and expand not more than 30cm, which is just a limit of 15cm on linear constraint with some offset of pivot if necessary. Then spring and dampener forces are added using custom component where scaling can be done properly and you can handle how and where forces should be applied, what their scale should be and etc. First two points are implemented for suspension on Aerosled RF-8 example already. Proper scaling is still missing and handling of other objects being properly pushed by skii.

That's true, it is easier if you customize. The only concern, and that's definitely only of 'philosophical' nature leading to discussions with no end in sight, is the reliability side of custom solution. Opening the 'source code can' is something we for example always shied away from, because while on simple tests scenes such custom made implementation might be working, there is no guarantee really that it will still work alright in a full game were cpu load is heavy and certain timer budgets might get violated and so on and so on. Basically there is the ever lurking danger that if you customized, then at some other end later on it might backfire and you might not notice it for months before it hits. Essentially, looking how even Epic breaks features on a somewhat regular basis with their own updates (like two side foliage in 4.11), which is kind of normal looking at the complexity of the code base, it might be a good idea to have the Epic phyiscs programmer have a quick look and give his Urbi et Orbi at the custom made solution before entering a larger project with that solution. But yeah, that's just endless paranoia of which you can not have enough really

[OldRaven]

I tried to migrate the entire MMT project to another project.. but that does not work.

Can I migrate it to another project?
I just opened it and did a migrate > the root folder to the content folder of another project.

But when I now open a blueprint in the other project I get an error message .

"Blueprint could not be loaded because it derives from invalid class.
Check to make sure the parent class for this blueprint hasn't been removed! "

EDIT : Wait never mind! I forgot to also copy the plugin folder .. works now

[OldRaven]

Wait,

I do have something weird..

the physics seem to go all over the place..

When I for example place the T26 in the map and play.. it starts flying all over the place.

[BoredEngineer]

Wait,

I do have something weird..

the physics seem to go all over the place..

When I for example place the T26 in the map and play.. it starts flying all over the place.

Most likely collision bodies are intersecting. I have a couple of custom collision channels for chassis/suspension/wheels. Check them in MMT_Content under ProjectSettings->Physics. Add the same into your own project and migrate it again.
Another thing to check is if Physics Sub-stepping is switched on in Project settings.