As a Roblox developer, it is currently too hard to use terrain for cliffs as optimization systems does not work how I would have expected them to work.This terrain wall you see here uses 20mbs of memory.
This only uses 2.3mbs of terrain you can test this by setting a brick to 2048,2048,1 for the size and converting it to terrain. Try to rotate it so it is straight up and down and then flat for some reason the optimization system does not work the same and makes a vertical wall uses a lot more memory than a flat surface. If roblox could fix this, this would greatly and I mean greatly help my map that currently sits at around 630 mbs of terrain and due to this issue, it takes people like a solid minute to load.
This is how it looks and we have made everything behind it paper thin so we can’t optimize it much. I have seen people make islands that are twice this big and only use about 20mbs or 30mbs of terrain and was confused with what was happening until I tested a flat wall vertical and then horizontal. If possible can we have a look at this and possibly a improvement on the terrain optimization system?
Here’s my best explanation for why this is happening:
IIRC, Roblox uses RLE (Run-length encoding) to compress terrain. Basically, it tries to compress a long line of terrain of the same material into a single value.
The problem is that this can really only become optimal for a single direction, and I would imagine that they chose the X or Z axis based on your file-size analysis. In the majority of cases, this probably works the best, since the orientation of terrain is more-so similar on the XZ plane than it is XY/ZY plane. I guess it’s possible that they try to do the same technique, but in a square or cube pattern, but again your file analysis says otherwise.
In order to figure out the best direction, the algorithm would need to attempt to compress in different directions and then compare which one is best. If I understand the algorithm correctly, that would mean trying to compress three different times (one for each XYZ axis). That also means that you would always hit the least-optimal approach too. I imagine this would be a performance bottleneck for saving data. I guess it could realistically perform this task in the background before saving and keep a record of the most optimal direction?
All of that is speculation based on what I know. I don’t know the exact techniques being used to compress terrain, but I am currently assuming it’s similar to what I’ve just stated.
There is no point in bumping this every few days if there is no new information to add – engineering doesn’t iterate that quickly and this does not seem like a simple issue to address. Engineering or Developer Relations read all threads in the Platform Feedback category eventually.
It wasn’t a bump though it was a question that I needed answered as usually, I get a response back from a staff saying. 1. We are looking into it. 2. Can you send us a template or give us more info. 3. We can not do anything about this. I don’t know who sees and who doesn’t see the post so I wanted to know that.
