koobas.hobune.stream
Absolute Position of Terrain Data
I've run into a block. My terrain generator runs much faster than most, but it isn't compatible with Unity's terrain, because while my generator creates data positioned absolutely in 3D space, Unity's terrain objects can only handle values in an arbitrary space between zero and one. Here's what I mean...
The first layer of perlin noise, which I call "elevation" is the truly macro-scale octave. It has an amplitude of 2500 meters, 500 of which are below sea level (zero). Its wavelength is 10000 meters, to ensure it doesn't affect the overall map shape too much. Scaling these float values to fit in the space between 0.0f and 1.0f would lower precision too much.
Are there modifications I can make to the Terrain object, or is it possible to create a similar object, which will work with the Terrain Toolkit functions? (I'm okay with having to modify the Toolkit sources to connect with the new class)
I cannot change the generator because its effectiveness relies on generating absolute positions. If there's a way to translate the output to something that will work with Unity's Terrain structures without sacrificing precision, please advise.
I've tested it. Heightmap Resolution does not mean precision of data. It means the number of samples per row and column. This, along with size determines how far apart samples are, and effectively how large the polygons of the terrain are. It's my impression that there is no way to improve precision, although I now know how to increase the height of the terrain object. Instead, since I will never have 2500 meters of elevation difference in the same terrain object, each piece of terrain generated by my generator I will put in a terrain object that is positioned and sized to contain all of the data in that square. The data will also have to be converted so that it will fit, but other than that, I see no drawbacks to this method.
The "Heightmap resolution" under the Terrain top-bar menu is the number of terrain positions. I've never gone this high, but you should be able to set it to, say, 65536 to store each height using 16-bits.
Sure, they'll still be 0-1(? didn't know that -- never looked at the raw data) but you can scale and lose less precision.
Oh, yes. Confir$$anonymous$$g my answer is completely wrong. H$$anonymous$$-res is the number of sideways verts.
I didn't know it was wrong until after I confirmed your answer (that was when I went and tested it).
