Static Lighting discussion (I think?)

Theoretically it's like this:

No vrad parameters: https://dl.dropbox.com/u/234836/mapping/vrad parameters/0 sun.jpg

This way
1) trees are either completely in the sun, or completely in the shade
2) shadows cast on the grass come from the collision mesh only, so just the tree trunk, not the leaves (meaning too small a shadow to see on large surfaces)

With StaticPropPolys (SPP): https://dl.dropbox.com/u/234836/mapping/vrad parameters/SPP sun.jpg

This way
1) trees are either completely in the sun, or completely in the shade
2) shadows cast on the grass come from the model polygons, so the trunk AND leaves. They are cast by the entire polygon though, even if the texture is at most parts transparant, so the "air" between the textured leaves on the polygons will still cast shadows

With StaticPropPolys (SPP) and TextureShadows (TS): (no screenshot yet cause i forgot the lights.rad file)

1) trees are either completely in the sun, or completely in the shade
2) shadows cast on the grass come from the model polygons, so the trunk AND leaves. Transparant parts of the texture do NO LONGER cast shadows, only the visibly textured parts
Note: the TextureShadows compile requires you to make a lights.rad file in the root folder of empires in which you explicitly tell which models this should be applied to (in this case the 4 pine models)

With StaticPropLighting only: https://dl.dropbox.com/u/234836/mapping/vrad parameters/SPL sun.jpg

1) shadows on the tree is calculated at polygon precision, so some parts can be in the sun, others in the shade
2) shadows cast on the grass come from the collision mesh only, so just the tree trunk, not the leaves (meaning too small a shadow to see on large surfaces)

With StaticPropPolys and StaticPropLighting: https://dl.dropbox.com/u/234836/mapping/vrad parameters/SPP SPL sun.jpg

1) shadows on the tree is calculated at polygon precision, so some parts can be in the sun, others in the shade
2) shadows cast on the grass and ON THE MODEL ITSELF come from the model polygons, so the trunk AND leaves. They are cast by the entire polygon though, even if the texture is at most parts transparant, so the "air" between the textured leaves on the polygons will still cast shadows

Note: Once i get the lights.rad file working i'll compile it with TextureShadows to see how much less dark it gets. I did try this yesterday but didn't see any difference

Note: The dark pine tree example is also mentioned on the valve developer wiki, with the advice to turn self shadowing off on the static props to fix this. This way however the bottom leaves don't have any shadows from the upper leaves at all which is equally as bad, just in the opposite way. So i can have pitch black shadows or none at all, can't yet have something inbetween.

EDIT

With SPP, SPL and TS WITHOUT the lights.rad file and with "ignore surface normal" set to yes for the models:
https://dl.dropbox.com/u/234836/mapping/vrad parameters/SPP SPL TS NOCULL 1.jpg

With SPP, SPL and TS WITH the lights.rad file and with "ignore surface normal" set to yes for the models:
https://dl.dropbox.com/u/234836/mapping/vrad parameters/SPP SPL TS LRAD NOCULL 1.jpg

With SPP, SPL and TS WITH the lights.rad file and with "ignore surface normal" set to no for the models (standard):
https://dl.dropbox.com/u/234836/mapping/vrad parameters/SPP SPL TS LRAD 1.jpg

On the shadow side their isn't really a difference with or without the rad file, on the sun side the TextureShadows command does seem to allow light to pass through the transparant parts of the foliage
And although the valve wiki sais this: ""ignorenormals - Ignores normals of vertex data to calculate lighting. This is extremely useful for foliage, and other thin types of vertex meshes" i think it still looks better without this option

But shadows are still black. It's as if the lighting method is correct this way, but too little ambient light gets to the shaded parts of the model.Next thing i'm gonna try is mess with the number of light ray bounces to see if this affects anything

EDIT

So again with SPP, SPL and TS WITH the lights.rad (and with no extra sky parameter):
https://dl.dropbox.com/u/234836/mapping/vrad parameters/SPP SPL TS LRAD 1.jpg

