hi everybody,
in my map base, i got some red echos (cf pict 1) where i didn’t got red lights.
for lighning my map, i use mostly coronas but for red lights i use coronas + red lights. i tryed to fix it from the lm_ picts but its too hard … i am erasing some good lightned areas …
can anybody help ?
picts 1/2
lm 2/2
this kind of thing can happen when walls are very thin so lightgrid covers a part of either side of the wall
although it does not look like this is the case here could you post the compile settings you are using as this can sometimes have strange effects like this with lighting
also how well have you optimized the vis in you map as vis portals have an effect on how light entities compile
should i reduce my lightgrid ?
my vis is not optimised since i got a lot of hint brushes but i have time for compiling : D (while i am at school)
lightgrid doesn’t affect lightmaps at all.
That red is very odd. Some screenshots with r_lightmap 1 might give you a clue.
have you tried manually deleting the lightmaps then recompiling?
sorry i did not mean the lightgrid i meant the lightmap sample size. i had a similar problem with light bleeding though thin walls but looking at the location of some of these red spots it doubt that this is the case
i would recommend you go and optimize your vis now. it does a lot more than just reducing the compile time. it can also make very drastic reductions in the amount of time it takes to calculate lightmaps (im guessing that it can discard a lot of faces that are not visible for the lights point of origin saving a lot of calculations, and cutting out faces that should not have light projected might even solve this problem)
i have already deleted my lightmaps … but nothing.
i don’t have a _minlight , _minvertexlight , _mingridlight …
should it comes from it ?
i noticed that there is two way to color lights : color & _color .
trying the two together , and each separate. hope it will stop bugging
_minvertexlight & other min cmds doesn’t work. that just minimized the red lights but they are still there.
What keys and values do you have for your worldspawn?
Do you compile from within the editor or do you use some other method (bat file for example)? What are your compiling settings?
Have you tried to select the walls, floor and ceiling and turn them into a func_group, then recompile? Just to try somehting else (I do this trick on occasion just to test what will happen).
compile commands from editor :
[q3map2] -meta -mv 1024 -mi 6144 “[MapFile]”
[q3map2] -light -faster -samples 2 -filter -external -lightmapsize 256 “[MapFile]”
keys in my worldspawn ( before trying with _minlight etc …) :
“classname” “worldspawn”
“_blocksize” “128 128”
“gridsize” “512 512 256”
“mapcoordsmins” “-341 987”
“mapcoordsmaxs” “4028 -3266”
“lightgrid” “256 256 256”
“_color” “1.000000 1.000000 1.000000”
“ambient” “5”
i never do func_group since i don’t understand utility of this method
IIRC one should use -fast and not -faster. Try -nocollapse in the light compile stage to get rid of the red light “effects”.
the ‘ambient’ key was what screwed me up - try _minlight instead
also you shouldn’t need _color if its 1 1 1 (that is the default)
The mapcoords are a bit odd (covering a size of 4369 x 4253) - they should be square and ideally aligned onto ‘block’ boundaries (in your case multiples of 128 as you have a _blocksize of 128). Turn on viewing blocks in radiant and you should see them highlighted in blue. Make the mapcoords bigger than the extremities of the map so that command map markers can be drawn and don’t get chopped off.
func_groups are great for tweaking lighting (have a search for _lightmapscale) and for selecting things more easily in the editor.
I would try the following
In worldspawn
Key/Value:
classname/worldspawn
_blocksize/128 128
gridsize/512 512 256
mapcoordsmins/-341 987
mapcoordsmaxs/4028 -3266
lightgrid/256 256 256
ambient/5
_lightmapscale/2
Regarding _lightmapscale/2: Default is 1. Use value 2 when you are working on your map (for faster compiles) and reduce it to 1 (or 0.5) in the final compile. When you make the final version of you map and release it.
In the editor and map
I use radiant version 1.4 and these steps are for that version:
1: Make sure you have de-selected everything. (That nothing is selected. Hit Esc).
2: Go to a room that you know has interesting shadows. (For example, a big shadow that goes over a wall, the ceiling and the floor.)
3: Select wall, floor, ceiling and other relevant brushes in that room
(SHIFT + left mouse button click)
4: Turn them into one func_group
(Right click in the 2D window and select func_group).
5: De-select everything (hit Esc).
6: Save. Take a short break. Stretch your back, hands/finger etc.
7: Select any brush that belongs to this new func_group
(SHIFT + left mouse button click)
8: Bring up the Entity Widown (hit N).
9: Enter the key/value _lightmapscale/0.125
(Default is 1. I use 0.5; 0.25 and 0.125.)
10: Compile.
11: Observe the differences and similarities in the map and in that room, compared to older versions of your map.
This is what I would try, to learn the benefits of _lightmapscale.
//Loffy
i tryed what you proposed. it looks much better and its look to work. but should i add detail brushes in my groups ? since i got some bad lightning on detail brushes.
Yes, you should select all the brushes that are having these “red light” issues. So this means both structural as detail brushes…
From the images you posted and mainly because the _lightmapscale is solving the issue It looks to me that some of the red light entities are “leaking” through the wall: Do you have any red lights near the areas that are having these light issues?