lighting problems

Some images in this post have been automatically down-sized, click on them to view the full sized versions:

hey guys i have one Q about some lighting problem that i have been having in my map. i make a light (brush) and use texture lighting (it looks great) but there is one problem, on the ceiling it makes a buncha crappy lighting things, see picture.

try recessing it into the actual ceiling....if you wish to use texture lighting only in this instanc....

my 2 cents....

Doc Brass... :dodgy:

it looks like a classic case of face splitting. turn the light fitting into a func_wall, and that should stop it from happening.

thatd work as well, prolly up yer r's a bit tho....

Doc B... :dodgy:

Why would it up your r's to stop face splitting?

another option is to place your lights one unit away from the ceiling.

thatd work as well, prolly up yer r's a bit tho....

Doc B... :dodgy:

No it won't. The lighting artifacts come from additional faces being created by intersecting world brushes. making the lights into entities will prevent said face splitting and allow the ceiling to split normally in far fewer (or at least a few fewer) polys than before.

i understand what happens....agreed about the face splitting.... and, youd know better than me.....just seems that about every time i use a func_wall to aleviate similar problems, they tend to up the r's a bit....i didnt say itd send em thru the roof, maybe its the quantity of func_walls then that are used....thats why i either recess them, or put them in as func_illusionary....also keeps ya from getting hooked up on em, especially along the walls.....or it could be that i just dont map worth a f**k either.... :wink:

Doc Brass... :dodgy:

Doc's right about the general increase in r's when you use func_walls, as they're 'visible' from everywhere in the map. i suppose my advice was a knee-jerk reaction when i seen face-splitting. /me bad

TB's solution of moving the brush down by 1 unit would be a better solution where the player can't see the space.

though the corridor does looks plain enough to accomodate some of Doc's recessed wall/ceiling lights [and maybe more], without any danger of the r's getting out of hand.

Whether you use func_walls or func_illusionaries makes no difference in how they are rendered - func_illusionaries are just non-solid func_walls - so the r_speeds won't change dependant on which you use.

Doc's right about the general increase in r's when you use func_walls, as they're 'visible' from everywhere in the map. i suppose my advice was a knee-jerk reaction when i seen face-splitting. /me bad

No, that's not true. Your first instinct was right. func_walls are not always rendered. If you have a small portion of a very large func_wall visible, or just a large func_wall in general, VIS often mishandles these and does render them at points where they shouldn't be, but properly constructed func_walls cull from visibility just as any other world geometry - and the above behavior applies to any brush entity, not just func_walls.

Failsafe was telling me something about Bounce lighting.

ok first...lets be clear.....i am NOT trying to be argumentative here....im just going from my own personal experience...this came up a while back, and i just happened to have a map with a few func_walls in it that i used as an example of what NOT to do (anyone remember that??) ie, too many func walls up the r's...actually it was an example of misuse of them...granted there were alot of them, but the general premise was exactly that....what NOT to do....hense:

? posted by <a href=""http://www.snarkpit.com/users.php?name=Dr Brasso"">Dr Brasso</a>

they tend to up the r's a bit....i didnt say itd send em thru the roof, maybe its the quantity of func_walls then that are used

so...

i threw up some screens where the r's had jumped by 200, and left it as an example.....

anyway, thats just my two cents....i concede to the "elder statesmen" of the site....and yes....TB's solution of the 1 unit down is prolly the best.....wtf do i know anyway.... :heee:

Doc Brass... :dodgy:

Vash said:
Failsafe was telling me something about Bounce lighting.

It's just a compile parameter in RAD. hlrad.exe -bounce

Basically, it determines how many "bounces" RAD will calculate from the light. (Like light rays bouncing off walls, etc.) Essentially it has the effect of smoothing out lighting. High bounce numbers don't really do anything - a value of 1-4 usually works best.

KungFuSquirrel said:

Doc's right about the general increase in r's when you use func_walls, as they're 'visible' from everywhere in the map. i suppose my advice was a knee-jerk reaction when i seen face-splitting. /me bad

No, that's not true. Your first instinct was right. func_walls are not always rendered. If you have a small portion of a very large func_wall visible, or just a large func_wall in general, VIS often mishandles these and does render them at points where they shouldn't be, but properly constructed func_walls cull from visibility just as any other world geometry - and the above behavior applies to any brush entity, not just func_walls.

Andrew's quite right here. A func_wall is only visible if you can see it directly, though occasionally Half-Life has an odd habit of having faces rendered through solid walls, but that goes for all brushwork/entities.

Too much of any entity will screw over your r_speeds, it's a fact of life. But in this case, you could do anything from func_wall'ing your light or just taking it one unit away from the cieling.

P.S. As an unrelated comment, having bounce at 0 with really intense lighting produces pitch black shadows, an AMAZING effect, especially in a firefight.

I've never adjusted the bounce value, though I guess the higher the number, the more prevalent and softer the light is. My HLRAD compile settings are usually just -extra.

Just slap the NULL texture on the sides of func_illusionaries and func_walls that you don't see. It removes the face splitting AND it won't render that underside texture which is sometimes does.

KungFuSquirrel said:
properly constructed func_walls cull from visibility just as any other world geometry

i've honestly found that not to be the case. i realised a long time ago that it was always func brushes that were rendered through a sky box, and when i found out about the wireframe view (quite recently), i was horrified to see every func_brush in my map being drawn, whether it was through sky or through solid world architecture.

Full VIS anyone?

yes gorb, with a -full vis compile.

Then your map must be built in a way that those areas are visible whether they're solid or entity.

nope

Yes. KFS is right. Func_walls cull from visibility unless you make them REALLY big. Then VIS doesn't really know what to do with them and just makes it visible from lots of places.

Func_walls will cull but if you don't have a lot of visblocking in one area they tend to show up in others. I had a lot of windows on a building once that always showed while the walls did not. Just experiment, use full vis, keep entity sizes small, make sure to visblock and try using HINT brushes when all else fails.

sorry people, it was my mistake.

when i used gl_wireframe, and seen all of the func_walls that were in places far removed and visblocked, i didn't realise that they were all grouped. i have a [bad] habit of tying brushes to existing entities. i must remember not to spread my groups so far apart.

sorry again.