Glow light issue.
#1
Posted 30 April 2014 - 11:14 AM
This issue is odd because if the locomotive has ditch lights, the ditch lights will be affected first then the head light. The following screen shots are that of a locomotive with no ditch lights.
Edward K.
#2
Posted 30 April 2014 - 08:17 PM
This is related to this observation/post: "http://www.elvastower.com/forums/index.php?/topic/23895-question-about-lights-and-alphas/"
James, if you please, take a look at this because I think the solution is rather simple. There is an interaction with Z-bias and viewing distance as set in the menu program. The maximum viewing distance that can be set by the user and recorded in the registry is 10000 meters. It appears "automagically" that when the viewing distance is set to roughly half the maximum allowable, which is 5000 meters this problem "goes away". The downside is that far more tiles are being loaded and some machines may not be able to handle this, especially if the experimental parameter is used where the maximum LOD is always used.
The tedious minutiae is that with a max viewing distance less than 5000 meters, alphas tend to creep away from the model in question, but at max viewing distances greater than 5000 meters the opposite happens.
"This issue is odd because if the locomotive has ditch lights, the ditch lights will be affected first then the head light. The following screen shots are that of a locomotive with no ditch lights."
In reality this is model dependent, it could be that the model maker placed polygons for those lights further behind or forward relative to where alpha light has been located. So the level of "disappearance" will be different.
Edward, I have been sitting on the stopgap "solution" for this in the meantime for a few years now. Life gets in the way, so my apologies to people like you who have had to suffer with this mystery.
#3
Posted 30 April 2014 - 11:38 PM
Edward K.
#4
Posted 01 May 2014 - 12:19 AM
// Apply a small z-bias so that lights are always on top of the shape.
Out.Position.z *= 0.9999;
Edit: Screenshot showing properly working glow lights.
Edward K.
#5
Posted 01 May 2014 - 08:48 AM
#7
Posted 01 May 2014 - 10:14 AM
#8
Posted 01 May 2014 - 12:16 PM
edwardk, on 01 May 2014 - 12:19 AM, said:
Out.Position.z *= 0.9999;
I think this is probably fine but haven't checked the code in detail. I guess we'll see if there's any unexpected side-effects now it is committed (hopefully not). :dance3:
#9
Posted 01 May 2014 - 12:30 PM
edwardk, on 01 May 2014 - 10:14 AM, said:
Hopefully your issue is covered by this fix as well.
Edward K.
Edward,
I hope so too. I'll know the next time I build a headlight with lighted number boards :dance3:.
Thanks again.
Tim
Edit after installing 2206:
Well, x2206 undid the fix that Rick put forth with the issue of my firebox flicker "burning through" the tender in rearward views on steam locos. Even with the viewing distance set at 10,000m (at a cost in FPS), the flicker was present at a distance equal to about 15 car lengths (see here post #6 for screen shots of before). I'll roll back to 2205.
Tim
#10
Posted 01 May 2014 - 06:51 PM
Unfortunately, it is not that easy. A parameter will need to be passed from runactivity that "tells" LightGlowShader.fx what max view distance the user has indicated. So if the user selects 5000 meters, then the value Out.Position.z *= X, if the user selects 2500 meters the value Out.Position.z *= Y. Yes, damn me for not being specific about what the differentiation should be for X and Y. But the "fudge" factor (I hope I am wrong!) needs to be predicated on what the max view distance is when runactivity starts up. This is what I hinted at in this post: "http://www.elvastower.com/forums/index.php?/topic/23895-question-about-lights-and-alphas/page__view__findpost__p__149876"
Once such a value is passed to LightGlowShader.fx I hope there is enough "room" in the SM2 variables to allow for a small calculation of what the Z-Bias should be. Otherwise, this it will need to be calculated in runactivity (performance??) and passed as a float to LightGlowShader.fx.
This is why I indicated a "stopgap" measure as a fix.
Steve...aka "Rick" (how did that happen?......!)
#11
Posted 01 May 2014 - 06:56 PM
#12
Posted 01 May 2014 - 08:23 PM
Quote
#13
Posted 01 May 2014 - 11:52 PM
#14
Posted 02 May 2014 - 12:05 AM
Eldorado.Railroad, on 01 May 2014 - 06:51 PM, said:
That's not needed at all - this is the same fudge applied elsewhere. It may not be the right fudge. Unless you have code that works better that what we currently have, and your code needs the max view distance, I wouldn't suggest making such absolute statements. And if you do have code, please do share it. :dance3:
#15
Posted 02 May 2014 - 11:23 AM
I was hoping that something like this was not going to happen. If the situation is that bad then simply replace the LightGlowShader.fx file with the file before V2206. There is evidently more to this issue. James, it will be your call of course if you need to release a version w/o the z-bias addition.
Edward K.