[Eldorado.Railroad]

Way.....back in x1587 this is the way dynamic shadow maps looked like:

Note the nice saturation of the tree in the foreground.

Later...in x1674 (and any version since), black triangles (circled in red) began to appear at viewing certain angles:


Note how the tree shadow is now more "watered down" at the base from where it was in x1587.

A look at the SVN log gives the two possible changes that occured to dynamic shadows:
1600 Mon May 06 17:46:22 EDT 2013 twpol Bug 1098600 - fix for shadows being quite faint.
1597 Mon May 06 07:28:09 EDT 2013 twpol Bug 1098600 - fix for shadow inclusion test and shadow map center calculation.

I have spent quite a few hours with ShadowMap.fx and SceneryShader.fx and I have not been able to eradicate the black triangles. These are only caused when the user sets:
ShadowMapCount = (user set) 2 (or more)

For illustration purposes (and personal preference):
ShadowMapDistance = (user set) 450

Note that changes were made to both of these files in x1597 as per the SVN log:
/trunk/Source/RunActivity/Viewer3D/RenderFrame.cs
/trunk/Source/RunActivity/Processes/RenderProcess.cs

Testing CSM in a valley route emphasizes the problem of the black triangles. You will have to hunt right and left in any camera view to see them, but once in view they do not move their position until the "sun" moves. AFAIK they are visible at some angle throughout the "simulator day" but note that the screen captures are at about 12:00pm. Note the direction and position of the black triangles relative to all the other "wanted" shadows.

Even the most recent versions of OR have these artifacts. Thanks for "unXNBing" the .fx files as it is for easier to take a good look at their contents and have the JIT compiler do its magic at runtime.

Is there a way to revert back to the "old" way of generating shadows?

Many thanks.

[James Ross]

Eldorado.Railroad, on 16 February 2014 - 09:10 PM, said:

Is there a way to revert back to the "old" way of generating shadows?

No. Either identify the problem, so we can fix it, or wait for someone else to do so.

I've seen the black around the edges too, and it's not being ignored, but shadows are a complex system of projections and culling.

[captain_bazza]

I concur with Steve re the shadow 'edge artifacts, Unfortunately I cannot pin them back to the originating version, but they have existed for many versions back. My videocard is an Nvidia. Steve has put in many hours of hard yacca researching this 'bug' and I'm certain his effort is greatly appreciated by those of us who don't have the teccy expertise to delve into the murky bowels of OR's code.

Cheers Bazza.

[dennisat]

Eldorado.Railroad, on 16 February 2014 - 09:10 PM, said:

... I have not been able to eradicate the black triangles. These are only caused when the user sets:
ShadowMapCount = (user set) 2 (or more)
...

I found very early on with OR (when V0.9 was first released?) that I got very weird effects with the default shadow settings. For instance, hard lines across the scene, areas of light and not so light (not really shade) flicking back and forth.
After some experiment I settled on the following which with my limited range of routes still gives very acceptable results:

ShadowAllShapes = (user set) True
ShadowMapBlur = (user set) False
ShadowMapCount = (user set) 1
ShadowMapDistance = 1000
ShadowMapResolution = (user set) 6144

My graphics card is an Nvidia GTX640 with 1GB of memory, which is fairly modest by today's standards.
I went to X2021 recently and didn't like the effects Textures Flickering/Shimmering so I reverted to X2012. I will find the time to try something from X2022 onwards in the near future, I hope.

Dennis

[James Ross]

Eldorado.Railroad, on 16 February 2014 - 09:10 PM, said:

I have spent quite a few hours with ShadowMap.fx and SceneryShader.fx and I have not been able to eradicate the black triangles. These are only caused when the user sets:
ShadowMapCount = (user set) 2 (or more)

The black marks at the edge are where two levels of the cascade meet. That's why you won't see them when you use just 1 shadow map level.

• Either, the projection test in the shader is wrong, so the ground is using the wrong shadow map level.
  
• Or, the shadow map culling is wrong, so there are elements missing from that shadow map level.