with SPP, SPL and TS WITH the lights.rad and with extrasky 32:
https://dl.dropbox.com/u/234836/mapping/vrad parameters/SPP SPL TS LRAD ExSky32 1.jpg

Number of bounces can't be manually set so i can't test that

 

This one is the best imo.
https://dl.dropbox.com/u/234836/mapp.../SPP sun.jpg

 

On the model itself maybe, but look at the ground, ... the trees cast no shadows
You can have a forest blocking all the sunlight, and the ground would still be as bright as in the open.

I'm now trying the bottom option of prop_static entities, which has to do with nocull, which i'm assuming the foliage has

Edit: sources

http://www.nodraw.net/2010/12/lighting-compile-options/
https://developer.valvesoftware.com/wiki/Advanced_Lighting (to the bottom of the page)
http://www.interlopers.net/tutorials/27738
http://facepunch.com/showthread.php?t=1208566
from valve wiki: "ignorenormals - Ignores normals of vertex data to calculate lighting. This is extremely useful for foliage, and other thin types of vertex meshes" (prop_static option)

 

Sorry for the double post, but i've been editing my two posts all day by now

I can't set the number of bounces. Wether i add the -bounce command or not hammer seems to choose the amount automatically (i tried -bounce 2 and -bounce 150, with standard being 100 bounces, and hammer effectively used 6 bounces every time)

I did use -extrasky 32
This means 32 times more rays are traced for indirect light (the -final command is the equivalent of -extrasky 16, standard is just 1). Vrad compile time went up from 5 minutes to 33

This did affect the cliffs, but NOT the trees:

Without extrasky: https://dl.dropbox.com/u/234836/mapping/vrad parameters/SPP SPL TS LRAD 1.jpg

With extrasky 32: https://dl.dropbox.com/u/234836/mapping/vrad parameters/SPP SPL TS LRAD ExSky32 1.jpg

Can a mod split this topic in the original map one and a topic about Source engine static prop lighting at post #18 ?

 

So this is with the props in a lights.rad and disableselfshadowing 1 with this compile parameter, I think it came out pretty good.

-final -lights empireslights -TextureShadows -StaticPropLighting -StaticPropPolys -game $gamedir $path\$file





The ground below the trees is just dark not pure black as it was without the lights.rad addition.

 

Definitely a lot better than the previous screenshots you posted yes

 

well running around another compile again there are still some of the more dense tree portions with black ground under them I might call it a day on the lighting though and just add some regular lights in those area with the ambient light's preferences.

 

compile times aren't really much of an issue, mine is about 6 min total on normal compile, 23 min with special final settings

 

Ya since orange box and finally getting vis_clusters in all the maps compiling hasn't been an issue like it was in the old days and the whole giant skybox was getting visleaf checked.

 

I remember the group compiling on networks. I hat 3 laptops and 2 PC's in our house hooked up to compile my maps. ^_^

If you take more than 10 minutes for a normal working compile, you are doing something wrong ^_^

 

Should be possible with staticproppolys yes

Unless ... i don't know anything about modelling, but if they were meant as dynamic props instead of static props, staticproppolys won't work of course.

But i'm pretty sure those palmtrees are and always have been meant as static props.

If the lightmapscale of the terrain below isn't low enough you won't see the shadows though, so the ground displacements can't be too large.

Edit: brutos ... aren't the palm trees in duststorm the same as the ones in arid, cause in arid i should've compiled them with shadows.
Not sure if it's the same palm tree though

 

yes brutos they should, also the textures they use should be changed over from UnlitGeneric so they can also have shadows. Now that Silk started this thread everyone is going to notice how lazy I have been when compiling maps!

Silk is also right about the lightmap scale on duststorm, it is actually probably too large to see anything at the moment.

 

Most of my maps have lightmap scales that are too big as well keef. Because of the amount of displacements i always have, i have to set them high enough that the map doesn't crash.

Every part that's completely in the shade gets at least a lightmap scale of 32 and often 64, so i can have a combination of 32 and 16 on well lit areas

 

Every map I've worked on is using the hint plane ceiling with the viscluster in the comm view area. Is there any map not updated?

 

I miss swaying tree's they don't do that anymore.