View Full Version : ClipMap + MipMap = invisible : can anyone confirm?

05-10-2013, 02:14 PM
I came across a rather catastrophic render bug while working on some assets for a realtime iOS experience...took way too long to track the source of the issue down, and was wondering if anyone else had experienced it!

Objects with clip maps render incorrectly, resulting in partially or almost entirely invisible geometry. The object appears to be rendering correctly (based on partial polygons or random scattered pixels), but the clip map just goes crazy. Please refer to the attached screenshots for examples.

114236 114235 114234

Apparently it's the mipmapping...

Clip Map, as applied to the object settings under the Render tab, should show the geometry where areas of the applied image = 0.0, and hide the geometry where areas of the applied image are 1.0.

Either random pixel scattering (though object is 99% invisible), or if triangulated, partially visible polygons with random pixel scattering in the invisible areas.

Forcing mipmaps to off fixes the issue, but shouldn't be required (and obviously prevents usage of mipmaps to reduce high frequency details in areas of problematic aliasing).

- Triangulation does not fix anything, though some random parts of the model may show up.
- Inexplicably does not affect all geometry, even across different parts in the same object layer (for example, I had some trees in this same project that were not affected by the bug).
- File format does not appear to influence the output, as both PSD and JPG files produced same results.
- Makes no difference if you use nodal texturing or transparency (I often use transparency in the layered shader so I can preview in OpenGL, but override with a 0.0 scaler in the node editor, however, this was irrelevant to the bug).
- Adjusting UV maps makes no difference.
- Texture proportions do not matter (I tested horizontal, vertical, and square texture formats).

05-15-2013, 03:45 PM
You have to remember that a clip map is one bit. (0-127=Black, 128-255=White). So having mips on and pixel blending will only cause it to disappear due to mips blurring when making the smaller images. This which in turn as a clip could push the image to move a pixel more into the black or white as the mip is made. So not a bug at all. Nature of the clip. As for the real-time aspect, alpha is always used as the transparency or clip. Does not matter if that alpha is 1bit through 8bit since it will be used as the transparency.

Rule of thumb, don't use mips/pixel on clip maps in Lightwave. Heck I even make them 2x to 4x larger so one can have the resolution needed to clip say a leave without jaggys.

Try this image as a transparency and a clip map with the pixel and mips off. You will see the difference right away and see why things will disappear when you have LW make MIPs for the image when loaded.


05-15-2013, 04:57 PM
I understand the 1-bit nature of clip maps, the issue is that mipmapping is always turned on by default when applying images in the clip map texture - and it usually works just fine. I'm trying to find out if anyone else has had inconsistent render results while using clip maps as well.

Of course blurring the image will result in inconsistencies in the final 1-bit clipping (reduced detail due to reduced resolution or origin texture). However, when the entire object disappears with random pixels within the expected clipped region, that's not cool, and entirely inconsistent with what should be rendered. Meanwhile, if triangulated, the polygons are partially showing up with the correct clip map shape...which is why I suspect it's not just a blurred asset issue, though somehow connected. A weird combination of mipmapping and polygon/UV shapes?

05-15-2013, 06:02 PM
Well, finding the right mip-map level to use can be quite tricky with UVs. And since clip-maps are used extremely early in the renderer (they are after all an early rejection test to check if a polygon is hit by a ray), it may be that not all required information is available at that time to handle it properly.