I think the former is more likely, with the current code, but it'll take time to figure out. If you want to help diagnose the issue, please use the current code or you may find fixes are no longer relevant/apply to the code.

[Eldorado.Railroad]

From 17 February 2014 - 05:20 AM:

If you want to help diagnose the issue, please use the current code or you may find fixes are no longer relevant/apply to the code.

Are you referring only to "changes" in the .fx files here? These are the only files I have been looking at and modifying.

Thanks.

[James Ross]

Eldorado.Railroad, on 17 February 2014 - 08:35 PM, said:

Are you referring only to "changes" in the .fx files here? These are the only files I have been looking at and modifying.

I could not tell from your original post what you had been modifying nor what versions you had used when doing so. The version numbers you did mention were old and I want to make sure that any modifications you make to fix issues is done with the latest code - otherwise there is a risk it'll be unusable.

[Eldorado.Railroad]

From 18 February 2014 - 12:43 AM:

I could not tell from your original post what you had been modifying nor what versions you had used when doing so.

From the screen captures references in the O/P I looked at x1587, x1674 which I labeled. I looked at a whole bunch of compiled eXperimentals that your personal website provides (very smart and very helpful, thanks James). What is getting in the way is that there are no static snapshots of source code to look at and unfortunately time was an issue to do so with SVN some months back. I have been examaning and modifying more recent version of .fx (latest is x2027...I think), sorry if the term "recent" was not explicit enough in the O/P.

It would be very helpful to have source code snapshots just prior to x1597 and right after x1600. I spent several hours last night looking at the annotations for several source files on SVN and unfortunately some changes that were indicated in several .cs for x1597 have now vanished. Nobody is pretending that the solution is to revert back to just prior x1597 but what can be observed is that the triangles in the FOV were not there, and the shadows were more saturated in x1587. Whatever fixes in x1597 and x1687 to resolve bugs seem to make the results "less desirable" afterwards. I have taken the time to go through a great many compiled code snapshots on your website and ALL have the same problem. The release from .XNB occurred somewhere late in the x1500 series of compiled releases which makes looking at the .fx files from that time..."difficult".

Would you have any relevant code snapshots to look on your HD that I could use to track down the source of the shadow map artifacts?

[James Ross]

Eldorado.Railroad, on 19 February 2014 - 07:36 AM, said:

Would you have any relevant code snapshots to look on your HD that I could use to track down the source of the shadow map artifacts?

Subversion has all the history and is publically accessible; there is no need for code snapshots at all.

But I think you've misunderstood the problem here. We have added significant new features, such as cascaded shadow maps, which have many benefits but also currently this black triangle bug. What you appear to be suggesting is that we remove the entire feature. You're welcome to help fix the black triangle bug but simply reverting the entire change that added it (that added the whole new feature) isn't going to be accepted.

[Eldorado.Railroad]

From 19 February 2014 - 08:18 AM:

James Ross wrote:
Subversion has all the history and is publically accessible; there is no need for code snapshots at all.

Yes, that is exactly what I have been accessing on the SVN server. However, I have not had success in backdating/reverting to a specific eXperimental version of OR, lock, stock, and barrel. This would help me do comparisons in both results and the code, which would help solve problems.

From 19 February 2014 - 08:18 AM:

James Ross wrote:
But I think you've misunderstood the problem here. We have added significant new features, such as cascaded shadow maps, which have many benefits but also currently this black triangle bug. What you appear to be suggesting is that we remove the entire feature.

AFAIK, and could observe, we have had CSM for a very long time, why else would we have the capability of using 4 shadow maps? So it has been around for several years in OR. I am not suggesting that we remove the entire feature, hardly. Why would you assume that? What I am suggesting is that with the versions discussed in the O/P that something has been added in the fixes, namely the triangles, but also weaker shadows. On this side of the screen CSM seemed to be just fine before the fixes, I never had any problems with it, perhaps a few compromises. That is why being able to compare both code sets, side by side, would be helpful. As mentioned in the previous paragraph, in my SVN tool I can see what was added in what version of the code, but I cannot see what the code looked like before the changes were made (this means that a certain eXperimental version is "compilable" even at this this late date for comparisons). The solution to the problems might be a hybrid between both CSM systems, the old one and the new one with the problems.

