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.
Posted by GoD on Fri Dec 19th at 5:55pm 2003
Posted by Dr Brasso on Fri Dec 19th at 6:02pm 2003
try recessing it into the actual ceiling....if you wish to use texture lighting only in this instanc....
my 2 cents....
Doc Brass...
Dr Brasso
member
1878 posts
198 snarkmarks
Registered: Aug 30th 2003
Location: Omaha,NE

Occupation: cad drafter
Posted by fishy on Fri Dec 19th at 6:02pm 2003
it looks like a classic case of face splitting. turn the light fitting into a func_wall, and that should stop it from happening.
Posted by Dr Brasso on Fri Dec 19th at 6:05pm 2003
thatd work as well, prolly up yer r's a bit tho....
Doc B...
Dr Brasso
member
1878 posts
198 snarkmarks
Registered: Aug 30th 2003
Location: Omaha,NE

Occupation: cad drafter
Posted by Tracer Bullet on Fri Dec 19th at 7:22pm 2003
Why would it up your r's to stop face splitting?
another option is to place your lights one unit away from the ceiling.
[addsig]Tracer Bullet
member
2271 posts
367 snarkmarks
Registered: May 22nd 2003
Location: Seattle WA, USA

Occupation: Graduate Student (Ph.D)
Posted by KungFuSquirrel on Fri Dec 19th at 8:47pm 2003
| ? quote: |
| thatd work as well, prolly up yer r's a bit tho....
Doc B...
|
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. [addsig]
KungFuSquirrel
member
751 posts
345 snarkmarks
Registered: Aug 22nd 2001
Location: Austin TX

Occupation: Game Design, LightBox Interactive
Posted by Dr Brasso on Fri Dec 19th at 9:34pm 2003
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....![]()
Doc Brass...
Dr Brasso
member
1878 posts
198 snarkmarks
Registered: Aug 30th 2003
Location: Omaha,NE

Occupation: cad drafter
Posted by fishy on Sat Dec 20th at 10:07am 2003
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.
Posted by ReNo on Sat Dec 20th at 2:16pm 2003
ReNo
member
5457 posts
933 snarkmarks
Registered: Aug 22nd 2001
Location: Scotland
Occupation: Level Designer
Posted by KungFuSquirrel on Sat Dec 20th at 2:57pm 2003
| ? quote: |
| 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. [addsig]
KungFuSquirrel
member
751 posts
345 snarkmarks
Registered: Aug 22nd 2001
Location: Austin TX

Occupation: Game Design, LightBox Interactive
Posted by Vash on Sat Dec 20th at 3:16pm 2003
Failsafe was telling me something about Bounce lighting.
[addsig]Posted by Dr Brasso on Sat Dec 20th at 4:52pm 2003
Dr Brasso
member
1878 posts
198 snarkmarks
Registered: Aug 30th 2003
Location: Omaha,NE

Occupation: cad drafter
Posted by Dr Brasso on Sat Dec 20th at 4:52pm 2003
Dr Brasso
member
1878 posts
198 snarkmarks
Registered: Aug 30th 2003
Location: Omaha,NE

Occupation: cad drafter
Posted by Dr Brasso on Sat Dec 20th at 5:00pm 2003
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 Dr Brasso
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....
Doc Brass...
Dr Brasso
member
1878 posts
198 snarkmarks
Registered: Aug 30th 2003
Location: Omaha,NE

Occupation: cad drafter
Posted by Campaignjunkie on Sat Dec 20th at 5:27pm 2003
| ? posted by Vash |
|
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.
[addsig]
Campaignjunkie
member
1309 posts
291 snarkmarks
Registered: Feb 12th 2002
Location: West Coast, USA
Occupation: Student
Posted by Cassius on Sat Dec 20th at 5:28pm 2003
| ? posted by KungFuSquirrel | ||
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.
Posted by Hornpipe2 on Sat Dec 20th at 7:25pm 2003
Hornpipe2
member
636 posts
94 snarkmarks
Registered: Sep 7th 2003
Location: Conway, AR, USA

Occupation: Programmer
Posted by Gorbachev on Sat Dec 20th at 8:32pm 2003
Posted by fishy on Sat Dec 20th at 9:52pm 2003
| ? posted by KungFuSquirrel |
| 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.
Posted by Gorbachev on Sat Dec 20th at 11:12pm 2003
Snarkpit v6.1.0 created this page in 0.0208 seconds.



