Interesting, 28-bit. That would seem like the other 4 bits are doing something because if your using a float or a double aren't those by nature 32-bit or 64-bit in a 64-bit system? (Just pondering on the matter with my limited C++ experience)
floats are 32bit, doubles 64bit regardless of the system (32vs. 64bit).
As for the 28 bit limit, that is apparently inherent to the SDK we use. Also, JPEG 2000 can use a variable number of bits and isn't limited to 8, 16 or 32 (per component).
So here's the question. I'll try to verify it with some tests, but might as well ask too
. If I understand correctly even with the current infinimap there is some advantage to using displacement maps through infinimap because it disregards information outside of the camera's view. For example if you are zoomed in on just a section of terrain that is part of a much larger terrain.
Actually it doesn't ... because that information may still show up in a reflection for example.
Which also means... if LW queries an infiniMap image for displacements it will always get a decent value, whether within the camera view or not.
It would be up to the displacement to decide if it actually needs a value or not.
In the case of terrain, the mesh subdivision, displacement and height map evaluation have to work hand in hand - that would be possible in LW but would also require a custom plugin.
If such is the case the limitation in my eyes is that 8-bits does not create a very smooth displacement, especially in the arena of DEM files which band considerably when reduced to 8-bit. The adjusting resolution of the images for displacement isn't as critical if it can at least not load the parts of the displacement image that are not visible to the camera.
DEMs are usually 16bit integers, which is enough to store roughly 32k different values half that if you allow for negative numbers). In general DEMs use integers, no floats.
I've got some ideas on rendering terrain within LW - especially since infiniMap doesn't handle that case adequatly at all (as I said, subdivision/displacement/elevation evaluation need to work together tightly for it to work as expected).
What you can do to fake it is parent a manually subdivided mesh to the camera (more subdivisions closer to the camera, less further away) and push it through a world coordinate projected infiniMap elevation image used to displace it. (does that makes sense?)
Cheers,
Mike
