Interior Mapping (Humus demo)

Hi there

I just tried Interior Mapping, using the code that Humus used in his latest demo.

The problem is, i cannot run his demo (no D3D10.1 card), so i don’t know how his results are supposed to be, but the results, that i get, are not perfect.

Here is a screenshot, of the result, when i use his code without changes:

Screenshot 1

As you will notice, the edges of the rooms do not have the same vanishing point. From grazing angles this looks extremely bad.

Here is the code, that i use currently for testing:

vec3 vTangent0 = vec3 ( vInteriorTangent.x, 0, vInteriorTangent.z);
vec3 vTangent1 = vec3 (-vInteriorTangent.z, 0, vInteriorTangent.x);

vDir.x = dot (vTangent0, vEye);
vDir.y = vEye.y;  // * 0.5; // HACK   
vDir.z = dot (vTangent1, vEye);

// Entrance position into the room
vec2 f = fract (vTexCoord2.xy);
vec3 vCubePos = vec3 (f * vec2 (2.0, 2.0) - vec2 (1.0, 1.0), 1.0);

// Compute position where the ray intersects the cube
vec3 id = 1.0 / vDir;
vec3 k = abs (id) - vCubePos * id;
float kMin = min (min (k.x, k.y), k.z); += kMin * vDir;

// Sample cubemap at this position
vInterior = textureCube (TextureInterior, vCubePos);

When i add the piece of code marked with “HACK” (ie: vDir.y = vEye.y * 0.5;) the result is this:

Screenshot 2

As you can see, the vanishing point is not completely wrong anymore, from grazing angles it looks much better. However, the result is still not perfect, it is still somehow distorted.

Can someone check out Humus demo, whether there are the same problems? And can someone tell me, what i might be doing wrong?


No one?

obviously nobody has a problem to which interior mapping is a solution at the moment. It’s relatively new, and a solution to a very specific problem.
It’s a very nice technique though, I agree.

Isn’t this just a cube map?

Yes, it is.

I don’t see anything obviously wrong in that piece of code, although I notice that you flipped some signs, but that shouldn’t cause this kind of problem. The “HACK” stuff obviously doesn’t belong there though.

What kind of data comes in to the vEye parameter?

Yeah, the sign-flipping was necessary, but it shouldn’t change anything. But now that i said it, i should expect that it is the root of all evil :wink:

vEye contains the vector from the pixel to the camera position.
Calculated in the vertex-shader, interpolated across the triangle:

vEye = ( -;

Whether i normalize the vector or not, does not make any difference during interior mapping.


Yeah, it shouldn’t matter whether you normalize it or not (although if you were to normalize it in the vertex shader that would screw things up). Does the vertex data match the ones I use?

No, i don’t normalize it in the VS, i know that interpolation wouldn’t work well then.

I don’t know exactly which vertex-data you mean. I don’t render the geometry as you do (afaik you place unit-sized boxes all over the world and scale them in the VS). I render fixed geometry without any additional transformations applied. I was not sure, whether i could reuse the tangent of my TBN matrix, so i calculate and upload and additional tangent, that is calculated like this:

// p1,p2 and p3 are the vertices of the triangle

Vec3 vNormal;
vNormal.CalculateNormal (p1, p2, p3);
vNormal.y = 0;
vNormal.Normalize ();

Vec3 vUp (0, 1, 0);

rvTangent = cross (vUp, vNormal).getNormalized ();

This obviously only works for geometry that is orthogonal to the xz-plane, as it is only supposed to work on house-walls.

Hm, i have a guess, what might be the problem:

I have found a few walls in my city-mesh, where the interior mapping seems to work perfectly (without the hack-stuff). Looking closely at walls where it works and others where it doesn’t work, i have found that in the non-working case the diffuse texture is applied with a non-uniform stretching factor. Ie. the the windows are stretched a little bit along the U or V axis, but only so few that it isn’t very noticeable by itself. Could this have a negative effect on the raycasting ? I guess so. If so i need to tell someone to fix his texturing routine. Or could i calculate the non-uniformity factor of the texturing, pass it as an additional attribute to the shader and use it to fix the ray ?



Just to confirm: The artifacts were caused by slightly distorted texture-mapping. Surprisingly even a very small distortion made the result very visibly incorrect. The problem was solved by storing the non-uniformity factor of the texture-mapping for every polygon and adjusting the view-ray with it. This did remove the artifacts, the results are pretty cool now.