Q3Map2 2.5.16 : lightmaps passing through brush HELP ME!!

(Kyashan) #1

Hi to all!!!

Premise: it excuses the errors but I am Italian and I don’t know well the
English :stuck_out_tongue:

My problem is known to many and more times and has been treated on this forum. It speaks of the light of the “sun”

that it passes through the brushes using a sky shader.

I have found many posts on this annoying problem and many they have resolved with various methods. In the most

greater part of the cases him it uses the function fun_group and _lighmapscale to resolve this problem. I have read

(from a post there codey and ydnar) that this bug has been resolved in the version of Q3map2 2.5.11
I use the version 2.5.16 but the problem it continues to it managed. :bored:

I don’t know thing anymore to do… I feel like crying!!! HELP ME!!!

To create my maps for Quake III Arena i use:

GTKRadiant 1.2.13
Q3map2 2.5.16 and Q3MapBuild 1.0 (build 25)
Windows XP Professional SP1
Pentium PC III @ 1Ghz (dual processor) - 2GB of RAM - nVIDIA GeForce 3 DELUXE with 64MB of RAM (driver detonator v.61.77)

I have sincerely tried her all but i don’t know whether to resolve this problem. I would like to know if in the use of

Q3map2 there they are of the options that I don’t know profits for this problem?

This is a map that I use for my test on this bug…

http://xoomer.virgilio.it/ale.rigitano/test_lightleak.pk3

Besides here are some images…

http://xoomer.virgilio.it/ale.rigitano/lightleak_test_01.jpg

http://xoomer.virgilio.it/ale.rigitano/lightleak_test_02.jpg

http://xoomer.virgilio.it/ale.rigitano/lightleak_test_03.jpg

Options in Q3map2:

-fs_basepath
-fs_game
-flares
-fulldetail
-info
-meta
-patchmeta
-skyfix
-v
-verboseentities
-threads 2
-fs_basepath
-fs_game
-vis
-saveprt
-threads 2
-light
-fastbounce
-patchshadows
-bounce 1
-bouncescale 5
-threads 2
-bsp2aas
-forcesidesvisible
-optimize
-breadthfirst
-freetree
-grapplereach
+set fs_basepath
+set sv_pure 0
+set r_vertexlight 0
+set r_fullscreen 1
+set bot_developer 1
+set bot_debug 0
+set g_wf_warmup 0
+set fs_game baseq3
+devmap

I hope can help me :banghead:
Thanks to all… Kyashan

(ratty redemption) #2

I dont know if youve tried this fix, but if you paint all sides of a brush (detail or structural) with a shader similar to my one then it blocks most sun light, although you may have to experiment with the placement of these light blocking brushes.

textures/_ratty_terrain/light_block
{
	qer_editorimage textures/_ratty_terrain/nodraw.tga
	surfaceparm nonsolid
	surfaceparm nomarks
	{
		map $whiteimage
		alphagen const 0
		alphafunc gt0
	}
}

the editorimage line can point towards any image so you could use the common/nodraw image.

recently I used this method to stop sun light leaking through a mountain to my cave tunnels underneath, although I would of expected no sun light to get down there, it was doing so before I placed a ‘caulk hull’ type arrangement of light blocking brushes, around my tunnels.

they are intersecting the caulk faces of the trisouped mountain brushes, and it seems to work perfectly now, although I haven`t tried making them structural in this case to also block vis.

(Q.) #3

@ratty
Can nodrawnonsolid(not nodraw) do the same job?
Just wondering. :???:

(ratty redemption) #4

I think I used nodraw nonsolid before to block light but Im not sure it always worked, Ill do some tests and report back later today.

if it does work there should in theory be a slight fps increase, as no tris would be drawn in game, where by the light blocking shader above does draw, as seen by r_showtris, just it`s texture is completely transparent.

(obsidian) #5

Is this occuring with a “normal” sky shader or are you using a skybox entitiy?

(Kyashan) #6

Boys… I everything want to thank you!!!

  • = MEX for obsidian =-

In my case I am using a sky shader and not an entity _skybox.

The shader used for the sky is of ownership of ydnar with some changes for my map.

If you ago pleasure I can make to see you some screenshots of my real map. I hope to resolve this problem… I don’t know whether to do!!! :frowning:

