Feature plans and rambling on design
For the next iteration of MMT I’ve prepared this model, inspired by Sd.Kfz.250 half-truck:
It will need a proper model for tires simulation and some adjustments to general architecture. Have to make both wheels and tracks work at the same time while using very different simulation algorithms.
Which brings me to… Over last few days, I was looking into how MMT usability can be simplified and how to make everything more automated while still customizable to every single bit that matters (in my opinion).
The naive idea is to make a single “Vehicle Component” where you can setup array of tracks/wheels/ski for a single vehicle. This means that each type of suspension (wheel, track and etc.) should be somehow customizable. I’ve tried Data Assets, Custom Classes and just combinations of structs for this. Each had it’s own downside and none show to be flexible enough to support tracks - wheels and ski are much simpler as they are normally limited to a single set of objects, such as spring/collision/mesh/friction. With tracks, situation is bit more complex as on one side it has to be treated as a single entity but on other it’s made out of bunch of mechanical parts.
I have two different approaches now in mind. In both approaches there will be some sort of Vehicle Director component who’s role is to glue various MMT components inside of the single vehicle, so to minimize amount of BP glue code, that have to be done now.
Then in one approach, I can create a single component which will contain all parts necessary for a single track. All suspension blocks (one per road wheels) all friction components, track animation, drive processor and etc. everything will go into a single component. This will be good for performance - as UE4 doesn’t like actors with a lot of components. The downside is that it will be much harder to tweak such track design from UI point of view, unless someone makes a full fledged “track editor”. My gripe in this design is mostly about setting up suspension. Single stack of it, doesn’t split nicely into some Data Asset + some vehicle specific settings, so far, just having array of structs made the most sense. Unfortunately you can’t multi-edit elements of array as you can multi-edit components.
The second approach is to keep everything as separate components but make them “smarter”. For example, friction component won’t be derived from scene component anymore, but from actor component - to avoid transform updates. Settings of friction component will be feed from Data Asset and it will intelligently bind itself to a parent, so it can receive proper data about “collisions” and do his own calculations. Suspensions stacks (spring and dampener), will be kept as scene components, so you can move them around freely and multi-edit their properties when necessary. The downside of this approach is that it will be much harder to add a complete track in real-time or copy track from one tank onto another.
If anyone has thoughts on this, I would like to hear. So far quite some time was spend on writing code that I had to throw away eventually. Somehow this “infrastructure” code is harder to design than a new simulation model.