AABB lines in Mark's bumpmap demo

[JD]

Anyone else noticed the lines in Mark Kilgard's bumpdemo? I have gf2 and 41.09 drivers. The single pixel wide AABB wireframe lines are only visible when mipmapping the bumpmaps. With full aa/af on it's hardly visible but takes a frame hit.

[Korval]

With full aa/af on it's hardly visible but takes a frame hit.

Lines should be of virtually infinite size. Antialiasing attempts to approximate this. So, it's hardly surprising that the lines seem to vanish.

[JD]

True, but do you have idea why there are lines in the first place?

[Jan]

I´m not sure if it´s the same problem i have, but in my app i do see some black lines on objects with bumpmapping, too. But ususally they are clearly visible (they don´t vanish when moving).
John Carmack once said, that creating mipmaps for bumpmaps (or normalsmaps) is an interessting field. Any idea if special mipmap routines for bumpmaps could improve the image quality?
I think a new mipmapping mode could be added to the SGI_create_mipmaps (or whatever) extension.

Jan.

[JD]

I use Mark Kilgard's bumpmap paper/code to generate the mip sub levels by downsampling each level manually. The bump normals don't work right when you let gl build mips. The lines in his demo/my app flicker on/off and completely go away if not using mipmapping, only level zero base normalmap. Also, the lines go away if mipmapping is on but using either all black or white heightmap that is then converted to normalmap using Mark's code. Yet, the downsampling code is working correctly. I use zero sized texture borders and clamp to edge in all my textures as well as for vector normalization cubemap.

Jan2000, can you download bumpdemo from nvidia and check it out for me? I like to know if you see distinct single wide lines in the shape of an AABB box that are drawn over the torus. Only one AABB box lines are drawn per light source. I've tried 41.09 and 43.45 drivers and still have problems. I emailed Mark and sent him a pic of what the lines look like. I'm on gf2 card and the lines are very visible if you use no aa/af filtering. Thanks.

[dorbie]

It's not merely a case of downsampling MIP maps. The lighting result needs to become an integration of the higher sampled bump map lighting result. So basically there is no correct solution using something like Phong/Blinn. Your bump maps just become progressively flatter with distance, which is probably not far from a decent solution given the method.

I don't know the lines you're referring to but trilinear filtering on the bump map shouldn't produce lines even with a naive downsample IMHO (unless this has happened at the tile boundary due to unwrapped filtering). Perhaps one problem is that you only have bilinear MIP map filtering.

Have you tried high quality settings on the card's texture filtering in the desktop display settings? They can and do mess horribly with the true trilinear zone and squeeze the MIP transition to much too small a region in anything but the highest quality modes.

[This message has been edited by dorbie (edited 08-18-2003).]

[dorbie]

Could we see a pic?

[JD]

Click on the "error" link under screenshots heading on the left window frame. Let me know what you make out of this. Thanks.
http://forged3d.tripod.com/

[Cab]

Are you using normalize cubemaps? (or cubemaps for something)
I have a similar problem using cubemaps. The code is correct (GL_CLAMP_TO_EDGE, ...) but there is a subpixel line between the faces of the cubemap (different depending on the faces).
Currently, I have not investigated the reason but it is there (difficult to see but it is there).

Hope this helps.

[Eric Lengyel]

This looks just like an artifact that I was seeing a couple years ago on the GF2. I showed it to Nvidia engineers (in person), but I don't think it was ever fixed. My guess is that it's a hardware bug that occurs when the cube map sample straddles two faces. Try running on a GF3+ and see if the problem goes away -- I don't see the problem on later hardware.

[This message has been edited by Eric Lengyel (edited 08-19-2003).]