HDR Flickering?!

[A Boojum Snark]

Interesting, I actually did run around it and couldn't see the flicker, and I do have an nvidia. Figured it was nothing since others were seeing it. Though this still doesn't explain why it hasn't come up in another map...

 

[IrishTaxIDriver]

I have absolutely no idea, I'm talking with Valve now and they said they don't see it either. My hunch now is that its only happening on ATI cards, BUT that still doesn't explain why t6 doesn't have it and t7 does.

Here are some getpos that show specifically where I'm getting them.

setpos -3258.833984 312.407867 263.969666;setang 2.002001 -1.539999 0.000000

setpos -3257.744873 352.902405 263.969666;setang 2.002001 -1.539999 0.000000

The blue spawn spot and the ledge. Strafing between those two spots causes it.

setpos -1881.607422 116.749626 159.849731;setang -12.782001 -33.263981 0.000000

setpos -1881.607422 116.749626 159.849731;setang -15.708003 -29.259991 0.000000

Aiming at the white brick building.

setpos -202.937622 -98.394867 320.969666;setang 2.618002 -1.848010 0.000000

setpos -121.966064 -101.007423 320.969666;setang 2.618002 -1.848010 0.000000

Moving foreward in the mill attic.

EDIT: For anyone who can't see it, FLOOR_MASTER recorded a video of it happening for me, he has an nvidia card so that theory may be out the window. I've added this video and the getpos to the rap sheet on the first page.

http://dl.dropbox.com/u/53150/mill-flicker.mp4

 

[IrishTaxIDriver]

Some new information. I pull the point entities from t6 and put them in t7 and it still occurs, but theres a catch.

When I find a spot where it bugs out, if I tab out then tab back in, its gone. It works normally. This has worked on every spot I've found so far.

EDIT: Its even working on B1. WHATS THE DEAL?!

EDIT #2: It seems to not happen in that spot again until another spot triggers the effect again. This has gotta be an HDR bug at this point.

 

[A Boojum Snark]

Have you tried changing light values? Just something small, +10 here, -10 there, just to get the majority of the calculations doing different math and such. Could be a quirk in vrad.

 

[IrishTaxIDriver]

I'll give it a shot, but none of this answers the lingering question of why it doesn't happen at all on t6.

 

[Snacks]

Not quite sure whats going on, but here's what I noticed.

For me, it appears to change brightness based on if the water could be seen in the view frustum.

You have two brushes of expensive water next to each other at different heights.

In t7 you switched to water_2fort_expensive from water_2fort in t6.

And switched to water_2fort_skybox_dx80 from water_2fort.

 

[IrishTaxIDriver]

Not quite sure whats going on, but here's what I noticed.

For me, it appears to change brightness based on if the water could be seen in the view frustum.

You have two brushes of expensive water next to each other at different heights.

In t7 you switched to water_2fort_expensive from water_2fort in t6.

And switched to water_2fort_skybox_dx80 from water_2fort.

Yeah I talked about that in another post. Thats not the same thing, I already fixed that one. The HDR bug still happens on b1, where I've fixed that water issue.

 

[Snacks]

Tried a quick test, I made a brush with 2fort_water_expensive, showed the same brightness problem. I changed it to water_2fort, no more brightness changes.

 

[IrishTaxIDriver]

Lemme switch the water and see what happens.

 

[IrishTaxIDriver]

Looks like we have a winner. I used 2fort_water_expensive, which must be a no-no.

 

[tyler]

9:34 PM - yyler <3: is there a way to even tell what you shouldnt use
9:34 PM - yyler <3: or do you just have to know
9:34 PM - A Boojum Snark: You should only use water with one underscore
9:34 PM - A Boojum Snark: e.g. water_<nameofwater>
9:34 PM - A Boojum Snark: if it is water_<nameofwater>_<somethingelse> leave it alone.
9:34 PM - A Boojum Snark: It is either broken or a supporting texture.

 

[IrishTaxIDriver]

Yeah, did not know that. Oh well, I do now.