Heightmaps Go to New Altitudes!

This update really is going to get some better terrain imports out there.
If there is anyone out there who is interested in heightmapping, I suggest checking out 144hertz heightmap importers guild, Heightmap Importers Guild - Roblox.


I would like to be able to preview a randomly generated cave system on the terrain that I could reroll to regenerate until I’m happy, where I could then permanently apply the cave system (i.e. it would keep the generated terrain in memory, and produce a carved version in the workspace each time I rerolled until I applied the caves). I would imagine it would just drill through the terrain indiscriminately, and maybe apply painting. Perhaps it would be useful to provide a masking brush that removes the influence of caves on certain voxels so you can preserve important terrain features.


Roblox always impresses me!
I am so happy for this change, and the moderation always left me waiting and sometimes it got moderated so I had to change my terrain. I am so happy with this change, thank you!


Some use cases:

  • Save terrain as a group asset and allow multiple developers to share, save and move parts of terrain between places (develop it in a production space and finalize it in another)
  • Easy “starter terrain” for new developers to get started with
  • Tutorials can share terrain that a developer may add into their own place without disrupting existing terrain or having to download a place file

Thanks! I have to say this seems like a request for a better cave system, not just one for heightmaps.


You’re right, this could be totally standalone from heightmaps. Maybe I’ll make a feature request in a few minutes.

Here is the thread:


Cool! I remember your team told me about these updates in a DM some time ago. I’ll most certainly be trying them out with my Gaea workflow!


i was having a little bit fun or should i say too much

yes this is the roblox Logo just pasted the image into the heightmap


Thanks. For your collaboration request, we have some other plans to improve collaboration in the works that I hope will address that need.

For starter terrain, I’d expect a new dev to use the terrain generator rather than importing terrain. Do you see a reason that’s inadequate?

And for tutorials, that’s a reasonable request. If a dev were to write an “export as heightmap” plugin for Studio, that would address that need because now even if you have Studio-generated terrain, you could provide a heightmap for someone to download/import as part of the tutorial. Importing it offset from your existing terrain should avoid disruption.


For the first part, do you mean that existing terrain chunk object that can be saved/created and loaded with scripts? I’d think that those can be shared as long as they’re saved to a place.

I do think that having the ability to save terrain chunks using the region tool and without having to use scripts would be nice.


This is a great update, finally we don’t have to wait for our heightmaps and colormaps to get moderated, we can even select it to generate all grass without a colormap!

Also, does generating hollow terrain use less server/pc storage or more? I’ve always wondered this.


I’m essentially suggesting a way that terrain regions can be exported to an asset to allow better collaboration and easily imported/updated across Places without the need for scripts.


I just opened it, it appears some of the labels get cut off:

‘Heightmap’ and ‘Size’ are missing their last letters.

I am on a Mac.


In general, with how our terrain is represented across our system, hollow terrain is more expensive.


I was wondering why the original importer was so poorly designed. Thank you for this.

1 Like

This is the UI issue noted in the original post that will be fixed in the next release. Thanks!


Love the new features, yet I’m wondering how could the new non hollow heightmaps affect performance?

These add on a massive amount of terrain which were the biggest reason some people used heightmaps instead of generated terrain.

Has this been an issue that’s been discussed? Was it implemented because it was optimized?

I’ve done 10k x 10k Heightmaps and I don’t think it’d be helpful to add even more terrain under the map (which is useless if you aren’t going to change your terrain) considering you’re starting to support even bigger maps

1 Like

In general, we’ve found that hollow terrain actually creates more performance overhead for our system than filled terrain, which was a major reason we moved to heightmaps generating filled terrain.

If you have a specific case where performance is an issue, could you let me know? I’ll pass it along internally for analysis.


@Phoninian Same answer. If you have a case where you see hollow terrain performing better, could you let us know?


Fair point. I’m imagining developers sharing these heightmaps, although I can see the terrain generator could be more useful in such a workflow.

A developer could write such a thing, but there’s a barrier to entry when there’s an external plugin to generate such images. If I recall correctly, the only way that a plugin would be able to do this would be to have some sort of desktop application that interfaces with Studio through HTTPService to save an image, or it could generate a script that generates the terrain from a dictionary (which wouldn’t be that useful unless there was an easy way to convert back to heightmaps for ease of use, which brings us back to this issue)

1 Like