I see…
Is that in the T26 the part in the event graph where you use the oncomponenthit on both the idler and sprocket?
Then I just add the same for all the other roadwheels right?
and the Break and Make static lock event I still need to do
Hi there, I know this is off topic, but I was wondering what is the exact formula you use to calculate MuFriction in your MMT project.
Final coefficient of friction is calculated from friction ellipse. Ellipse itself is defined by two parameters Mu X and Mu Y as two radii of the ellipse. In runtime, we take direction that wheels are moving at and fetch friction coefficient from ellipse (using ellipse equation):
https://github.com//MMT_Plugin/blob/master/Source/MMT/Private/MMTBPFunctionLibrary.cpp#L226
Hey man! I’ve been trying to set up my own lightweight(read: inferior) version of a tracked vehicle and your comments and code has been very insightful.
However, one thing I can’t properly get a grip on is how to calculate load on the engine and how it affects RPM, and how torque comes into play in all this.
Could you give me a bit of guidance on how you do it or where in your code I can find info on this?
Hii How can I implement Braking for the Tank?
Sorry for late reply, forum doesn’t notify subscribers if it’s your first post on forums.
The closest example you can check for this is “modular driver train”, which can be hard to follow as it’s goal is modularity rather than readability.
Torque is a rotational force, so basically engine produces some torque that is transferred to sprocket through a driver train (clutch, gear box, differential, final drive and etc.), as torque passes by various parts of drive train it changes but eventually it gets to sprocket. Sprocket pulls the track and friction force between track and ground produces “traction” force which on one side pushes vehicle forward but at the same time pushes the track into opposite direction. This “opposite” force is what is called “Normalized Reaction Force” on friction components in MMT. This reaction force pulls on sprocket (through tracks), which produces “negative” torque that is transferred back to the engine through a drive train, which slows down the engine.
In real life, all these processes happen simultaneously, but in code we can integrate all involved forces from the engine to the ground contact and then back.
Basically there are 3 things which need to be taken into account in drive train: angular velocity (w), torque (T), moment of inertia (I). They are connected and different drive train parts effect them differently. Their connection goes through these formulas:
a = T / I
w = w0 + a * dt
“a” is angular acceleration, “dt” is delta time and “w0” is angular velocity on previous integration step (frame)
What it means is that the higher is moment of inertia (rotational equivalent of mass) the more torque you need to rotate an object. Own moment of inertia is a constant for all parts of the drive train, as it depends only on shape and mass distribution of the object. So in theory, for a very simple drive train (engine -> axle -> sprocket) we could just sum up moments of inertia and that would be a final moment of inertia that engine has to deal with. In practice, such drive train might not work at all without some external help, as engine needs to be rotating already to produce torque. Let’s add a starter engine then, so you have something that can get drive train into motion to a point where your main combustion engine can start producing torque. Electrical starters are great because they can produce full amount of torque with a zero RPM (unlike most of combustion engines). The heavier the drive train the more time it will take for the starter to get it rotating at some desired RPM. On top of that, if sprocket has track attached to it (or instead of sprocket we have a wheel) and said track is in contact with the ground then starter needs to produce enough torque and long enough to get the whole system into movement. Either way we need some way to accelerate just the main engine without touching the rest of the drive train, and this is why we can add a clutch, which basically splits drive train into independent parts when clutch is not locked.
[At this point I might be talking about things which you didn’t asked] The whole deal with drive train requires quite lengthy explanation as there is a minimal set of devices you need to simulate (or imitate) to make a working vehicles - engine, clutch, gear box (optional), differential or final drive. Each of these parts change torque, angular velocity and “visible” moment of inertia in their own way. So the actual load on the engine, depends on individual state of each drive train part as it matters if clutch is locked and engine now needs to spin all parts together or just its own axle and pistons when clutch is open. The gears (in gear box or differential) change effective moment of inertia quadratically: Calculating effective inertia
Some discussion on this we had on gamedev.net: https://www.gamedev.net/forums/topic…nt-of-inertia/
The simplest example of drive train I know of is in this classical article:
http://www.asawicki.info/Mirror/Car%…r%20Games.html
Try implementing it and see if you get it. It might be better to go over specific question if you have those. I sadly don’t have any links to some good overview articles or videos as I’ve read/watched a bunch of them just from search results. This guy has really good videos on engineering of real cars and you can find explanations for gear boxes, differentials and other parts:
For which tank? All example tanks have braking but in different examples its done differently.
Hey! Incredible work this,and I find myself drawn to this project rather than trying to wrap my head around writing my own PhysX MovementComponents because of the utter lack of information on how to go about doing that, specifically for tracked vehicles. Seems several teams have done it, but maybe I am just too daft to figure out how to. Regardless, with some testing MMT seems to hold up well enough in network environments, but how do you think it would hold up with tens of vehicles being simulated (thinking racing game or such, just for fun)? Would that be overkill?
I haven’t done anything in MMT in regards to multiplayer support. In simplest case, where each client simulates their own vehicle, performance should be fine. If you want to do it on the server, regardless of replication details, then couple of things could be improved. Like packing multiple components into a single component and looking at ways to multi thread calculations. Currently the bottleneck on tanks for example, is in amount of components being used. Last time I’ve run performance test, whole physics update multiple time per frame, took roughly the same amount of time that UE4 spends updating transforms of components - which is a lot imho.
In feature versions I want to re-engineer how components are setup. Was working on that already but stopped due to multiple reasons. Like suspension is already split into two classes, a UObject with all Code an component class that wraps it, so one can make a component with array of suspension stacks instead of having one component per each suspension. Need to do the same for friction component.
Makes sense yes. I guess that, in theory, it’d be possible to leave the clients to their own devices and just have the server check if they are in an invalid location or moving too fast perhaps? I got bored as well, so I started building a version of A_TrackedVehicle in C++ to both learn how you do things and to see what I could do with it since I seem to think better in raw code when the blocks get huge and full of math.
Out of curiosity, since you’re evident quite bright when it comes to these things, have you muddled at all with the PhysX implementation? Frankly I prefer the way you do things due to simplicity and UE’s vehicle physics are “interesting”.
Sorry for late reply .I am using the M113 blueprint tank.So I was going through one of the post where you mentioned that you can’t get too many tanks in scene because of performance drop.I also looked for some optimization techniques mentioned in that post which were great. But In my case I am planning for 50+ tanks in single scene. If I cant get realistic tank movement because of performance issue I would be happy to explore other options like hover tanks(which I think is great).Will they will be more efficient in terms of performance for example hovercraft movement calculation wold be faster than tank movement?
This is one of my old time favorite game where the robot and tank hovers.Mind the volume 
A_TrackedVehicle is an old implementation which is inferior in most ways to T-26 example. I’ve brought it into MMT from an older project. The only benefit it have is that everything packed into a single BP but it lucks modularity of the new version together with some bugfixes and features like more adequate suspension.
I haven’t used PhysX implementation but recommend looking into it if your goal is performance. It has some quirks but as source code is available you can mod it to your needs. Performance wise it’s really great, I’ve heard people having like 20 tanks roaming around without significant performance impact.
It will be as efficient as you design them, there are many ways how hovecraft can be made. Overall, yes it will be more perfomant as you need less components and many things can be faked with a simpler math. One of the tricks with older games is to have a “flat” level, then you don’t even need any suspension or hovering as vehicle can just sit at some height from the ground.
I gathered, yes, but I felt it was easier to get a good look at everything in one place, so to say, and pretty quickly converted before looking at the other stuff in detail. I have it working as a C++ implementation now with some changes on my own and so far so good x). But it’s just for the curiosity value right now of course.
Thanks for the recommendation RE PhysX. I’ve found a plethora of vehicle resources, but nothing at all for tanks in regards to their implementation. I’ve looked at the tank snippet from their own (PhysX) SDK but it didn’t get me very far. Because of this I can’t help but wonder if you are referring to any specific source code being available? Am not asking you to do all the work for me, it may simply be that all the queries I’ve put into google and elsewhere have not provided the right results :x. I guess my real issue is figuring out how to marry the PhysX example and UE’s vehicle system in a logical manner. I had a play with the UE plugin that lion03 (on GitHub) made, but it doesn’t utilize the PhysX implementation at all, rather making a 4W vehicle with some very slight changes and the result isn’t really that great, comparatively.
Yes, I was referring to the code snippet that PhysX provides. There where couple of people who wanted to wrap PhysX tanks into plugin but no idea if they succeed. From what I understood, PhysX tank is more or less a regular vehicle with a limit on wheels speed which is set to be equal for all of them (at least in animation). Don’t know what are the changes on simulation side.
Yes, with some poking around and fiddling and so on I have that working quite well actually and I have gotten quite far with it. It is surprisingly easy once you wrap your head around it.
Though one thing I can’t seem to figure out, is how to get the tracks bound to the wheels in a useful manner. I’ve made a mesh track solution since I don’t want to use instanced tracks for performance reasons, not quite sure how to move the instanced meshes around the spline anyway. But no matter. I looked at your own mesh track that is in the MMT_Content project and see how it is built and set up with the physics asset and skeletons, but I would like to ask you how it’s then used. My own experiments were horrible since I can’t get the track to follow the movement of the wheels :P. I am not expecting a tutorial or anything x)
Skeleton covers only animation of boggies, boggies are animated by taking into account position of pairs of wheels. What I do for tracks is use a spline, with control points set under the wheels, when wheel moves up/down the control point follows the wheel and spline deforms. Track links, which are instances of ISM, just follow spline during their animation - I re-calculate position of the links on each frame.
With mesh track you can follow the same logic, place bones under the wheels and move them together with wheels. I had example of this in old project “Tracked Vehicles”, not sure if it’s still there.
I already built a solution for spline tracks similar to what you wrote here and it’s all well and good. I just feel that the other is a puzzle I want to solve, especially since this is so unlike anything I’ve done before when it comes to rigging. I already had a look in your old project as well, and the mesh track is there but not used. What gets to me is how to move the bones in the track with the wheels if they are not in the same mesh, i.e. how to link them since setting up the hierarchy in the 3D app doesn’t produce the right results. Cheers for taking your time, by the way, this is quite interesting to learn.
Ahh, that is done by passing values to Animation BP. Basically you declare some variable in AnimBP, then in regular BP you grab skeletal mesh, get reference to AnimBP that is used on it and pass variables of wheels position or whatever else you need there. The light tank example does this to animate boggies.
The rigging is not too complicated, basically you just blend from one bone into another. To accommodate shape of the wheel, blend can be non-linear, normally you have some automatic weight assignment in/Maya that works ok. Doing it manually can yield better results.
Just for clarification, the bones will move up/down only, to make illusion of track movement you need to animate material.
I guess, one could move bones around the spline too, not too sure how well that would work. It might work just fine. Haven’t tried it.