However this is the map of example that I use for my test (in this case for the bug of the lights :???:

link for the download: http://xoomer.virgilio.it/ale.rigitano/test_lightleak.pk3

Perhaps I am me little expert but I hope that you as the other ones can help me :bored:

Thanks 10000000000… :smiley:

Kyashan :banghead:

(ratty redemption) #7

Ive just tested nodraw nonsolid on the same brushes that worked with the above light blocking shader and nodraw nonsolid doesnt work …maybe it did in the past with sun light, Im not sure, but it definitely doesnt work now for me, so I recommend the light blocking shader, unless someone else can suggest something else?

(codey_) #8

In case you have missed it there’s a lot of talk about blocking light leaks in this thread:

http://www.splashdamage.com/index.php?name=pnPHPbb2&file=viewtopic&t=10060

Example of how it can look with a _skybox leak and ydnar’s fix

http://www.splashdamage.com/index.php?name=pnPHPbb2&file=viewtopic&t=10203

Here’s my version of ratty’s shadow shader - I added Radiant transparency for easier editing and noimpact just for double security so nothing strange happens in-game with rockets and such.

//============================================================================
// magic shadow maker - thanks to ratty redemption for the code!
//============================================================================

textures/codey1/shadow 
{ 
    qer_editorimage textures/codey1/shadow1.tga 
    qer_trans 0.50
    q3map_pointlight 
    surfaceparm nonsolid 
    surfaceparm nomarks
    surfaceparm noimpact 
    { 
        map $whiteimage 
        alphagen const 0 
        alphafunc GT0
    } 
}

And here’s the image I use in Radiant:

Hope this can help you.

cheers

(ratty redemption) #9

ydnar to the rescue!

He told me to caulk the box surrounding the _skybox instead of having the sky shader on it and lo and behold - the leaks went away.

_codey, those are good links and thats a useful tip from ydnar which I must of missed when you posted it in the other thread, but Ill try that when I get round to making my skybox :slight_smile:

and admittedly I havent tested the light blocking shader with rockets, although there probably isnt any harm in using noimpact, even if it might not be needed, so I`m going to update my original shader with your additions.

I agree its also more convenient to have it use qer_trans which I normally use on other nodraw shaders, but hadnt thought of using it on this one :slight_smile:

(Q.) #10

Oh. really?
Thank you for your testing.

BTW it’s one mystery that q3dm17sample.map is using nodrawnonsolid at the bottom of what is so called volume light.

(ratty redemption) #11

np, and have you tried compiling that sample map with a recent version of q3map2? it could be the lighting code works different now.

(obsidian) #12

I think this problem has more to do with improper mapping techniques more than anything to do with Q3Map2. I took a look at your map and rebuilt it. Some things to keep in mind:

-stick to as large of a grid size as possible.
-miter corners.
-caulk all unseen faces.
-use caulk-hull method, it solves a lot of other issues as well as lighting problems. (didn’t do that here as it was unnecessary)

Sample map:
http://members.lycos.co.uk/quakeroats/maps/

(Kyashan) #13

… for codey_

Dear codey_ I have created a scipt with your code (textures/codey1/shadow etc etc) but this doesn’t work.
In GtkRadiant and in Q3ase this script is not seen and therefore I cannot try it. The procedure that I have followed is that used for the creation of the other whole scriptses but with this it doesn’t go… perhaps mistake something :frowning:

===========================================================

… for obsidian

Dear obsidian I thank you for your availability and for your jewel help. Do you know a tutorial for the technical caulk hull? Sincerely I have never used her and I have to say that with this method the problem of the luci/ombres resolves a lot him.

It excuses my inexperience
Kyashan :slight_smile:

(Q.) #14

@ratty
Not yet and I am rather reluctant to test something at the moment…sorry. :rolleyes:

(ratty redemption) #15

np, but if you do oneday and the results are different, then please tell us :slight_smile:

(codey_) #16

You can’t just copy my shader straight off. You need to grab the picture I posted and move to you own customs texture folder, then add my shader to you own shader file, then edit the file path to point to the texture. But that’s only to make things easier in Radiant. The shader will work in-game without my little icon texture, you’ll just get the ‘image missing’ in Radiant if you skip it.

cheers

(ratty redemption) #17

Ive discovered we dont have to paint every side of a brush with the light blocking shader, the other sides can be caulk… the advantage being less tris are drawn in game.

I`ve also noticed that vertex lit shaders seem more prone to being affected by light leaks then lightmap shaders.

although we can also use the q3map_vertexscale command to tweak the brightness of vertex shaders which might be more convenient in some cases then placing light blocking brushes.

(obsidian) #18

Light blocking shaders are usually nodraw, so there are no additional tris being drawn in game.

Caulk is a solid, light blocking, nodraw shader - so that’s why we use it on unseen faces of brushes - it’s solid, blocks light and reduces tricounts.

@ratty, do you mean that if disabling lightmap lighting in the game options will cause light leaks or when one actually writes a vertex shader? That’s an interesting observation, I’ll have to check it out sometime.

(obsidian) #19

BTW, in addition to my original post:

I’m not entirely sure how this works or if I’m explaining this correctly, but as I understand it this is why we try to stick to relatively large grid sizes when roughing out the basic structure (or “caulk hull”) of your map. The way lighting gets sampled is according to luxels (lightmap pixels) so light leaks may occur when the brushes are mismatched from the lightmap sample points as in the case with Kyashan’s map. Hopefully ydnar or someone else can verify this.

Of course, there are other reasons for sticking to larger grid sizes for the stucture of your map. Hinting on a small gird will likely cause unnecessarily long vis compile times.

As a reference, I think every level editor should read this. Although Q3W is severely crippled ATM, I did manage to find this thread via Google. It’s Q’s (Quakin’) Sample Map thread. He goes quite extensively into optimizing a map using the caulk hull method as well as hinting, preventing overdraw, etc, etc. This is my all time favourite thread. Read it a couple of dozen times until you understand it.

http://www.quake3world.com/ubb/Archives/Archive-000004/HTML/20020703-6-020488.html

(Kyashan) #20

… for codey_

Dear mapper…

Thanks still for your availability. I don’t succeed in resolving the problem of
the light through the walls yet.

(for the sky I don’t use an entity _skybox but a normal sky shader of ydnar)

Yhis is the structure of my file PK3 with your file shader and your image
“shadow1.tga”

http://xoomer.virgilio.it/ale.rigitano/codey_shader.gif

Thanks still
Kyashan