I am wanting to generate some cheap terrains for use in rendering distant terrain. This terrain will be swapped for a higher quality terrain when the player gets closer.
I know that it’s projected that in 2018.3 terrains will be getting faster, but for now they are quite heavy, and it’s not really needed when they’re so far. So I’m thinking a low quality mesh with a basic texture baked on it would be fine.
I know there are terrain to mesh converters out there, but none of them are open source, or even have their source available… which is an issue since my goal is to automate it.
Any thoughts? Is there a way to easily create a basic texture from a terrain?
Have you considered using 3D software, like 3Ds Max, Maya, Blender, to crate simple terrain? Their not that difficult to create, using high map for example and save as obj.
Regarding to texture from terrain, assuming in Unity, you can use Camera Renderer To Texture. Or something like that (forgot)
I’m making the terrain in Unity, so making them in blender wouldn’t work.
But your texture from terrain idea is certainly interesting. It would look terrible up close, but from far away… maybe it could work.
There must be a way to “snapshot” the basemap for the terrain. There has to… somehow.
I think you can export unity terrain as raw, or else it shouldn’t be difficult to write a script to export the heightmap data. Then I think motst DCC (blender at least) have displacement function that can take the raw 16bit data and apply it to a mesh. So the idea is to make a terrain mesh on a DCC, using the raw heightmap, then decimate the mesh using various tactics to the quality you need.
If you need terrain’s texture too, you would just need to export the texture and splatmap, apply them on the decimate terrain and then bake them, and reduce them to desired resolution.
There is: grab the heightmap data (as the next poster said) and then apply it a procedurally-created grid (or triangle) mesh. You can use the settings in the terrainData object of the Terrain to know how large it is and how much vertical displacement it has.
Keep in mind with this approach you will quickly reach the 64k vertex limit for a given mesh with a 513x513 heightmap, the default terrain size, so you might have to capture at less-than-full-resolution heightmap, or else tile a bunch of meshes (or strips) together.
take the snapshot using camera with renderTexture? position the camera on top of the terrain, looking down, set orthographic size to match the terrain size, you can exclude unwanted object when ‘capturing’ with layermask…
Weird I could literally find NOTHING about this on google. Well this certainly looks interesting.
I actually just realized how splatmaps are stored… literally just a texture. So I think I know of a really easy way of doing it, although we’ll see if it actually works out.
Woohoo, I got it working! This generates both a mesh and a texture, that is scalable! Next I plan on stitching these textures together (since they’re so low quality) and essentially make an atlas! The beauty of having a world split into chunks
All I need to do is make a big texture and put the pixels of each texture chunk into the big texture! Then I just need to translate and scale all of the uv’s in the exported terrains.
This will mean only one material and one texture for all of these terrains
Note the only reason this is realistic (and won’t end up with massive textures) is because I’m going to be using low resolution textures per chunk, like 64x64 or even 32x32.
Alas, a new problem. My new mesh terrains, which are used in the distance, don’t match up to the closer actual terrains cause of LODS. I have no idea how to fix this at the moment.
You mean there is a physical gap in the geometry?? If you are mixing and matching terrain and mesh that’s kinda gonna always dog you, especially when the terrain LOD drops down, as the two vertex streams are generated from different sources.
Usually you can fudge it through design with enough extra ground cover (houses, trees) near problematic seams, or by lowering and overlapping one piece or the other, but it’s a pretty tricky issue in the general case.
But also be sure to check the simplest case: all terrains are completely flat.
If THAT has seams then you have a basic problem in your positioning maths (or scales) and you can fix that to possibly help other problems with real data.
What I’m doing is having close terrains as terrains, and far terrains be swapped with these meshes, until the player gets close. (then those meshes will be swapped with terrains). Flat terrains are fine, of course. The issue is that the distant terrain of course does not match with the LODS of the terrain.
And as you said, I’m guessing there isn’t much of a solution here. I could try to make it so the meshes are the same resolution as a specific LOD distance for the terrain, but LODS are split into tiles, so that’s not going to work either.
So sadly it looks like this whole feature is unusable for me, rip
UNLESS
I modify the terrain during rumtime to match the mesh… is that possible?
As you asked, you would need to manipulate vertices.
Which is possible. But will require a bit of coding. I would suggest work on edges.
But I am not the expert in this field.
Just an idea.
I would thought that you best modify further-mesh front-edges, to fit and hide behind (neighbor) closer-mesh back-edges.
Easiest way, perhaps, is to flatterer desired edges. But such meshes need be modified, once player changes position and look at direction. For example fly over and looking now from opposite side and modified mesh.
More complex, would be to fit edge vertices, to actual actual edge of neighbor. Still potentially you may see imperfections, where vertices are reduced on one mesh, and you have curve on other mesh’s edge.
So some hiding tricks you may still need to apply, when mesh positioning is initiated.
It is certainly possible to modify the terrain on-the-fly to account for the LOD differences, and that’s probably the right way to handle the seams issue. You’ll want each side of the higher LOD pieces to have a number of verts that is evenly divisible by the number of verts in the lower LOD side; with that in place, you can force the outermost edge of higher LOD terrain to exactly match where the verts line up with verts on the corresponding lower LOD side, and then you can place the remaining higher-LOD verts on that side on the line that linearly interpolates between each of their neighboring verts. I believe that would do the trick.
This assumes you’re focused only on heightmap-based terrain, though – it gets considerably harder if you want procedural caves, overhangs, cliffs, etc, and you would want to use a more complex algorithm not of your own design there, most likely.
