[edwardk]

The development version is not cooperating so I was unable to run a test, but I am still unable to launch anything. This is odd. I was able to run the XNA version. I would also advise to check the folder where the saves are kept. Turns out I had years worth of files I had to delete. This is also including the "Load Cache" folder.

Edit: I guess we still have to create the LAA version of runactivity.exe. Once I did this, the problem stopped. This is still odd because at one point during the day, I was in and out the program and did not have problems until now. I even rebooted the computer and the problem still existed. I am guessing there is a memory management issue since I did not create the LAA version until now.

Edit: There is one possibility. In the development version I was experimenting with expanding the precipitation box size. The only the thing I can guess is the non-development version did not like this.

Edward K.

[edwardk]

It looks I may have experienced a first in issues. While running the monogame version with an activity that included snow, I experienced a low memory issue. I am not sure if snow is the culprit, but it looks as if there may be memory leak. I was not keeping track how long I was in the activity before OR crashed. I never experienced this with the XNA release so its looking the monogame version is the cause.

Edit: I am not sure if there is a connection with this, but there was a log message indicated below. This was for ParticleEmitterShader.fx.

warning X3556: integer divides may be much slower, try using uints if possible.

Edward K.

[ebnertra000]

I've actually run across that, too, but in my case, the weather was clear. So it probably isn't dependent on weather. Exhaust, maybe?
Those are particles, I think. In any case, attached is my logfile, in case it's useful

Attached File(s)

•  OpenRailsLog.txt (16.26K)
  Number of downloads: 306

[perpetualKid]

There's a bug in Terrain.cs where IndexBuffers are not correcty set/updated, at least for Monogame version leading to lot of D3D warnings (visible only if running DX Debugging):
D3D11 WARNING: ID3D11DeviceContext::DrawIndexed: Index buffer has not enough space! [ EXECUTION WARNING #359: DEVICE_DRAW_INDEX_BUFFER_TOO_SMALL]

Basically in Draw method, if the PatchIndexBuffer for the particular terrain patch is null, still need to reset the graphicsDevice.Indices to the SharedPatchIndexBuffer, as it might have been set from another patch's individual buffer in a previous iteration of the Draw-loop.
I haven't profiled but would assume there's a minor performance gain once the IndexBuffer works correctly. As code is same for XNA version, this might cause same issue, but I haven't checked.

diff --git a/Source/RunActivity/Viewer3D/Terrain.cs b/Source/RunActivity/Viewer3D/Terrain.cs
index b280d493..ae8f0030 100644
--- a/Source/RunActivity/Viewer3D/Terrain.cs
+++ b/Source/RunActivity/Viewer3D/Terrain.cs
@@ -264,8 +264,7 @@ namespace Orts.Viewer3D
public override void Draw(GraphicsDevice graphicsDevice)
{
graphicsDevice.SetVertexBuffers(VertexBufferBindings);
- if (PatchIndexBuffer != null)
- graphicsDevice.Indices = PatchIndexBuffer;
+ graphicsDevice.Indices = PatchIndexBuffer ?? SharedPatchIndexBuffer;
graphicsDevice.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, 17 * 17, 0, PatchPrimitiveCount);
}

[Csantucci]

Thanks, perpetualKid. If there aren't negative remarks against that, I'll commit it.

[perpetualKid]

Csantucci, on 22 November 2017 - 04:59 AM, said:

Here OR x.3988, MonoGame version plus ShadowAllShapes checkbox, can be downloaded http://www.interazio...e/OR3988_MG.zip .
Here the updated dev kit can be downloaded http://www.interazio...DevKit_Rev7.zip can be downloaded.
My list of pending functional problems is empty at the moment.
Thanks again to Dennis for his invaluable contributions.

