Incorrect func_physbox shadows
Is there a way to make the shadows associated with these func_phyboxes less blatantly incorrect? As can be seen below, the shadows cast by func_phyboxes that are separate entities but physically touching are not continuous. I should note that everything with a wood texture in the image is a func_physbox; the ramp in the middle is made out of two separate func_physboxes. The light source is above and to the left of the player.
This problem is present regardless of the type of compile (normal or expert) used, although I only ran light.exe in expert mode, not bsp.exe or vis.exe (I used the "final both" setting for light.exe). Any suggestions of further things to try would be appreciated.
Are you using a light entity or env_projectedtexture?
Now with 100% more inline comments!
I'm using a light entity.
Huh. Well, first of all (and this might just be a typo) but I was under the impression that vrad.exe is used, not light.exe. I'm guessing you mean this, though, because upon checking VBSP and VVIS are referred to by name in the compile window whereas VRAD is referred to as light.
Anyway, I'm not sure what you mean by "I only ran light.exe in expert mode, not bsp.exe or vis.exe (I used the "final both" setting for light.exe)". My advice if you're running the different processes in different configurations somehow: Don't. If worst comes to worst and it isn't too obvious I believe there's an option in the func_physboxes to disable shadows.
Also, it might help (if you're willing) to post the VMF or just the room containing the weird lighting.
Now with 100% more inline comments!
Yup, I was using the names from the expert mode compile window; sorry for any confusion.
I'll try running all the compile processes using the "Full compile -both -final" option to see if that fixes it; I just assumed that to test final lighting/shadow aspects of the map I'd only need to run light.exe on this setting, but that assumption may well be incorrect. (What I previously did was run a normal mode compile for everything, then run only light.exe/vrad.exe in expert mode using the "Full compile -both -final" configuration.)
I'll give this a shot if running all the compilation processes using the same expert mode configuration doesn't work.
Thank you both for the suggestions; I'll report back once I've tried them.
Using an env_projectedtexture worked; the shadows are now accurate (see below). However, I'm not completely satisfied with the result, as there's a circle of brightness centred on the point that the env_projectedtexture entity is pointed at. Given that the room's light source isn't a spotlight (see somewhat unnecessary second screenshot below), this kind of behaviour isn't ideal.
I've tried aiming the env_projectedtexture down and adjusting its FOV to more accurately reflect the intended nature of the light source and, although this improves things, there's still a noticeable border where the projected texture ends. Any suggestions for better textures to use for the projection would be appreciated; something with a smooth gradient would work well. Alternatively, if there's a way to configure env_projectedtexture such that it adds shadows without adding light, that would be quite useful.
On a related note, I've noticed that the default material for env_projectedtexture (flashlight001) isn't listed in the Hammer materials browser. Could this mean there are potentially other textures suitable for projection that aren't listed?
Thanks for the list, Skotty. The flashlight001_intro texture looks like it might yield a better effect than the default.