[James Ross]

AlFitz, on 07 April 2014 - 12:26 PM, said:

The ECML does have a lot of repeated scenery but it's very long, the stations are pretty accurate however.

It's good you've been able to implement this as I thought it was DX11?

Yeah, this is part of what I posted yesterday when I added the option:

James Ross said:

Until a few days ago, I thought that hardware instancing needed DirectX 10+ but a friend of mine pointed out that not only is Efficiently Drawing Multiple Instances of Geometry possible in DirectX 9, it is supported in XNA 3.1 (it's also supported in XNA 4.0, with a slightly different API).

So there we are, working instancing. :D

[That Genset Foamer]

This looks like it'll bode well for the Salinas Valley route. Downloading the new build, gonna test it out tonight!

[Csantucci]

Starting from X2157 I recommend to everyone checking this option: I just noticed a frame rate rise from 17 to 22 FPS in a big yard!

[gpz]

I would like to ask James, just out of curiosity, if wouldn't some draw call batching also be possible to be implemented? I mean for objects sharing the same material, the different geometries could be uploaded to VRAM and rendered in one pass. Maybe it is possible only for opaque and 1-bit-alpha objects, since for blended ones the alpha sorted rendering has higher priority. And even for them the effect for their shadow is questionable.

[James Ross]

gpz, on 08 April 2014 - 12:31 AM, said:

I would like to ask James, just out of curiosity, if wouldn't some draw call batching also be possible to be implemented? I mean for objects sharing the same material, the different geometries could be uploaded to VRAM and rendered in one pass.

That's really hard work. You have to merge the vertex and index buffers first and (unlike instancing) I don't believe you can animate these primitives at all.

[gpz]

But it might still worth doing it at least for tracks or terrain. E.g. on large stations there might be a lot of different type of tracks, where batching the many only-dozen-vertex objects into 1 draw call might help. I don't know if it is possible, but for tracks the batching of already-instanced objects might save some more drawcalls too. :)

[dennisat]

dennisat, on 07 April 2014 - 07:27 AM, said:

I've been testing this feature on Dorset Coast and it certainly reduces the number of draw calls (loads up the GPU somewhat more of course) and increases frame rates.

However, I am seeing some weird effects...

I seem to be the only one with any problems with model instancing. I have been experimenting with X2157 on Dorset Coast this morning and have tried a lot of combinations of Nvidia graphic options, including defaults, with no improvement to the flickering transparent textures. Note the Clapham Junction platform canopies in the first two (static) screenshots below; with instancing turned off the flickering does not occur. So far, I have come across two artifacts which are the light cones of JP1.streetlight.s. This is used extensively as a platform light in this route. These always occur at the same locations and are not there when instancing is turned off. See last two screenshots below.

Is it my graphics card - GTX460? It is working hard but does not seem to be hitting max memory or GPU when these effects occur, according to GPU-Z.

Flickering transparent textures:




Random Artifacts:

[James Ross]

I've seen a single item misplaced in my journeys with instancing (a fence across the track in L&PS). I'm guessing the model hierarchy is confusing things in some way, like for your case of the street light. But I have not seen instancing cause flickering or unexpected transparent scenery and I don't have any good ideas how it could do so (the materials that control the actual rendering are unchanged), so that's currently a bit of a mystery.