[RFC] New Heightmap PQSMod

[NathanKell]

This is a request for all the smart knowledgeable coders out there to share their thoughts/ideas on this. Not a "do it for me" by any means (although if you want to contribute code, awesome!)

Basically, RSS needs better heightmaps. While a paging heightmap PQSMod would be the best solution, it's considerably more complex, so I'm looking into creating a 16bit-supporting one instead, and also (since I can load data directly rather than going via Texture2D) supporting resolutions >8192x4096.

So what I'm currently interested in is this. Are there any high-performance compression/decompression algorithms I should consider using? Since heightmaps will tend to have some level areas, even lossless compression should offer an advantage--presuming the performance hit is not too high. (Further, is there a lossy algorithm that would not lose too much and thus defeat the purpose, where heightmaps are concerned?)

Even if the maps need to remain uncompressed, going to 16bit gray will only double the memory requirements (and, if perhaps my code has less overhead than MapSO, it might end up better than that ratio).

Another question: how should filtering be done? I presume I will need to filter *some* when getting pixels--we don't want nearest neighbor for heightmaps! However, something more intelligent than bilinear would probably be nice, as we *also* don't want to just blend the thing--sharp edges should be better preserved.

Third question: am I forgetting anything obvious/dangerous that you ought to tell me about?

[rbray89]

Interesting... I myself am adding a PQSMod that adds Tangent information to the built/updated Quads. However, huge textures like that eat up memory REALLY fast, and seeing the bugs on EVE regarding 8K textures and Mac OS have led me to believe they may not be usable on certain systems.

Have you considered using a Per-RootQuad map? It would be marginally more complex, at most you would have 3 loaded at a time, and you could unload them once the Root is unloaded. You could even generate a massive regular height map in PS, and then use a Equirectangular 2 Cubic plugin or app to split it into the proper images.

[NathanKell]

Hmm, that's a very interesting suggestion! Makes a lot of sense.

[DaMichel]

Good luck with your efforts Nathan. Here are my 2 cents.

You probably want some sort of image pyramid for filtering or you will run into aliasing issues.

Also, i have to link to this page http://vterrain.org/. Perhaps you find some inspiration there.

Moreover you'll spot compression artifacts in terrain much more easily than in images. Therefore i'd say that compression won't be very effective.

Edited April 20, 2014 by DaMichel

[comham]

Presumably any improvement to terrain in RSS could also be used to improve the stock planets? I'll keep my eye on this.

[NathanKell]

DaMichel: yeah, I'll have to do a check to see if I can find a good, fast filtering algorithm. Haven't been to VTerrain since I was doing my thesis; it seemed a bit outdated then but maybe it's been updated.

comham: yeah, although there the heightmap resolution is already sufficient...

[comham]

DaMichel: yeah, I'll have to do a check to see if I can find a good, fast filtering algorithm. Haven't been to VTerrain since I was doing my thesis; it seemed a bit outdated then but maybe it's been updated.

comham: yeah, although there the heightmap resolution is already sufficient...

I consider 1m/px sufficient