-staticproplighting and why NOT to use it

Icarus

aa
Sep 10, 2008
2,245
1,210
-staticproplighting effectively doubles file sizes. The other settings, -staticproppolys -textureshadows -final have no bearing on the file size and are OK to use!

I've always wondered how some maps get massive file sizes despite a rather small amount of custom content, so I set out an experiment to discover the truth.

I've hypothesized that it was something in Youme's VRAD compile settings that greatly increased the filesize.

First, I cordoned a room of pl_waste that has lots of chain link fences and payload tracks. The compile used hammer's Normal compile settings (-both). Then, I compiled the same map with youme's settings (-both -final -staticproppolys -staticproplighting -textureshadows), one effect at a time. These are my findings:

Setting | Filesize
Normal|4910KB
Youme| 8877KB
-final|4910KB
-staticproppolys|4910KB
-staticproplighting | 8877KB
-textureshadows|4910KB

WOW! That's nearly DOUBLE the file size!

Personally, I don't really notice if a certain prop has just the right lighting in certain places. What I do notice is the sometimes ridiculous file sizes some maps come to be. Not for any good reason, IMO, to double the file size. We are not Valve, so we cannot make downloading mandatory. We must do our best to keep our maps at a reasonable size.
 
Last edited:

Altaco

L420: High Member
Jul 3, 2008
484
120
Yeah, if something's got nasty shadows just disable them.
 
Last edited:

Icarus

aa
Sep 10, 2008
2,245
1,210
IIRC, -staticproplighting only affects the lighting on the prop itself. It is -staticproppolys' job to cast shadows onto the world
 

Nineaxis

Quack Doctor
aa
May 19, 2008
1,767
2,820
The problem is with outdoor areas, where 90% of props have their origins inside displacements (and therefore are near pitch black in a very bright environment).
 
Aug 19, 2008
1,011
1,158
The problem is with outdoor areas, where 90% of props have their origins inside displacements (and therefore are near pitch black in a very bright environment).

There is a simple trick to correct that, you place an info_lighting near the opject that is badly lit due to being inside a displacement or sort, give the info_lighting a name and set the objects lighting origin to that info_lighting


edit: corrected
 
Last edited:

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
OK so its nearly double the filesize, but its 100% worth it. (well, unless your map looks rubish to begin with...)
 

GrimGriz

L10: Glamorous Member
Jan 2, 2009
774
133
OK so its nearly double the filesize, but its 100% worth it. (well, unless your map looks rubish to begin with...)

Anyone want to take the time for some comparative screens?
 

Icarus

aa
Sep 10, 2008
2,245
1,210
Personally, I believe the costs outweigh the benefits. Especially if it causes your map to be +100MB
 
Last edited:

Sgt Frag

L14: Epic Member
May 20, 2008
1,443
710
Honestly in both of those cases I think that there are work arounds that are better overall than the expensive lighting.

1- the metal sheets. True, they do look somewhat better with expensive lighting.
But the shadows on the backside make them look like crap imo anyway. So to double the filesize to make one side of them look better isn't worth it.
You also mention Youme that info_lights are broken but they have been working great for me (maybe they were fixed at some point?)
Anyway. I believe the best overall solution for those pieces would just be to use an info_lighting outside of the wood planks in a spot where they get light but not overly dark or bright.
They wont have the good shadows but wont have the bad either. And much better file size.

2-The chainlink. Yeah, those shadows look great. But that's the texshadows and lightmaps scale isn't it? Does that have to do with the expensive lighting?
In any case, it depends more on the situation. For example having a chinlink fence right in front of a wall seems a little odd. ( I know it's just for the example but...)


But to me that's still one of those optimizing things, as a map maker you gotta weight the benefits and the negatives.
I feel that the shadows are a smaller benefit compared to the larger negative of double file size when most players wont notice the shadows in game but all players will notice the large file size and long DL times.
 

Icarus

aa
Sep 10, 2008
2,245
1,210
-staticproplighting only affects the lighting on the props themselves. It has no bearing over the chainlink fence effects.
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
Yeah thats the texture shadows one and that wont change filesize at all, but it will make the shadows look better at a cost of a longer compile time.
 

JoshuaC

L420: High Member
Sep 2, 2008
444
164
arena_watchtower_b4 - fast compile HDR/LDR no cubemaps = 13.3MB
arena_watchtower_b4 - final compile HDR/LDR -staticproppolys -staticproplighting no cubemaps = 14.8MB
arena_watchtower_b4 - final compile HDR/LDR -staticproppolys -staticproplighting built cubemaps and packed materials = 17.3MB

Makes quite a visual difference. Personally I've never seen it double the file size.

I was always under the impression that lower lightmap scales = bigger file size.
 
Last edited:

Nineaxis

Quack Doctor
aa
May 19, 2008
1,767
2,820
I think the extra lighting settings add the polish a map needs. Maybe the visual difference isn't blatant and obvious, but it is there, and really makes a map look much nicer.
 

Icarus

aa
Sep 10, 2008
2,245
1,210
arena_watchtower_b4 - fast compile HDR/LDR no cubemaps = 13.3MB
arena_watchtower_b4 - final compile HDR/LDR -staticproppolys -staticproplighting no cubemaps = 14.8MB
arena_watchtower_b4 - final compile HDR/LDR -staticproppolys -staticproplighting built cubemaps and packed materials = 17.3MB

Makes quite a visual difference. Personally I've never seen it double the file size.

I was always under the impression that lower lightmap scales = bigger file size.

It probably affects larger maps more than smaller ones, so arena should be fine.

Or, at least, maps with lots of props.
 

dirtyminuth

L5: Dapper Member
Nov 5, 2007
221
15
Has anyone taken the time to explore the last three, vertex lighting-related fields in prop_static and how they might affect file size? Exploring the "Disable Vertex Lighting" option might be of more notable interest.

If there is an option to selectively control which props receive more accurate lighting, it could go a long way in cutting down on file size.
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
Has anyone taken the time to explore the last three, vertex lighting-related fields in prop_static and how they might affect file size? Exploring the "Disable Vertex Lighting" option might be of more notable interest.

If there is an option to selectively control which props receive more accurate lighting, it could go a long way in cutting down on file size.

Well yes, those last three options alter how rad does lighting, if you set most of your props to disable vertex lighting then you're filesize is going to be smaller