So if you ever use belts, then you'll be happy to know that we've optimized those significantly.

Belts and pipes currently exist within unique instance groups in Updated, meaning that each length of belts between connection points was managed by themselves.

But in 1.0, they're going to be pooled together instead.

This is a big computational relief for your CPU as it won't have to work through as many instances of belts and pipes as it currently does.

So now instead belts and pipes belong to like fewer but bigger pools and now instead we're relying on the GPU to do the heavy lifting.

GPUs can work extremely fast, even when computations are chunky in size, which is why I foresettled for this fewer but bigger approach.

This helps stuff like shadow rendering a lot, since shadows will also belong to massive pools being calculated and drawn, rather than many individual objects or smaller groups.

It's also great for instances where many small belts occur frequently, which tends to happen a lot.

A prime example of this is Manifolds, where, you know, belts currently have to be computed per belt, no matter how small they are, which they tend to be in Manifolds.

After this change, again, they're pooled together and the DPO will just, like, show it all through.

One thing that a lot of people asked us about is whether we're going to use Nanite for combat belts.

And we did play around a bit with Nanite splines to try and, like, optimize the belts.

But in the end, we sort of ended up settling on our own instancing solution because we found that it worked better for our game.

Speaking of objects that may occur frequently everywhere, we've now introduced a system that converts several architectural buildables that players don't interact with, or don't produce anything, into data-only objects.