Thank you! I’ll add this change into 4.15 version.
Performance issue might be coming from the multiple prototype actors in the main level. They are not optimized and some of them are throwing warnings into the log. I’m observing this since 4.13.
If you try latest version from github, it should work better as I’ve cleaned up main level.
This performance issue was with the github version, I couldn’t test MMT_Content_CPP as hitting play caused it to crash to desktop. Here is a short FPSCharStats I ran in the terminal while playing the level. I am going to try and attach other profilers onto the editor when running the level.
Yeah, it was the two light track experimental ones causing the issues, once I removed them I was able to play. I added one back in to see and no, those things are performance heavy.
Yeah, that is quite possible, one of them is a prototype heavy on calculations, it moves quite a few physics bodies (about a 100) on each sub-step in addition to rest of the workload. I’m working on porting code to c++, to get better performance and optimize various other parts.
I’m not using PhysXVehicles for any of these. I’m aware of PhysX’s N wheeled vehicle implementation but I feel that there is not enough control for the end user, in a way how one have to setup and tune everything.
The long term goal for MMT is to provide lego like building blocks, from which one could assemble various kinds of vehicles and change their parameters at any point of time. I don’t think I could make them as performant as PhysXVehicle template, but they will have more features and flexibility beyond specific implementation for a single type of car. For example, Modular Drive Train allows to swap drive components in real-time and connect multiple engines, gearboxes and differentials to a set of wheels/tracks or what ever else user can come-up with. This is obviously won’t provide the same level of performance as specialized implementation of a drive train, like if you want have just a 4WD car.
Finished Ray Check implementation for c++ Suspension Stack component.
To place this in a context:
There is a new c++ component called Suspension Stack. This component is responsible for finding position of the wheel and calculating and applying suspension force.
I’m planning to have three implementations of the way how wheel position is found: Ray Check - the simplest and fastest, uses LineTrace to check for surface under the vehicle. Works well on relatively smooth surfaces but can fail miserable on tranches or sharp obstacle. This implementation is finished and I finally can spawn about 20 tanks with acceptable loss of frame-rate (there are no LODs for physics of visuals employed, with them it should be much better). Sphere Check - slightly more expensive than Ray Check but slightly more accurate too. Sphere Check is used on A_Tracked_Vehicle implementation, M113 and Ripsaw are based on it. It’s not very accurate with large wheels as you can collide with objects sideways - way beyond the visual rendering of the wheel. I’m adding this technique mainly to be used with simulate track, where sphere check is done only against the surface of the track, so sphere protruding to the sides is irrelevant. Shape Sweep - the most accurate of them but the most expensive. With shape sweep you can basically use any kind of shape for your wheels, not limited to a cylindrical shape of the wheel. This allows to construct your suspension in such a way that vehicle will get maximum flexibility for going over obstacles, by making sure that sweep shapes overlap and conform to shape of the track. This way vehicle won’t get stuck on some sharp obstacle.
You can switch between this simulation modes in real-time, which can be used for LODs or just to enable more expensive technique only when it’s necessary - you don’t need Shape Sweeps when vehicle is driving across the field, Ray Check is enough, for driving over the rubble you can switch to Shape Sweep until vehicle leaves area with potential obstacle.
Sphere Check and Shape Sweep are not implemented yet.
Suspension Stack component is using new implementation of the spring. It’s much easier to tune it and imho more intuitive overall:
What you define is a maximum length of the spring, which depends on model of your vehicle. Minimal force of the spring, which can be calculated as:
Minimal Spring Stiffness = Total Vehicle Mass * 980 / Total Number Of Suspension Stacks
This is the amount of force that suspension will produce when spring is extended to maximum length - 1 cm. You can set this force smaller if you want your vehicle to sit lower and wheels to have a bit of a droop when they are not colliding with anything.
Another parameter is Maximum Spring Stiffness, which is set as ratio of Minimal Spring Stiffness. The higher the values the stronger spring will react when compressed. For a light tank, I found value of x2.25 to be quite good. It basically means that if all mass of the tank shifts to one side (during aggressive cornering or being on high slope) suspension still can produce enough force to prevent chassis from scraping ground.
By design, all parameters of suspension can be changed in real-time. As a simple demonstration, I’ve added “active” suspension to the light tank. Using “Insert/Home/Delete/End” (sorry laptop users) you can adjust total suspension force on fly:
[getting database error on attempt to attach image]
You can try latest compiled version by this link:
Tank with new suspension is “Press 6 to Posses”.
I’m not sure if latest version is already on github, will check in the evening.
Updated MMT Content to 4.15, MMT Plugin will be updated soon.
I’ve tried BP Nativization after update and was able to package whole project. It runs but unfortunately it looks like some variables get messed-up (speculation), as a result vehicles don’t behave as they should.
Added two simple examples of how Suspension Stack and Friction components can be used to imitate “car” suspension, you can find it in Simple Examples level. Variant with friction is not finished and vehicle can’t drive or spin wheels, yet.
Know issues: Old example with a wheel connected by two springs to platform behaves really weird, potentially got broken way before 4.15
If someone is in dire need of 4.15 version of plugin only, let me know and I’ll prioritize updating it.
New version of MMT Content and Plugin is on github:
added simple example of how SuspensionStack can be used to make a hover vehicle, can be found in Simple Examples level, calls name is SuspensionStackDemo
added example of 4 wheeled vehicle with simplistic drive train - engine provides constant torque as long as gas pedal is pressed
4 wheeled vehicle is based on existing components, it lacks proper tire simulation and almost impossible to control in RWD. Currently is all four wheels are powered (AWD) and friction is tuned for drifting
4 wheeled vehicle example is located in Simple Examples level, class is called SuspensionStackWithFriction
fixed issue with rolling friction where produced force didn’t made any sense. Now rolling friction acts as a “braking” force on the wheel/sprocket
It’s made out of existing meshes, so it looks like this
It lacks all very important parts that good car needs to have:
Tires - on simulation level, this vehicle rides on four metal wheels with a brushed contact surface. I didn’t realized that without proper tires, rear wheel drive (RWD) vehicle is almost impossible to steer as front “wheels” need to behave more like ice skates to steer movement of the car in desired direction
Anti-roll bars - current setup of friction is on purpose made slightly forgiving to sharp cornering, vehicle will drift instead of roll-over
Ackermann steering - currently, front wheels are rotated to the same angle which is not just sub-optimal for proper vehicle but means than outer wheel is always drifting more than inner wheel while cornering
Wishbone or similar suspension - right now, suspension stack and movement of the wheel is strictly parallel to vehicle chassis, instead it should be slightly slanted or proper wishbone suspension need to be implemented
Center of mass sits way above the line of suspension force application
Engine toque depended of wheels angular velocity - currently engine provides a constant torque, which means that only rolling friction and mechanical friction of the wheel are limiting factors of speed
Gear-box - currently wheels are most of the time are skidding as torque applied to the wheels is too large from the start
Variable steering sensitivity - as we have to use binary input controls (unless you use gamepad) steering sensitivity needs to depend on velocity of the vehicle
Most of the mentioned above, is not just missing “game mechanics” feature but absence of simulation of actual solutions to problems that had to be solved by engineers historically. For now, I’ll get back to finishing new Suspension Stack component. In feature I’ll try to dedicate some time for adding new features for proper car simulation.
Added 4 wheeled vehicle into the main level and tuned a bit - move center of mass by 25cm down and made friction coefficients stronger, while lowering toque of the engine.
As you can see at the end of the video, raytraces can pass through the landscape, need to investigate if this is because trace is done too low or absence of the successful trace is not processed correctly.
I might have found the reason why main level (Land Vehicles) had such a terrible performance in editor. Yesterday I was cleaning some code and commented-out statistics gathering tags in c++ code of friction component. After this I don’t see any significant fps drop when playing in editor. Would be grateful if someone could try latest version from github and confirm that performance got better!
Added Sphere Check mode for Suspension Component, both light tank and 4 wheeled vehicle are moving much smoother over the obstacles. Still not as smooth as with shape sweep but it’s considerably better than a ray check, albeit with it’s own downsides -a bit higher performance impact and wheels of large radius can collide with objects outside of visible geometry as sphere is not the best “approximation” of the cylinder.
On user reported that for him this change didn’t made much difference and what made difference is removing LightTankExperimentalTracks from the level. It is performance heavy but not that heavy, perhaps there is something wrong with it in another aspect. For now, I’ll remove it from the level. Could you try doing the same?
Basically I should get rid of current way of how you get into vehicles. Was planning to have something like a spawner platform, where you can select a vehicle to spawn and then posses it to drive around. Just to avoid having all this vehicles in the level. especially as only few of them have ability to go into “sleep” state when inactive.
Another clue as to why there is such performance difference and I don’t see it on my side - I never use it with Play In Editor Viewport. On my side, by default it starts in a New Window when I hit Play. As all default settings are removed from GitHub repo, for anyone who gets copy from repo by default it will start in editor main viewport, unless you change it. I’ll test this on my side, at least I hope I can reproduce this issue this way.
Welp, so I get about 27 fps in both cases and around 80 when LightTankExperimentalTracks is removed… I’ve measured fps in Simple Examples level, where the same tank is placed off side and I get 55fps with tank and 120 without it.
So I’ll remove it for now from the main level as it clearly has some serious issues with performance. It will be back after porting track tracing to c++.
Hi. First of all thanks for making this. and making it easy to use
i have played around with this for a bit now but i have some problems with friction. It Looks like its in the compiled version you uploaded as well.
The problem is that even if all my friction-points says static the tank still slides. And if i set the friction higher it slides less but will start stuttering when on flat ground. Not a lot, but it will never stop to move.
Am i making the wrong assumption that when the friction is using static it should more or less be glued to the ground?
I have some problems with friction. Its present in the latest compiled version that you have uploaded.
Even if the contact-point says it is using static friction they still slide.
Should not the static ones be static to the ground its on?
