Head hurts: External lightmaps and consistent lighting

[obsidian]

Right, I'm experimenting with some external lightmaps on certain surfaces but no matter what I try I can't seem to get consistent results. I'm wondering if there is some simpler solution or something obvious I'm missing. Maybe some of the programmer types around here can poke in the code to see what Q3Map2 is doing.



For some reason, external lightmaps are rendered 4x darker in game even though the lightmap pages are comparitively consistent in brightness. I really don't know why this is and if there is a simple fix here, everything is solved. I can compensate by forcing external lightmaps to be rendered 4x brighter.

This causes another issue, while everything looks alright with r_overbrightbits 0, r_overbrightbits 1 cranks the external lightmaps gamma up until it looks as if the surfaces have reached critical mass (probably because I am increasing the lightmap brightness). I can fix by using "rgbGen identityLighting" instead of "rgbGen identity" which flexes the vertex colours from 0.5 to 1.0 depending on whether r_overbrightbits is on or off.

Now everything looks consistent with r_overbrightbits 0, but with it turned on normal surfaces will have overbright but external lightmaps will not. I tried playing with -gamma and -compensate to fix, but for some reason those two commands only seem to affect internal lightmaps and I'm more or less back to the original problem of external lightmaps being too dark.

Code: Select all

textures/tranquility/concrete
{
	q3map_lightmapSize 1024 1024
	q3map_lightmapBrightness 4.0
	qer_editorImage textures/tranquility/concrete.tga
	{
		map textures/tranquility/concrete.tga
		rgbGen identity
	}
	{
		map $lightmap
		blendFunc filter
		rgbGen identityLighting
		tcGen lightmap
	}
}

Sometimes I hate level editing.

[Silicone_Milk]

r_overbrightBits appears to be simulated for external lightmaps.

See:

Code: Select all

void ColorToBytes( const float *color, byte *colorBytes, float scale )
{
	int		i;
	float	max, gamma;
	vec3_t	sample;
	
	
	/* ydnar: scaling necessary for simulating r_overbrightBits on external lightmaps */
	if( scale <= 0.0f )
		scale = 1.0f;
	
	/* make a local copy */
	VectorScale( color, scale, sample );
	
	/* muck with it */
	gamma = 1.0f / lightmapGamma;
	for( i = 0; i < 3; i++ )
	{
		/* handle negative light */
		if( sample[ i ] < 0.0f )
		{
			sample[ i ] = 0.0f;
			continue;
		}
		
		/* gamma */
		sample[ i ] = pow( sample[ i ] / 255.0f, gamma ) * 255.0f;
	}
	
	/* clamp with color normalization */
	max = sample[ 0 ];
	if( sample[ 1 ] > max )
		max = sample[ 1 ];
	if( sample[ 2 ] > max )
		max = sample[ 2 ];
	if( max > 255.0f )
		VectorScale( sample, (255.0f / max), sample );
	
	/* compensate for ingame overbrighting/bitshifting */
	VectorScale( sample, (1.0f / lightmapCompensate), sample );
	
	/* store it off */
	colorBytes[ 0 ] = sample[ 0 ];
	colorBytes[ 1 ] = sample[ 1 ];
	colorBytes[ 2 ] = sample[ 2 ];
}

It's strange, though, -gamma *should* be affecting the external lightmaps.

Do you have screenshots of internal and external lightmaps side by side without messing with r_overbrightBits, -gamma, or -compensate?

[obsidian]

That's the first screenshot above:
r_overbrightbits 1
-light -fast -patchshadows -samples 4 -bounce 8 -dirty

It seems as if -gamma and -compensate does in fact affect the external lightmap, but it's not affecting it consistently with the internal lightmaps, so it's like shooting a moving target.

[DaEngineer]

Have you found a solution meanwhile Obs? I thought of using external lightmaps in a map I'm currently working on, that's why I'm asking. The shadows are indeed much sharper, but without overbrightbits the overall appearance is rather flat compared to the regular lightmaps.

[fKd]

-fast makes it darker right? but pass...

[obsidian]

Nope, no solution yet. So if you wanted some surfaces with higher resolution and some at default, you'll get inconsistency. It could be a program bug, I can't think of any other solution via either compile switch or shader.

[Silicone_Milk]

Shoot I was pretty sure I found a solution to this like a month ago but had thought you already solved it. I'll see if I can't dig up the post I was reading on it.

[skinNCNmaster]

i do believe one solution might be painting the shadows onto your texture.

[lvlshot]http://www.rave.ca/en/image/original/441487/[/lvlshot]

[DaEngineer]

The shadows aren't the problem. The problem is having high-res shadows AND overbrighting. Even if you would paint the lighting by hand, you still can't fake overbrighting by doing so. And by the way, who wants to paint shadows for an entire map by hand?

[skinNCNmaster]

check this out...

makes working on those "painted shadows/highlights" easier...
http://sgq3-mapping.blogspot.com/2009/0 ... htmap.html

when your looking at the lightmap, and can edit it..


if it can be done using black, it can be reversed to do white..

[obsidian]

FFS. That has absolutely nothing to do with what we are discussing. You are telling us the obvious stuff that we already know. The problem is with how Q3 handles OVERBRIGHTBITS WITH REGARDS TO HIGH-RESOLUTION LIGHTMAPS. If you have nothing of value to contribute to this conversation about overbrightbits, please keep out of it. Thanks.

