Hope i don't confuse things, have spoent the afternoon constructing related textures but with different content ...
1 hour ago, _Silence_ said:
But if you are dealing about exact pixel size, then this sounds that texture rectangles might be the best choice.
Well, it is not that the distance between texels directly corresponds to world positions. A texel is just a height value, it's world position comes from other sources and is calculated. But i don't want to go deeper into the LOD algorithm, will do that in my blog one day soon(tm). A rectangle texture might only have advantages if it is faster than a full blown 2d texture, but i'd consider tackling and comparing this to be premature optimization at the current state of program.
Quote
So why these +1 or +2 pixels are in matter ?
A vertex (world position) has one corresponding height value (a pixel if you so want, i'd prefer heightmap texel here). I calculate surface normals (vertex normals) in the vertexshader by sampling around the current position and crossing the resulting vectors, or by using a weighted matrix on the surrounding positions. Since a position and a texel correspond, i can do so easily. But there is a problem at the borders because texture positions are missing there. The resulting error is visible. That's why i need a texture of 2^n +1 or +2 depending on the normal calculation method.
Quote
Are you doing pixel-precise treatments ?
Nope, the resulting world positions are mangled so that they fit an ellipsoid. I am currently doing that.
Quote
In the shaders are you using texture functions or gather functions ?
Simple texture lookups. Example (simplified):
vec3 computeNormalCentralDifference( vec3 pos ) {
float leftHeight = texture( heightMap, vec2( pos.x - 1.0, pos.z ) );
vec3 left = vec3( pos.x - 1.0, leftHeight, pos.z );
float rightHeight = texture( heightMap, vec2( pos.x + 1.0, pos.z );
vec3 right = vec3( pos.x + 1.0, rightHeight, pos.z );
float bottomHeight = texture( heightMap, vec2( pos.x, pos.z - 1.0 );
vec3 bottom = vec3( pos.x, bottomHeight, pos.z - 1.0 );
float topHeight = texture( heightMap, vec2( pos.x, pos.z + 1.0 );
vec3 top = vec3( pos.x, topHeight, pos.z + 1.0 );
return cross( right - left, top - bottom );
}
Quote
These extra pixels will be interpolated and mixed during magnification or minification. Is this a concern ?
Mipmapping is disabled for the heightmap textures. Otherwise i'd have to call textureLod()s with another degree of complexity ... i am a stupid guy and would get lost ? And i wasn't exactly honest, a number of vertices can actually share adjacent heightmap values (faking resolution), and then interpolation takes place. But that is an independent thing.
Quote
Thus the will to understand what exactly are those extra pixels. I currently suppose this is related to the fact that your use tiling.
I need extra pixels or texels at the border simply because for the shading i want to sample around the current position (like in the example) and the underlying lod algorithm needs a power of 2 heightmap. Thus i must add the mentioned overlap of 1, either at one side and top, or at both sides, depending on the sampling technique. That's all.
I will simply go the way. If "unintended consequences" show up, i'll post them.
Thanks for sharing thoughts !
