Video for the new update to highlight new features:
Just for clarification, new tank is based on Russian T-26 light tank from pre-WW2 years, but suspension is slightly different and re-assembles one from modifications of German Panzer I tank.
New tank/tracked vehicle model is based on assembly of various components rather than a single monolithic class. This simplifies refactoring and gives more freedom in configuration of the tank.
Track friction model is now based on CollisionHit events of various parts that build up the track. This means that any part of the track, including sprocket and idler can provide traction with the ground. Previously it was limited to road wheels which are pushed by suspension spring and suspension spring had to be made using custom component. Now you can assemble moving parts of suspension using physics constraints which allows to build pretty much any kind of suspension not limited to a linear springs.
Tracks now have a mechanical friction, which will slow down their rotation without torque coming from the engine and require some minimal amount of torque to start moving from full stop. You can see how “from still to rolling” transition is now more aggressive than a very slow smooth rotation of the tracks as it was before.
Know issues:
Version on repository has a bug in implementation of mechanical friction function, where delta time is not taken into account, which changes acceleration rate of the vehicle at different FPS
CollisionHit events usually happen on edges of surfaces which can push one wheel to the left and next wheel to the right, this creates inconsistent behavior of the friction when driving over the flat surface in straight line
Some of the collision shapes of track are a bit rough which can lead to unnatural collision of the “wheel” with the ground
There is a small jittering from the friction when vehicle is standing still
Suspension is not completely tuned and is too stiff but overall represents the concept of how multi-body suspension can work
[Temporary Controls for T-26]
To reverse, hold Shift key while holding W
W - move forward
A/D - apply brake to left/right track for steering
S - brake both tracks
To get over the vertical obstacle in front of the vehicle on the demo level, keep holding W until tank gets enough grip, it might take few seconds.
Are there plans to implement track-ground collisions? (like say for example, on a toy tank, with just 1 powered and 1 idler wheel connected by a track; the track should push against obstacles between the wheels. With the current system, unless you add many wheels close together, there would be noticeable overlaps; right? )
In principal you can do full physics track as a chain of treads with collision mesh, connected to each other using physics constraint. There is a working example of this in Tracked Vehicles thread. Main problem with such approach is performance and stability of joints. Stability can be fine for low velocity but at something over 20km/h things will go ugly.
I have some ideas based on modifying shape of the track spline by raytracing multiple points against the ground, but nothing concrete yet.
With current implementation you can always add some small invisible spheres with collision and drag track by them. I could actually try this.
I’m not finding it now; but a while back I saw a video about a technique for simulating ropes and cables where instead of having everything flexible, they had straight segments that were divided and joined based on the desired curvature and along contact surfaces, and lengthened and shortened when the rope was being pulled around an obstacle. Would an approach like that work for making the track simulation stable? (is it even clear at all with the way I’m describing it?)
I have to admit I have not read through everything, but is there a way with this method to have the wheels react less suddenly. Like at ~ 1:41 in the video you see how the wheels hop from one frame to the next into the new position. Like binary 0 to 1 switching with nothing in between. Maybe some interpolation of the position over a few frames, or tracing a few frames ahead on a projected path could solve this.
Yeah, that should work. You can measure a lenght of the current spline do decide if top segment should be tense or hanging for example. For the ground contact part you could even dynamically add spline points when spline segment intersects something.
There is slightly easier solution to all this - displaced landscape for visual appearance and coarse height field map for calculating track position and wheel displacement. Most of the time, tanks will be driving on soil instead of a flat plate and sharp geometry as here.
There are issues with landscape collisions so I need to introduce that extra layer of soil on top of landscape anyway. Otherwise we have to stick to raytraced wheels for a “smooth” ride.
I think this might be it:
I also found this video; but I remember they had one that went into more details and showed more examples, I haven’t found that yet.
I took a quick screenie. The ‘wheels’ (not the right name probably) marked in red. They move, or flip, just between two frames and therefore appear to have zero mass.
In general the lack of inertia of the wheels and the chains looks a tad unnatural. Interpolating to the new spline positions to not have them go instantly there might help with this.
They have little mass compared to the weight which pushes on them, this can be tuned. Visual wheels are attached to invisible mesh with collision, adjusting mass of collider, bogie which connects them and handle to which bogie is connected - changes quite a bit. It’s a matter of tuning I think. Will look into it
Btw, you are looking at 30fps video, so that have effect on smoothness too.
Great work and thanks for all your effort in developing the MMT! You are a rockstar!!
So I’m working on an SdKfz 251 that I got up and running thanks to OldRaven’s tutorials. You’ll notice that I attached the front wheels and they are rotating nicely and have working suspension.
I decided to use your method for adding yaw rotation to the Fokker rudder (Steer Rudder function) as a method for ‘turning’ the front wheels of the half-track:
However, when I add an Event Tick node to my A_TrackedVehicle blueprint’s event graph to pass delta seconds to the Steer Wheels function, the front tires ‘turn’ appropriately but all tread rotation ceases:
I guess your half-track is a child of A_TrackedVehicle blueprint. In this case, on EventTick event of the child you need to call EventTick of the parent first. Right click on EventTick and there should be option “Call Parent Function” or something like that. This will add new node to the graph, just call it before you call SteerWheel function.
Be aware that new tank is made out of about 100 components
I just didn’t used any skeletal meshes to be sure that everything is assembled exactly as it should and works together. Need to look into how it can be done in more manageable way. A bit of complexity comes from the fact that visual representation of the road wheels, sprocket and idler is different from their physics body and it can’t be the same static mesh. Collision meshes, which are invisible, connected to a bogie (in case of road wheels) and not allowed to rotate. Visible meshes of the road wheels, have to rotate, so they are placed as children of physics mesh in hierarchy and animated using AddLocalRotation. Suspension can be made in principal as a skeletal mesh but you will still have to attach physics mesh separately as we need to process individual collision hit events.
Btw, would it be possible to have it iterate thru all the objects in the BP, and automatically add objects to their respective parts of the BP code (inside an array I guess) based on a prefix in the name, instead of requiring things to be manually added? (like for example “Wheel Left-”, “Sprocket Right-” etc; or maybe even skip the “left” and “right” part, and use their Y coordinate to calculate how they should behave)
Ideally, you should be able to directly provide references of components to other components in the same BP. But this is technically not possible because some components can be created before others.
Automatically finding them could be done using tags for example, like to locate a gearbox component for example. But then assumption would be that you have just one gearbox, which is not the case for some tanks.
My point is that “automatic” referencing of components can be done only if you have more or less the same configuration for each tank. But in this case nothing stops from just duplicating a BP and setting different meshes.
Referencing of components can be improved in some cases by using hierarchy of components. For example friction component almost always uses root as component to which forces are applied and direct parent as a reference for velocity and coordinate system. I’m just not sure that adding such automation worth the price of loosing flexibility.
Can’t you have it not assume the number of anything, and just count the instances once it reaches the last item? Or am I understanding the issue wrong?
Maybe that was a poor choice of words. You said it could see one gearbox, and stop there even when there is actually more than one; so I asked if it would be possible to always check for more until all objects have been checked.
