Pixelated lightmaps

Slippy · Post by **Slippy** » Fri Dec 19, 2008 9:12 pm

Hey everyone. I made a quake iii map in gtkradiant for use in irrlicht, and when viewed in the engine, all the textures in the bsp are all blocky looking. here's a SS to show what i mean... http://dl-client.getdropbox.com/u/92625 ... blocky.png

I viewed the same level in the cake engine, and the textures are smooth. Any help would be nice

TY

bitplane · Post by **bitplane** » Fri Dec 19, 2008 9:44 pm

Looks like texture filtering flags are not set on the lightmap layer. This is probably a problem with your exporter. What did you make it with? Also, can you provide the BSP mesh?

Slippy · Post by **Slippy** » Fri Dec 19, 2008 9:51 pm

I made it with GTKRadiant. Heres the .bsp -> http://dl-client.getdropbox.com/u/92625/myQ3map.bsp

bitplane · Post by **bitplane** » Fri Dec 19, 2008 10:07 pm

Can you also provide textures please? Otherwise it will be pretty difficult to see the problem

Slippy · Post by **Slippy** » Fri Dec 19, 2008 10:11 pm

Ok, here's the whole .pk3. http://dl-client.getdropbox.com/u/92625/myQ3map.pk3

bitplane · Post by **bitplane** » Sat Dec 20, 2008 3:35 am

Looks like a bug to me, the lightmap renderers ignore the bilinear filtering flag on texture layer 1.

Reproducible in quake map example, replace the block of code that does bsp load and node creation with:

Code: Select all

	scene::IAnimatedMesh* mesh = smgr->getMesh("20kdm2.bsp");
	scene::ISceneNode* node = 0;

	int c = mesh->getMesh(0)->getMeshBufferCount();
	for (int i=0; i<c; ++i)
	{
		scene::IMeshBuffer* mb = mesh->getMesh(0)->getMeshBuffer(i);
		mesh->getMesh(0)->getMeshBuffer(i)->getMaterial().TextureLayer[0].Texture = 0;
	}
	
	node = smgr->addMeshSceneNode(mesh->getMesh(0));

Renaming topic and moving to bug reports

Slippy · Post by **Slippy** » Sat Dec 20, 2008 3:41 am

Ok, thanks for the bug discovery. Didn't want to think it was just a problem on my end.

bitplane · Post by **bitplane** » Sat Dec 20, 2008 4:06 am

Duh I'm an idiot. I've renamed the topic again

It's because your lightmap is too small (128x128), try a bigger one. My new guess is that the other engine you mention enlarges and smooths the lightmap, or displays it using a shader.

We could always add lightmap shaders if someone wrote them though

(any volunteers?)

BlindSide · Post by **BlindSide** » Sat Dec 20, 2008 4:14 am

Shaders don't affect filtering modes afaik. I still have to set the bilinear flag within the engine...

EDIT: Wait, my spidey-misunderstanding senses are tingling...

bitplane · Post by **bitplane** » Sat Dec 20, 2008 4:18 am

BlindSide wrote:Shaders don't affect filtering modes afaik. I still have to set the bilinear flag within the engine...

So it's not possible to get a smoother transition between the pixel values in a vertex shader?
Then I guess the cake engine must have a minimum lightmap size

I'm going to have a little play in rendermonkey with a 2x2 bitmap and see what happens

BlindSide · Post by **BlindSide** » Sat Dec 20, 2008 4:21 am

It would have to be in the pixel shader, unless you used vertex colors as the lightmap.

A simple blur might suffice, but it's a waste of runtime resources on something that could be done as a preprocessing step. Infact, an Irrlicht utility function could just be added that enlarges an image and then applies a gaussian blur, it's a good way to get half-decent quality out of trial versions of Deled for example, which only export to 128^2 or something.

Another quirky idea would be to blur the lightmap as a post-process, this involves rendering the lightmap information separately in another pass, and may cause some dark halos around objects (Unless you also render a depth map and only blur if the depth is close enough). I've tried this on shadowmaps and despite the obvious drawbacks it does leave everything looking alot smoother.

bitplane · Post by **bitplane** » Sat Dec 20, 2008 4:31 am

I see the problem.. I do a 2x2 pixel with bilinear filtering on a quad in rendermonkey, I can see the pixelated effect if I zoom in but it isn't very bad at all.

However, if I then multiply my values by 4 like the M4 lightmap renderer does it looks similar to the quake map without a diffuse texture. So the scale comes after the texture read, causing those ugly steps. I doubt there's a way around this

So the answer is get a bigger lightmap!

BlindSide · Post by **BlindSide** » Sat Dec 20, 2008 4:44 am

Yeah, bilinear is performed in 8-bit on hardware unfortunately. There is a way around this, and it's to perform bilinear explicitly in the pixel shader, but this is expensive.

If you are interested anyway, basic formula is here.

Slippy · Post by **Slippy** » Sat Dec 20, 2008 5:14 am

Wow, thanks a lot to both of you. I did confirm for myself that q3map2 does output 128 lightmaps. I googled for a solution, but it seems q3map2 can't produce larger lightmaps.

bitplane · Post by **bitplane** » Sat Dec 20, 2008 5:25 am

You could create a 256x256 render target for each lightmap, then draw it with draw2dimage, then replace the originals.
Or you could save the lightmaps back out again and scale them in a graphics program, or you could lightmap the mesh in irrEdit.