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:
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.
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
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)
Does the heightmap wipe out any terrain in its bounding box? I want to use the heightmaps alongside my existing map but I’m worried I can’t place it into the map without the terrain under it erasing
Thanks. I have your feedback noted. Ultimately every feature request turns into a prioritization question, but we will take your notes into account as we work on some future projects.
Honestly this should be a toggle feature. I know most people prefer fully solid terrain generation for purposes of editing, but a lot of people including myself also value the hollow generation for optimization.
If you change the position property, you can generate it offset from your existing map. There is a 3D bounding box preview of the volume the terrain will be generated within in your viewport.
@FreezeShock Same answer–could you let us know if you have a specific case where hollow terrain gives better results?
I mean if I were to add the heightmap into an already existing map, to maybe add a mountain onto an already existing landscape using a heightmap, would the heightmap erase all the terrain that collides with the bounding box? Or would it create the mountain on the landscape and merge the terrain together?
It will merge them together. We first read the target area, apply our changes from the importer, then write it back to the terrain. Any air voxels made by the importer will not overwrite your existing terrain.
