[edwardk]

This issue has been posted under open rails tracker already, but I am going to bring it up here in case someone here understands the issue. As far as I know, this issue is only affecting glow lights(Type 0) utilized on trains. Either engine or wagon. If you switch to external camera view 2 and move your camera so that you are directly in front of the locomotive and up close, all lights will appear normal when turned on, but at some point as you are moving away from the locomotive, the glow light will essentially change. It appears to go out, but part of the glow light is still visible. By placing the glow light at an angle while moving the camera back will bring the light back, but at one point, you will lose it completely. At this point, you can still see the outline of the lightglow texture if viewing the locomotive at an angle.

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.

Attached thumbnail(s)

• 

[Eldorado.Railroad]

Edward,

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.

[edwardk]

Regarding the possible solution, I have already tried setting the maximum viewing distance along with using the experimental setting to extend the maximum viewing distance and none of them worked. Of course this was before I knew about the other post.

Edward K.

[edwardk]

I do believe I found the fix for this nagging issue and it involves both LightGlowshader.fx and SceneryShader.fx :yahoo: While looking in the SceneryShader.fx file, I came across this line below. I took this line and pasted it into the Vertex Shaders block found in the LightGlowShader.fx file. Since the topic of z-bias was mentioned, I figured what the heck and guess what, it worked. I will run more tests to make sure everything else is fine. Unless James knows something that I do not and this fix is breaking something else.

// 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.

Attached thumbnail(s)

• 

[timmuir]

This is a promising breakthrough. Thanks, Edward and Rick.

[edwardk]

Fixed in V2206.

Edward K.

[edwardk]

timmuir, on 01 May 2014 - 08:48 AM, said:

This is a promising breakthrough. Thanks, Edward and Rich.

Tim,

Hopefully your issue is covered by this fix as well.

Edward K.

[James Ross]

edwardk, on 01 May 2014 - 12:19 AM, said:

// Apply a small z-bias so that lights are always on top of the shape.
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:

[timmuir]

edwardk, on 01 May 2014 - 10:14 AM, said:

Tim,

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

[Eldorado.Railroad]

From 01 May 2014 - 12:16 PM:

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:

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?......!)