Shouldn't the trees in the middle have some bigger shadows? Other than that, good job, looking forward to play it.
The dead pines? It would be better yes, but a narrow trunk won't cast a visible shadow on large surfaces, and i can't increase the lightmapscale any further. When i start adjusting all the trees (to fit the ground perfectly) i'll try to see if i can mimic a tree shadow with the lightblock entity. Though chances are the map will crash, but who knows.
Just a thought: couldn't you have them as prop_dynamic_override entities? The shadowlod should still be in there, unless $propstatic in the qc disables it.
I'll give it a try soon Btw Rappe, i'm currently doing a full compile (was too curious to check the performance with the new trees to wait). It should be ready within the next hour or so. I also decreased some of the visibility draw distances of the trees, so i'm expecting a noticable increase in performance. I'll edit this post with the results, hopefully this evening.
What is your Sunspreadangle set at? It might be making your shadows far less defined than they should be. The entity says 5 is a good starting value but really you're best off with 0 to 2.
I just closed everything down to go to bed, but i'll check on friday. And Rappe, surprisingly i get about 10 fps less on the new map, but let's say that is because of the entities i added, cause i wouldn't know how your trees could be more expensive with the same res texture and less triangles. Fps on the old map ranged from 100 to 200, and on the new map from 90 to 190. That's good enough, as i'm running on a pc that's four and a half years old. Main thing bothering me is that i haven't yet found a way to make the shadows cast by the trees less dark. I'm starting to think the vrad parameters can't be tweaked or fooled in any way. http://dl.dropbox.com/u/234836/mapping/emp_chain/emp_chain_210120120007.jpg
where is the problem, this looks quite good if you ask me?! the grass sprites look too bright thats all ... but well maybe the picture doesnt really show it ...
Valve trees do that too, honestly. The only difference is that their branches are placed a little more sparsely giving the branches some extra light to breathe in (though it doesn't look as good). The problem is that alphatest textures are opaque or transparent, which doesn't perfectly represent the nature of leaves. Your options aren't good. (I'm going to test with mostly translucent leaves just to see what happens. Though, even if that works, you'd have to swap out the textures for every compile.) (What happens is, VRAD doesn't care. No love for translucency texture shadows? However, ghostly-translucent trees are a trip.)
It's the middle of the day, lack of direct sunshine doesn't mean it's completely black. It looks wrong from under there, and odd when looking to it from a distance.
The branches (almost) all share the same alpha texture, but the branches all being distributed randomly-ish across the trunk makes the chance that a light ray will pass through all the overlayed alphas very small. Edit: But the same should ring true for Ep2 trees, or any other tree. I'm trying to reproduce on a small testmap, full final compile, hdr, staticproppolys and textureshadows. But I can't seem to get it as dark.
It is the same for the Ep2 trees, don't worry about that. Like i said somewhere before, this is no model problem. The shadows are cast correctly on a correctly made model. The problem is that in real life on a bright day there's always loads of diffuse light hitting places that are not hit by direct sunshine. So trunks, roots, ground and foliage always remain very visible, just not shiny bright. They certainly don't get anywhere near complete black. To get that shade effect in source (which might be possible) you'd have to set vrad parameters to use a massive amount of sun rays with a very high number of bounces so they can get to all those places. But even getting close would be impossible for pretty much any currrent day hardware, which is why most "modern" game engines these days use various techniques and tricks to make light and shadows look equally real by ... cheating really. If the source engine has something similar, i haven't found it yet. Then again, playing HL2 Episode 2, i can't remember seeing green/black trees. I should check that out. But for at least a week i won't have much time anyway, and in worst case i just leave it dark as it is. -both -final -StaticPropPolys -TextureShadows -StaticPropLighting That last parameter is used so that parts of a model can be in shadow, and the others not. Standard method i think is that a static_props is either completely lit, or completely in shadows. I haven't tested it without that parameter though ... if you happen to have a screenshot of your compile without it ...
silk : simple approach, but could you not add a low-level ambient light in hammer to simply reduce the effect of limited light getting under the trees ? if you were to do a sample test small scale of the same light setup (as rappe was describing) you could probly get the 'right' ambient settings figured out and just drop those in place wherever clump of trees are...plus you can easily save a vmf simply containing these/this light entity for future usage in dark areas.
Not sure about this but maybe the ambient light on the trees is determined by the shadow_control and not the light_environment?
Shadow control hasn't been touched, the color is mid grey. Also i checked the sunspreadangle, and it was set to 0 I also checked the previous version of the map to compare: Old trees: http://dl.dropbox.com/u/234836/mapping/emp_chain/emp_chain_130720110005.jpg New trees: http://dl.dropbox.com/u/234836/mapping/emp_chain/emp_chain_210120120007.jpg I'm going to check all my todo files to see if i did change something i have already forgotten to explain the difference. Edit: This is odd: old city: http://dl.dropbox.com/u/234836/mapping/emp_chain/emp_chain_130720110008.jpg new city: http://dl.dropbox.com/u/234836/mapping/emp_chain/emp_chain_210120120004.jpg Only light changes are: - Sun direction from the right (180°) instead of the left (0°) - Brightness lowered from 480 to 450 - HDR brightness lowered from 380 to 355 - Both ambient levels have stayed the same For example this is the change caused by the altered values in the rest of the map: old map: http://dl.dropbox.com/u/234836/mapping/emp_chain/18.jpg new map: http://dl.dropbox.com/u/234836/mapping/emp_chain/emp_chain_210120120000.jpg
Only in the city for some reason. The rest of the map is lit correctly. I'm hoping for some mistake during compile, cause this is too strange.
