q3map2 light issue?

[Hipshot-zz]

So the version bundled (Q3Map (ydnar) - v2.5.17n-git-5daf2e2) (unless updated recently?) has an issue with the light phase, compared with the older q3map2 (Q3Map (ydnar) - v2.5.15).

So, I'm not exactly sure where the issue is located, I just know that light that bounces from certain surfaces won't do that in the newer version. Which makes light look different, I'm sure a lot of people will never know this, but I notice this big time in the way I light my maps.

The first image is from the newer version of q3map2, the second image is from the older. Notice how the light bounces on the pink leaves and lights up the scene, it's a very good looking effect:

This is the shader I'm using to test this, there might be an bug here, but I don't think so:

textures/hipshot_m16/leaf
{
qer_editorimage textures/hipshot_m16/leaf.tga
qer_alphafunc greater 0.5
qer_trans 0.99
surfaceparm alphashadow
surfaceparm trans
surfaceparm nomarks
surfaceparm nonsolid
nopicmip
cull none
deformVertexes wave 25 sin 3 8 .1 0.2
{
map textures/hipshot_m16/leaf.tga
blendFunc GL_ONE GL_ZERO
alphaFunc GE128
rgbGen const ( 1 1 1 )
depthWrite
rgbGen identity
}
{
map $lightmap
rgbGen identity
blendFunc GL_DST_COLOR GL_ZERO
depthFunc equal
}
}

And this is the light stage compile line, same is used by both programs:

q3map2.exe" -light -patchshadows -fast -samples 6 -gamma 2.5 -compensate 3 -v -bounce 10 -threads 4

Any ideas here, can this be fixed? Who really is the developer of this version of q3map2 btw? =D

[Garux]

surfaceparm trans is legitimately not bouncing.
I'm developer of this q3map2.

[Hipshot-zz]

Would you say this is a "bug" in the old one and you corrected the mistake? Because that could certainly be the case too.
Because as you can see, the result is very different here, even with surfaceparm trans.

[Garux]

I say

• trans stuff being trans for light is logical behavior
• that's not me, who established this behavior
• try to remove trans

[Hipshot-zz]

Nah, it has nothing to do with the trans part, it's the editor image. Which I know sounds strange, but it does effect it if there's no lightimage specified.

So I suppose, is it possible to get this result in the new q3map2? This pink bouncing light or should I just use the old compiler?

[Hipshot-zz]

Being a little late with my reply here.

So I think this should be fixed as the default behaviour of the compiler. BUT, there's a reason to why it was "removed" these years ago, either was it a mistake or deliberately?

I can see several issues with "fixing" this, but most of these issues might never be seen by any user that isn't aware really, I'm a bit tired so I won't go into all this, but yea. Ensiforms suggestion about a flag/switch might be good, either to enable, or disable.

I would have loved to use the new compiler for this map with the modern model support.

---

About the compile times:
They are so much higher that I feel that I go back years in hardware haha, the older compiler is just so much faster, especially since I can't really see the difference in quality.

Garux, if you want, add me to steam if you want me to test any compiler thing or send you something easier:
https://steamcommunity.com/id/hipshot/

[Garux]

Transparent objects let light through, it makes perfect physical sense to not bounce from them.
Alphashadow objects technically should bounce only by opaque parts, which in most cases would be subtle insignificant impact (e.g. grate only emitting by 1/10 of surface area). So throwing these away is good optimisation in real cases imo. Also if we simply enable bounce for alphashadow, bounced color will depend on transparent parts color too, which may be w/e.
Alphashadow bouncing only may be important, when bounce is overpronounced artificially imo, then it may be implemented 'manually' like: q3map_cloneshader -> sp trans, q3map_surfacelight, q3map_offset, blendfunc gl_zero gl_one.

Wrt performance i suspect it's like alphashadow has some sampling by default, and these samples get multiplied by number of samples you request in some of: skylight 6, sunExt 32, -samples 6. Possibly @divVerent can shed some light on reason of such dramatic performance penalty.

Wrt steam: i'm not registered there xD

[Hipshot-zz]

Yea,. you are probably right Garux, it would be strange to bounce like that in "reality", it makes more sense to let the light through really.
Maybe a shader parm could be added, like "q3map_transbounce" or something, because at this point I'm not sure how I can force this behaviour with this compiler, on the other hand, I could be using the old compiler just using .ase models, just have to use a custom plugin in into blender.

Anyway, this is the level I'm working on. This is using the old compiler then, compile time 88 sec.

https://zfight.com/misc/images/maps/m16/9.png
https://zfight.com/misc/images/maps/m16/10.png
https://zfight.com/misc/images/maps/m16/11.png
https://zfight.com/misc/images/maps/m16/12.png
https://zfight.com/misc/images/maps/m16/13.png

[Garux]

I'm not sure how I can force this behaviour with this compiler

it may be implemented 'manually' like: q3map_cloneshader -> sp trans, q3map_surfacelight, q3map_offset, blendfunc gl_zero gl_one

possibly w/o offset
 

using .ase models, just have to use a custom plugin

old compiler supports .obj, i suspect this is simpler option, unless you are using vertex alpha
 
Juicy rust in your level!

[divVerent]

As for that change - fd6d38c - it was necessary to get rid of all the aliasing in the glowplant map, I think. It has a light source very close to a grate, and projects the grate's pattern on a wall.

Without this, antialiasing applies only to surface edges, but not to alphashadow.

Feel free to put that logic behind an option, but for Xonotic we definitely still need it.