Something is going wrong by the changes to CabShader introduced in that patch.
Under the hood, DX throws exceptions everytime the SpriteBatch.End is called once the effect shader is set at the SpriteBatch.Begin.
D3D11 ERROR: ID3D11DeviceContext::DrawIndexed: Vertex Shader - Pixel Shader linkage error: Signatures between stages are incompatible. The input stage requires Semantic/Index (NORMAL,0) as input, but it is not provided by the output stage. [ EXECUTION ERROR #342: DEVICE_SHADER_LINKAGE_SEMANTICNAME_NOT_FOUND]

SpriteBatch is first started without effect

SpriteBatch.Begin(SpriteSortMode.Deferred, BlendState.NonPremultiplied)

in SpriteBatchMaterial.SetState in Material.cs.

Drawing the CabRenderer primitive in MSTSLocomotiveViewer.cs, the SpriteBatch is ended, and restarted with _Shader as effect parameter

 _Sprite2DCabView.SpriteBatch.Begin(0, BlendState.NonPremultiplied, null, DepthStencilState.Default, null, _Shader)

Subsequent calls to the SpriteBatch.End error with above message, but SharpDX swallows the exception and I guess some shader effect is not applied as it should. I'm a bit lost as graphics is not in my core skills, looking up the error message, the PIXEL_INPUT in cabshader.fx may be somehow wrong (order)?

Stacktrace:
at SharpDX.Direct3D11.DeviceContext.DrawIndexed(Int32 indexCount, Int32 startIndexLocation, Int32 baseVertexLocation)
at Microsoft.Xna.Framework.Graphics.GraphicsDevice.PlatformDrawUserIndexedPrimitives[T](PrimitiveType primitiveType, T[] vertexData, Int32 vertexOffset, Int32 numVertices, Int16[] indexData, Int32 indexOffset, Int32 primitiveCount, VertexDeclaration vertexDeclaration)
at Microsoft.Xna.Framework.Graphics.GraphicsDevice.DrawUserIndexedPrimitives[T](PrimitiveType primitiveType, T[] vertexData, Int32 vertexOffset, Int32 numVertices, Int16[] indexData, Int32 indexOffset, Int32 primitiveCount, VertexDeclaration vertexDeclaration)
at Microsoft.Xna.Framework.Graphics.SpriteBatcher.FlushVertexArray(Int32 start, Int32 end, Effect effect, Texture texture)
at Microsoft.Xna.Framework.Graphics.SpriteBatcher.DrawBatch(SpriteSortMode sortMode, Effect effect)
at Orts.Viewer3D.SpriteBatchMaterial.ResetState(GraphicsDevice graphicsDevice) in C:\Storage\Dev\GitHub\Other\ORTS-MG\Source\RunActivity\Viewer3D\Materials.cs:line 616
at Orts.Viewer3D.RenderFrame.DrawSequences(GraphicsDevice graphicsDevice, Boolean logging) in C:\Storage\Dev\GitHub\Other\ORTS-MG\Source\RunActivity\Viewer3D\RenderFrame.cs:line 685
at Orts.Viewer3D.RenderFrame.DrawSimple(GraphicsDevice graphicsDevice, Boolean logging) in C:\Storage\Dev\GitHub\Other\ORTS-MG\Source\RunActivity\Viewer3D\RenderFrame.cs:line 625
at Orts.Viewer3D.RenderFrame.Draw(GraphicsDevice graphicsDevice) in C:\Storage\Dev\GitHub\Other\ORTS-MG\Source\RunActivity\Viewer3D\RenderFrame.cs:line 529
at Orts.Viewer3D.Processes.RenderProcess.Draw() in C:\Storage\Dev\GitHub\Other\ORTS-MG\Source\RunActivity\Viewer3D\Processes\RenderProcess.cs:line 328
at Orts.Viewer3D.Processes.Game.Draw(GameTime gameTime) in C:\Storage\Dev\GitHub\Other\ORTS-MG\Source\RunActivity\Viewer3D\Processes\Game.cs:line 134
at Microsoft.Xna.Framework.Game.DoDraw(GameTime gameTime)
at Microsoft.Xna.Framework.Game.Tick()
at MonoGame.Framework.WinFormsGameWindow.RunLoop()
at Microsoft.Xna.Framework.Game.Run(GameRunBehavior runBehavior)
at Orts.Program.Main(String[] args) in C:\Storage\Dev\GitHub\Other\ORTS-MG\Source\RunActivity\Program.cs:line 49



Relevant changes from that patch:

RunActivity/Content/CabShader.fx

@@ -44,9 +44,9 @@

struct PIXEL_INPUT
{
- //float2 Position : VPOS;
+ float4 Position : SV_POSITION;
+ float4 Color : COLOR0;
float2 TexCoords : TEXCOORD0;
- float4 Color : COLOR0;
float3 Normal : NORMAL;
};


RunActivity/Viewer3D/RollingStock/MSTSLocomotiveViewer.cs

@@ -1257,9 +1256,9 @@
else
_Shader.SetData(_Viewer.MaterialManager.sunDirection, _isNightTexture, false, _Viewer.World.MSTSSky.mstsskyovercastFactor);

+ _Sprite2DCabView.SpriteBatch.End();
+ _Sprite2DCabView.SpriteBatch.Begin(0, BlendState.NonPremultiplied, null, DepthStencilState.Default, null, _Shader);
_Shader.SetTextureData(stretchedCab.Left, stretchedCab.Top, stretchedCab.Width, stretchedCab.Height);
- _Shader.Begin();
- _Shader.CurrentTechnique.Passes[0].Begin();

[dennisat]

perpetualKid, on 23 August 2018 - 02:22 AM, said:

RunActivity/Viewer3D/RollingStock/MSTSLocomotiveViewer.cs

@@ -1257,9 +1256,9 @@
else
_Shader.SetData(_Viewer.MaterialManager.sunDirection, _isNightTexture, false, _Viewer.World.MSTSSky.mstsskyovercastFactor);

+ _Sprite2DCabView.SpriteBatch.End();
+ _Sprite2DCabView.SpriteBatch.Begin(0, BlendState.NonPremultiplied, null, DepthStencilState.Default, null, _Shader);
_Shader.SetTextureData(stretchedCab.Left, stretchedCab.Top, stretchedCab.Width, stretchedCab.Height);
- _Shader.Begin();
- _Shader.CurrentTechnique.Passes[0].Begin();

Hi Carlo,

I'm following this with interest. I don't know if you remember but these changes were due to Monogame handling Spritebatch shading differently from XNA.
Unfortunately, I'll be away for 2 weeks otherwise I would be experimenting with this problem.

Dennis

[Csantucci]

Hi Dennis,
of course it would be nice if the problem could be solved. However no one noticed visual problems, so I think that we can all wait two weeks until you're back :)

[James Ross]

perpetualKid, on 22 August 2018 - 01:22 PM, said:

There's a bug in Terrain.cs where IndexBuffers are not correcty set/updated, at least for Monogame version leading to lot of D3D warnings (visible only if running DX Debugging):
D3D11 WARNING: ID3D11DeviceContext::DrawIndexed: Index buffer has not enough space! [ EXECUTION WARNING #359: DEVICE_DRAW_INDEX_BUFFER_TOO_SMALL]

Basically in Draw method, if the PatchIndexBuffer for the particular terrain patch is null, still need to reset the graphicsDevice.Indices to the SharedPatchIndexBuffer, as it might have been set from another patch's individual buffer in a previous iteration of the Draw-loop.
I haven't profiled but would assume there's a minor performance gain once the IndexBuffer works correctly. As code is same for XNA version, this might cause same issue, but I haven't checked.

Hmm, interesting. I haven't looked at the differences between the XNA and MonoGame code here, but I am familiar with the XNA side; what you've found in the code should be correct as-is, because we batch up the draw calls into TerrainSharedMaterial and TerrainMaterial groups, the former setting the graphicsDevice.Indices before starting drawing each primitive in TerrainSharedMaterial.SetState.

There of course may be a bug in the draw call batching that means the above isn't happening as intended. You can check this by holding the Debug Log Render Frame key down (Alt-F12 by default) for at least one frame, which will flood the log file with details of all the rendering batches being performed.

Whether or not this issue is as described, running the game with the debug DirectX mode is a fantastic idea and I'm glad you've reminded me it exists (I'd totally forgotten about it), so thanks for that! We should run Open Rails under more debugging modes like this. :)

[perpetualKid]

James Ross, on 23 August 2018 - 11:55 AM, said:

we batch up the draw calls into TerrainSharedMaterial and TerrainMaterial groups, the former setting the graphicsDevice.Indices before starting drawing each primitive in TerrainSharedMaterial.SetState.

There of course may be a bug in the draw call batching that means the above isn't happening as intended.

James, based on that statement I did some more digging. I think the issue comes through AddAutoPrimitive from RenderFrame.cs - actually seems with Dynamic Shadows the materials on shadow map are not grouped but just added in AddShadowPrimitive, whereas other materials are properly grouped in AddPrimitive.
So sorting and grouping the RenderItem collections for shadowmap either while inserting or afterwards should give result how you describe. The alternative approach how I fixed that equally ensures the correct index is used.
Your approach will save the GPU from changing the IndexBuffer (it's only a pointer which buffer to be used since they are already setup before), at the cost of sorting the Materials.

As this is not Monogame specific, we may split that into a separate thread?