So the next major hurdle was the tracks. When I made the first set of track pieces, I had little idea of where I was going with it, both stylistically, and technically. With the second track set, I nailed down what I wanted the first world’s tracks to look like, but it left much to be desired in terms of performance. Where I had gone wrong, primarily, was having separate materials for different parts of each piece: The concrete bits had a concrete material, the metal bits had a metal material, etc. While that makes total sense, it’s far more efficient for the engine if you shove all of that into a single material, and have different zones on the texture maps for each different sub-material. That way, it can batch all of that in a single draw call, instead of drawing each material separately. In fact, it cut my draw calls by 6 to 8-fold. Unfortunately, that meant the end result was effectively a brand new track set, even though it looked the same as the last, and therefore I had to re-create every single level I had made prior to then, hence the reason I hadn’t made many in the first place. I knew eventually I had to replace them.

But that’s not the only optimization I did. I also wrote a script that merges the meshes of each track upon level load. So, before the merge, it’s set up as a hierarchy. The rails are children of the bumpers, and the bumpers are children of the road piece. That means that every time I made a change to the transform of the road piece or its parent, (I.E., moved or rotated anything, which is the entire point of the game) that change had to propagate up to 6 more times, which, needless to say, created an unnecessary bottleneck.

So now it’s as efficient as I can think of how to make it presently, without sacrificing the quality of the physics.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s