[skinNCNmaster]

help is help is help, when its honest and open, i am trying to bee nice/helpful, why do you insist on continueing to try to be high and mighty over me?

and value is in the eyes of obsidian and only obsidian i guess

fine if you don't see how this information helped, your caught up on only seeing me

[obsidian]

i am trying to bee nice/helpful

I don't doubt that. But I doubt you even understand the problem, thereby your ability to help. Posting irrelevant images from your wizards game isn't contributing to a solution.

[ailmanki]

Is this something usefull?

http://shaderlab.com/q3map2/2.3/readme_previous.txt

2002-07-09 2.2.0-b12 Larger-than-life lightmaps are now
supported, up to 1024x1024. Add
q3map_lightmapSize H W to a shader
to use. Lightmaps are stored in
maps/{mapname}/_lm_NNN.tga and a
shader script q3map_{mapname}.shader
is generated. Also added
q3map_lightmapGamma N.N. Use a
value of 2.0 to simulate
r_overBrightBits 1 and
r_mapOverBrightBits 2 on external
lightmap images.

[obsidian]

Well, that's exactly what I'm doing, but it's producing the above problems.

[ailmanki]

I checked q3map2 source and there is some extra for external Lightmaps. If you have not yet- I suggest to try q3map2 from NetRadiant, but I guess that won't fix the inconsistency; I do not understand the code - hehe; yet NetRadiant has updates to it.

In any case it should be possible to mix different resolutions of external lightmaps, with the q3map2 shader keys. I think it was never the idea to use internal & external lightmaps at same time.
One enemy-territory level uses a kind of cheap approach, for very small surfaces it simply switches to vertex lightning - but I guess that is something you know a lot more about it then I do (I cant find the appropriate shader key for that, I wonder if just dreamed that part).

[sock]

What surprised me the most was the trouble with the external light maps, they did not support the hot glow effect and the marble behind all of the torches was dull. This led to some parts of the map needing different lighting models to cope with the visual effects and some weird problems with shadows across seams. For some reason the external maps had strange jagged lines and had to be manually fixed in Photoshop which took a while because of several compiles.

I think that's the same problem I was having with overbrightbits and external lightmaps. So far, from what I can tell, Q3Map2 isn't doing something right:
viewtopic.php?f=10&t=46294&p=878028

What kind of jagged lines are you referring to? Do you have a screenshot as an example?

I moved your question here as it seems more relevant, it will be lost in the screenshot thread. I remember seeing this thread and not really understanding your diagrams, they looked like a lot of white blob and weird shadows. I had never played with external lightmaps and was not sure what was going on.

The first problem I found is the over-bright issue:
[lvlshot]http://www.simonoc.com/images/design/co ... ref2_1.jpg[/lvlshot]
The only thing that changes between left and right is the shader command to enable 1024 external lightmaps. The compiler settings and lightmapscale are the same. I did not use skylight because I wanted to see what exactly was going wrong.

Second problem is quality of shadows on brushwork/patches vs misc_models:
[lvlshot]http://www.simonoc.com/images/design/co ... ref2_2.jpg[/lvlshot]
For some reason models have worse shadows when using external lightmaps. Got no idea why but it is seriously bad news because ASE models are amazing tools for creating repeatable/small detail.

Other things I have noticed is how internal lightmaps look different:
[lvlshot]http://www.simonoc.com/images/design/co ... ref2_3.jpg[/lvlshot]
There are internal lightmaps because the overbright is present, both are using the same lightmapscale and compiler settings but the shadows on the right are bad quality. Which leads me to think different internal pipelines for patches and models, especially final lightmap quality. Again annoying because models are far more useful than brushwork/patches.

Final problem is jaggered lines which can be fixed by external maps:
[lvlshot]http://www.simonoc.com/images/design/co ... ref2_4.jpg[/lvlshot]
Manually blurring the edges on the external lightmap fixes this problem, it is like the compiler needs a final pass on the lightmap to soften pixel edges.

Sadly I have no solution to your original problem, but I can certainly confirm the problem is there and a couple more for good measures!

[ailmanki]

About the lightmap difference, the documentation says it does generate a shader for each lightmap.
shader script q3map_{mapname}.shader
If that is the case, maybe that shader is bad ( or uhm incomplete )?

[ailmanki]

@Sock Try with a low -tresh value to get rid of the pixeled edges.

The reason lower values of -thresh are used are for when you want more accurate phong and bumpmapping. Lower values = smaller triangles = more samples per luxel (lightmap pixel) = more accurate normal = smoother shading

If you decompile the 2 maps you made for testing the shadow on ase and patch; if you decompile those; I believe you should get a patch back for the patch, and brushes for the ase. If you look at those brushes generated - I suppose you will see why it makes that broken shadow.
Maybe I am wrong and it generates only brushes when clipping is enabled - but maybe you had clipping enabled?

@Obsidian, I managed to misunderstand parts of your post several times - lol sorry.
Did you try exporting / importing lightmaps? Compare lightmaps of same size? E.g. generating an external lightmap with 128x128.
I thought maybe its just that the same 'amount' of light is projected on a bigger area - and thats why it gets darker, but well thats just hypothetic.