I hope that this is clear now what the intent is. Just trying to help/fix and not just excise.

Thanks.

[gpz]

Eldorado.Railroad, on 19 February 2014 - 05:22 PM, said:

Yes, that is exactly what I have been accessing on the SVN server. However, I have not had success in backdating/reverting to a specific eXperimental version of OR, lock, stock, and barrel. This would help me do comparisons in both results and the code, which would help solve problems.

If TortoiseSVN is installed on your computer, just right-click on project folder, select menü TortoiseSVN -> Update to revision. A form appears with a text field, into which you can enter the revision number you want to checkout. It is very easy to go back to even the very beginning. :clapping:

If you need to see two versions parallelly, then copy the whole project directory, so you can checkout two different versions to the two directories.

[Eldorado.Railroad]

From 19 February 2014 - 11:22 PM:

If TortoiseSVN is installed on your computer, just right-click on project folder, select menü TortoiseSVN -> Update to revision. A form appears with a text field, into which you can enter the revision number you want to checkout. It is very easy to go back to even the very beginning. :sign_rockon:

If you need to see two versions parallelly, then copy the whole project directory, so you can checkout two different versions to the two directories.

Peter,

That solved the problem. I was using a standalone SVN program, which is handy because it does not need to be installed, but it lacked certain features. I don't really like the shell integration of Tortoise, but at the moment there is no other free choice that I can think of. When a machine is being used for multiple purposes (not just coding per say) shell integration is too distracting. That right click menu can get to be way to long and complex! I wish there was a portable version of Tortoise someplace as even now this is not the machine I would use to code with.

Thank you sir!

[Eldorado.Railroad]

From 17 February 2014 - 04:44 AM:

ShadowMapBlur = (user set) False
ShadowMapResolution = (user set) 6144

My graphics card is an Nvidia GTX640 with 1GB of memory, which is fairly modest by today's standards.

Although I have not been able to do so since July of last year, I ran OR on a SLI Nvidia 780 rig. Quite simply, outstanding and expen$ive! On lower hardware I tried your settings (except I left ShadowMapBlur as True). When shadow maps are that size, this ATI rig drops framerates by at least 33% into the 40 FPS territory. I wonder what framrates you are achieving when the HUD indicates large numbers (>2000) for primitives and/or dynamic shadows?

[markus_GE]

Can tell you that, having tried out (and adpted, yet not adopted) these settings: 25 on the MONON, with that drop in the low 40s on everything else.

Reduced map resolution to (I think) 2048 and enabled two maps... gives reasonable shadows and reasonable performance.

Cheers, Markus

PS: This is a SONY VAIO Laptop, i5 M430 @ 2.27 GHz, 4 GB RAM, ATI Radeon Mobility HD5650 GPU with 1 GB VRAM

[dennisat]

Eldorado.Railroad, on 23 February 2014 - 08:38 PM, said:

Although I have not been able to do so since July of last year, I ran OR on a SLI Nvidia 780 rig. Quite simply, outstanding and expen$ive! On lower hardware I tried your settings (except I left ShadowMapBlur as True). When shadow maps are that size, this ATI rig drops framerates by at least 33% into the 40 FPS territory. I wonder what framrates you are achieving when the HUD indicates large numbers (>2000) for primitives and/or dynamic shadows?

I have VSync enabled so never see frame rates above 60. They start to drop into the 50s when I hit about 3,000/1,500 Render/Shadow primitives and into the 40s at 4,500/1,200 primitives. It really starts to stagger, less than 20fps, when I hit about 7,000/4,000 primitives but I don't have many route locations that are this dense.

Dennis

Edit:
Having re-read this topic from the start I think I'll experiment again with the shadow options.