Heightfield Generate Underwhelming Performance

Started by WAS, February 05, 2020, 02:14:57 pm

Previous topic - Next topic


If I'm not mistaken, this feature is still single threaded? Granted. I understand that, but somehow I feel like 4% CPU usage with occasional peak to 8-9% is slower than it should be. I've had an 8k 8640x8640 heightfield at 12000x12000km going for about an hour and it's at 16%.

I don't know. I almost felt like this process went faster on my A10 or even Xeon. I've always done either 6k or 8k exports to ter.

Ryzen 5 2600 (base clocks)


Secondary question; does this offer any real clear advantage to just doing a heightfield with luminosity? It's much faster but I also question the "translation" via this method.


Does the generate maybe slow down when working on heavily detailed areas? Or are the spikes related to this maybe?


February 05, 2020, 02:33:56 pm #2 Last Edit: February 05, 2020, 02:39:57 pm by Matt
It is currently single-threaded (at the time of writing, v4.4). The main thing affecting its speed is the complexity of the shaders that you feed into it.

If you know how to export heightfields using a plan view render and luminosity, I say go for it. Just keep the micropoly detail close to 1 (or above) so you don't lose any detail. The micropoly detail controls the polygonal model that is being captured, so you want it to be not much less than 1.

AA 2 should be good, just make sure that the Pixel Sampler shows minimum samples per pixel is at least 1. You might want to change it to non-adaptive (max samples).

If you crank the micropoly detail above 1 (and AA is 2 or more) you can get a better quality version than the Heightfield Generate, because that samples only once per pixel.
Just because milk is white doesn't mean that clouds are made of milk.