Problems with -textureshadows

  • If you're asking a question make sure to set the thread type to be a question!

TheoF114

L1: Registered
Sep 10, 2013
33
234
I've been trying to compile with -textureshadows but I've run into a problem. VRAD is able to find my custom lights.rad file, but it isn't using any of the forcetextureshadows data inside it. The contents of my custom lights.rad (lights_theo.rad) is:
forcetextureshadow models/props_coalmines/wood_fence_short_256.mdl
forcetextureshadow models/props_coalmines/wood_fence_short_128.mdl
forcetextureshadow models/props_coalmines/wood_fence_short_64.mdl
forcetextureshadow models/props_coalmines/wood_fence_256.mdl
forcetextureshadow models/props_coalmines/wood_fence_128.mdl
forcetextureshadow models/props_coalmines/wood_fence_64.mdl
and during compile I get the message:
Valve Radiosity Simulator
4 threads
[Reading texlights from 'lights.rad']
[37 texlights parsed from 'lights.rad']

[Reading texlights from 'lights_theo.rad']
[0 texlights parsed from 'lights_theo.rad']

Using the compile parameters:
"-lights lights_theo.rad -staticproppolys -textureshadows -both -game $gamedir $path\$file"

I have lights_theo.rad in common\Team Fortress 2\tf

Can anyone help out? Thanks
 

henke37

aa
Sep 23, 2011
2,075
515
You do know that the file does two things right? Both defining materials that emit light and setting texture shadows. Note that the notice in the compile log only speaks of one of them. The one that you aren't using. As such your conclusion is likely based on a faulty interpretation of the evidence.
 

TheoF114

L1: Registered
Sep 10, 2013
33
234
OK, thanks for explaining what the compile log means, but shouldn't my props be casting more detailed shadows now?

FbWi4Od.jpg
 

henke37

aa
Sep 23, 2011
2,075
515
What's the lightmap scale on that surface? It is rather coarse by default.
 

iiboharz

eternally tired
aa
Nov 5, 2014
857
1,291
I remember YM was having the same issue, I think it's something to do with the texture.
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
Henke: don't be rude.

It's definitely specific to those props, I was having the same issue. The lights.rad correctly forces some props to use textureshadows but not this specific set of props. I don't know why. I thought it might be because the mesh is double sided, but it's not.
 

TheoF114

L1: Registered
Sep 10, 2013
33
234
Update/Sort of fix:

So -textureshadows works fine with the doomsday versions of these props but not with the coalmines version, no clue why.

CE3V3bq.jpg
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
Oh sorry, that's what I meant by the specific group of props, the coalmine versions, should have said that.

If you're willing to thoroughly investigate, please do, but for now I'd recommend making do with the doomsday ones, since it seems to be just the colamine props.
 

tyler

aa
Sep 11, 2013
5,102
4,621
What's the difference between them other than that? Maybe the Doomsday ones are fixes or something?
 

EArkham

Necromancer
aa
Aug 14, 2009
1,625
2,773
The chickenwire texture is different. The VTFs are the same (though the actual VTF refrenced in the doomsday props is the metal/chickenwire001 one, while the VTF for the coalmines one is located in props_coalmines/ -- they're identical vtfs just in different locations).

The VMT however for the coalmines version includes some differences:

Code:
	"%compilepassbullets" 1
	"$surfaceprop" "chainlink" (this is "metal" in doomsday)
	"$nodecal" 1
	"$nocull" 1

The coalmines prop has mesh work for the wireframe only facing one side, while the doomsday one has mesh work for both sides and no $nocull in the vmt. I can't confirm with 100% certainity because it seems like content inside the gcf is taking precedence when I try to make a new chicken_wire.vmt in materials/models/props_coalmines.

[EDIT] I'm not right about $nocull as I tested it with a custom prop that uses $nocull and it rendered shadows perfectly fine. Give me a few, and I'll test $nodecal

[EDIT2] Welp, I can't figure it out -- I copied everything from the vmt, and it doesn't appear to matter on my custom prop -- as long as I don't change $basetexture, it loads up the vtf and correctly and works out the texture shadows. So maybe the VTF is different somehow? They look identical when I open them both up, same file size, too... hrm, how curious.

Also, the doomsday fences are less than 1/2 the polycount of the coalmines ones! So it seems like using the doomsday ones is preferable for more than just the chickenwire issue.
 
Last edited:

tyler

aa
Sep 11, 2013
5,102
4,621
The chickenwire texture is different. The VTFs are the same (though the actual VTF refrenced in the doomsday props is the metal/chickenwire001 one, while the VTF for the coalmines one is located in props_coalmines/ -- they're identical vtfs just in different locations).

The VMT however for the coalmines version includes some differences:

Code:
	"%compilepassbullets" 1
	"$surfaceprop" "chainlink" (this is "metal" in doomsday)
	"$nodecal" 1
	"$nocull" 1

The coalmines prop has mesh work for the wireframe only facing one side, while the doomsday one has mesh work for both sides and no $nocull in the vmt. I can't confirm with 100% certainity because it seems like content inside the gcf is taking precedence when I try to make a new chicken_wire.vmt in materials/models/props_coalmines.

[EDIT] I'm not right about $nocull as I tested it with a custom prop that uses $nocull and it rendered shadows perfectly fine. Give me a few, and I'll test $nodecal

[EDIT2] Welp, I can't figure it out -- I copied everything from the vmt, and it doesn't appear to matter on my custom prop -- as long as I don't change $basetexture, it loads up the vtf and correctly and works out the texture shadows. So maybe the VTF is different somehow? They look identical when I open them both up, same file size, too... hrm, how curious.

Also, the doomsday fences are less than 1/2 the polycount of the coalmines ones! So it seems like using the doomsday ones is preferable for more than just the chickenwire issue.

Good work, thank you! The last bit about polycount reminded me that the coalmines rocks also have high polycounts, and as I remember, no LOD models, so I wonder if that's just indicative of whoever was making all those assets.
 

YM

LVL100 YM
aa
Dec 5, 2007
7,135
6,056
Given the vmt parameters there, if it's any of them, it'll be the %compilepassbullets
Other things have nocull and work fine. Can't imagine $nodecal and $surfaceprop have any effect on it.
 

EArkham

Necromancer
aa
Aug 14, 2009
1,625
2,773
The VTFs aren't 100% identical. The metal/chickenwire001 version has SRGB checked while the other one does not. Does that have any impact at all?

Maybe! I tried to swap out the VTFs at one point, but it seems to default to GCF content over local/custom so I kinda stopped caring, heh. I guess I could test it by compiling two test props, one that uses the coalmines vtf and the other using the doomsday one.

Occupied with other projects at the moment, but I'll report back if I end up doing that.