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

[disc]

James Ross, on 08 April 2014 - 12:35 AM, said:

I don't believe you can animate these primitives at all.

Can't be done like this?: if the object has animation, then rendered as it is now. If doesn't, then it can be batched. The most of the scenery objects aren't animated at all.

[James Ross]

disc, on 08 April 2014 - 02:48 AM, said:

Can't be done like this?: if the object has animation, then rendered as it is now. If doesn't, then it can be batched. The most of the scenery objects aren't animated at all.

Sure, that's exactly how instancing works currently; animated scenery is left as-is. My point is that you can animate instanced models (it's just not implement yet), but if you batch things up you can't. I don't think batching general scenery is a particularly worthwhile endeavour.

[gpz]

James Ross, on 08 April 2014 - 02:53 AM, said:

My point is that you can animate instanced models (it's just not implement yet), but if you batch things up you can't. I don't think batching general scenery is a particularly worthwhile endeavour.

All right, I believe it. Just a small note: I meant batching would be applied after instancing, on the remaining objects, not before.

(Just a little explanation to others: instancing can be done for objects with same geometry and material, while batching could be done for objects with same material but different geometry.)

[Genma Saotome]

Batching would be a HUGE aid to my routes as my models use a lot of generic textures that are shared widely. I think it would also be a HUGE aid for Scalerail, DBTracks, and any road set anywhere there are large numbers of them placed.

[roeter]

Seems not all is well with instancing.
Below is without instancing, bottom is with instancing enabled.


It's nice that all similar objects are drawn as one instance, would be even nicer if the were drawn in their proper places.
If you're wondering what to look for : all 'sausages' have been removed from their posts, and there's only one remaining which hangs over the left-hand track in the middle of the station.
This is a 'private' route, so I'm afraid it's not available for download.

Regards,
Rob Roeterdink

[dennisat]

roeter, on 08 April 2014 - 10:45 AM, said:

Seems not all is well with instancing.

I bet this is the same as my observation in a previous post. My "sausage" is the night "light cone" and if you could see the "light cones" on the platform lamps, they wouldn't be there, if you see what I mean!

Dennis

Attached thumbnail(s)

• 

[dennisat]

I have been experimenting all day with JP1streetlight1.s (the platform lamp) and I cannot work out why it should appear as it does when instancing is used.

I know very little about model structure so I wonder if an expert could take a look at the model and see if there is anything unusual about it. It doesn't seem very complex. It is in the JAPAN1 folder.

Instancing makes such a marked improvement to a heavily scenerised route that I think it's worth getting to the bottom of why some models do not show properly when it is in use.

Dennis

[James Ross]

dennisat, on 09 April 2014 - 09:18 AM, said:

I have been experimenting all day with JP1streetlight1.s (the platform lamp) and I cannot work out why it should appear as it does when instancing is used.

I know very little about model structure so I wonder if an expert could take a look at the model and see if there is anything unusual about it. It doesn't seem very complex. It is in the JAPAN1 folder.

Instancing makes such a marked improvement to a heavily scenerised route that I think it's worth getting to the bottom of why some models do not show properly when it is in use.

Don't worry, I'll be on the case soon. :cheers3:

[Genma Saotome]

To buttress the argument that this is useful, here's a real example of the results from the Goose Island route:

124	sr_1tbuffer_c.s	
69	sr_1tcrv_c_00150r01d.s	
65	sr_1tend_c_06d.s	
51	sr_1tstr_c_005m.s	
47	sr_1tstr_c_005_5m.s	
45	sr_1tbuffer_c.s	
42	sr_1tcrv_c_00060r20d.s	
41	sr_1tstr_c_025m.s	
34	sr_1tstr_c_005_5m.s	
31	sr_1tstr_c_015m.s	
28	sr_1tend_c_06d.s	
27	sr_1tstr_c_030m.s	
26	sr_1tstr_c_025m.s	
24	sr_1tstr_c_040m.s	
23	sr_1tbuffer_c.s	
22	sr_1tcrv_c_00150r05d.s	
22	sr_1tstr_c_005m.s	
22	sr_xtend_c_06db.s	
21	sr_1tstr_c_010m.s	
20	sr_1tstr_c_020m.s	
19	sr_xtcrv_c_00150r01db.s	
17	sr_1tcrv_c_00120r10d.s	
16	sr_1tcrv_c_00060r10d.s	
16	sr_xtend_c_06dd.s	
15	sr_1tcrv_c_00060r20d.s	
15	sr_1tcrv_c_00150r01d.s	
15	sr_xtcrv_c_00150r01da.s	
14	sr_1tcrv_c_00120r01d.s	
14	sr_1tcrv_c_00120r05d.s	
14	sr_1tstr_c_050m.s	
14	sr_1tcrv_c_00090r01d.s	
13	sr_1tcrv_c_00060r20d.s	
13	sr_1tstr_w_010m.s	
13	sr_xtcrv_c_00150r01db.s	
13	sr_2tstr_c_005m.s	
13	sr_1tend_w_06d.s	
12	sr_1tcrv_c_00075r10d.s	
12	sr_2tstr_c_020m.s	
11	sr_1tcrv_c_00090r20d.s	
11	slw_066a_2ls_100m.s	
11	sr_1tstr_c_020m.s	
11	gi_cabrini_green_08x.s	
10	sr_1tstr_c_100m.s	
10	slw_066a_2ls_050m.s	
10	sr_1tstr_w_005_5m.s	
10	gi_cabrini_green_16a.s	
9	sr_1tcrv_w_01000r01d.s	
9	sr_1tstr_w_005_5m.s	
9	sr_1tstr_c_080m.s	
9	sr_1tend_c_06dx.s	
9	slw_066a_2ls_002m.s	
9	slw_066a_2l-2lt_90d.s	
9	slw_066a_sw10_050m.s	
9	slw_066a_sw10_2l-2lx_90d.s	
9	slw_066a_sw10_100m.s	
9	sr_1tstr_c_030m.s	
9	sr_xtcrv_c_00150r01dd.s	
9	sr_1tcrv_c_00090r05d.s	
8	sr_1tend_c_06dx.s	
8	sr_xtcrv_w_00500r01de.s	
8	sr_xtcrv_w_00500r01dd.s	
8	sr_xtcrv_w_01000r01db.s	
8	sr_xtcrv_c_00060r10db.s	
8	sr_xtend_c_06db.s	
8	sr_1tcrv_c_00100r10d.s	
8	sr_1tstr_c_070m.s	
8	sr_1tcrv_c_00090r10d.s	
8	sr_1tstr_c_060m.s	
8	slw_066a_2l-2lx_90d.s	
8	sr_1tcrv_c_00150r05d.s	
8	sr_1tstr_c_040m.s	
8	sr_xtcrv_c_00090r10db.s	
8	sr_1tstr_w_005m.s	
7	sr_1tcrv_c_00120r10d.s	
7	sr_1tstr_w_005m.s	
7	sr_1tstr_c_005_5m.s	
7	sr_1tstr_c_015m.s	
7	sr_xtcrv_w_00500r05db.s	
7	sr_1tcrv_c_00500r02d.s	
7	sr_1tcrv_c_00090r05d.s	
7	sr_2tstr_c_040m.s	
7	slw_066a_2ls_250m.s	
7	slw_066a_sw10_002m.s	
7	slw_066a_sw10_080m.s	
7	sr_1tstr_c_005_5m.s	
7	sr_xtcrv_c_00090r10da.s	
7	sr_xtend_c_06da.s	
7	sr_xtcrv_c_00060r10da.s	
7	sr_xtcrv_c_00060r10db.s	
7	sr_1tstr_w_025m.s	
6	sr_1tend_c_06d.s	
6	sr_1tcrv_c_00250r05d.s	
6	sr_1tstr_c_025m.s	
6	sr_2tstr_w_005m.s	
6	sr_1tcrv_c_00075r05d.s	
6	sr_2tstr_c_030m.s	
6	sr_xtend_c_06dd.s	
6	sr_1tstr_c_250m.s	
6	slw_066a_2ls_080m.s	
6	slw_066a_2ls_065m.s	
6	slw_066a_sw10_011m.s	
6	sr_1tstr_c_070m.s	
6	sr_1tstr_c_050m.s	
6	sr_2tstr_c_020m.s	
6	sr_1tstr_c_001m.s	
5	sr_1tend_w_03dx2.s	
5	sr_2tstr_w_020m.s	
5	sr_xtcrv_w_00340r10de.s	
5	sr_xtcrv_w_01000r01dd.s	
5	sr_1tcrv_w_00500r01d.s	
5	sr_xtcrv_w_00500r01db.s	
5	sr_1tcrv_w_00500r05d.s	
5	sr_xtcrv_w_00500r05da.s	
5	sr_xtcrv_w_01000r01da.s	
5	sr_1tstr_w_010_2m.s	
5	sr_1tcrv_w_00340r01d.s	
5	sr_1tstr_w_025m.s	
5	sr_2tstr_c_005m.s	
5	sr_1tcrv_c_00100r05d.s	
5	sr_xtcrv_c_00150r10db.s	
5	sr_1tcrv_c_00250r05d.s	
5	sr_1tcrv_c_00150r10d.s	
5	slw_066a_2ls_003m.s	
5	slw_066a_sw10_003m.s	
5	slw_066a_sw10_004m.s	
5	slw_066a_sw10_250m.s	
5	slw_066a_sw10_040m.s	
5	slw_066a_sw10_2l-2lt_90d.s	
5	sr_2tstr_c_020m.s	
5	sr_1tstr_c_020m.s	
5	sr_1tstr_c_010m.s	
5	sr_1tstr_c_100m.s	
5	sr_1tcrv_c_00150r10d.s	
5	sr_xtcrv_c_00090r10dd.s	
5	sr_xtcrv_c_00090r05dd.s	
5	sr_xtcrv_c_00090r05db.s	
1718		

That's 1718 instances reduced to just 136 sets. All but 2 lines (21 objects) are track or road shapes.

Each of those 1718 instances required at least 4 draw calls. What was not apparent tho was any appreciable difference in fps. I'll try to find time to do some before & after comparisons... primitives and fps.

James, you might consider dropping the threshold of what's "instanced" from 5 to 4 or maybe even 3. I think trading "depth" (instances per shape) for breadth (lots more sets) could add up enough to make it worthwhile.

[James Ross]

Genma Saotome, on 11 April 2014 - 11:52 AM, said:

That's 1718 instances reduced to just 136 sets. All but 2 lines (21 objects) are track or road shapes.

Good data.

Genma Saotome, on 11 April 2014 - 11:52 AM, said:

James, you might consider dropping the threshold of what's "instanced" from 5 to 4 or maybe even 3. I think trading "depth" (instances per shape) for breadth (lots more sets) could add up enough to make it worthwhile.

There is certainly a balance to be struck, as I found that too low a threshold actually started making performance worse again. Of the values I tested, 5 was the peak, but it'll naturally vary somewhat due to the differing scenery.

To give some hard numbers, I started the London & Port Stanley activity "T08 Morning Run" and switched to the cab camera. With my OR settings (which included dynamic shadows but the default 2K view distance and no auto-tune) this starts off with 10.9k primitives and 8.8k shadow primitives at 17 FPS.

A threshold of 25 barely helps at all, with the values being 10.7k / 8.8k / 18 FPS.

Down to 10 and it's making a difference: 7.3k / 6.1k / 23 FPS.

At 5 it's doing the best: 5.9k / 5.0k / 25 FPS.

But at 2, it's back up: 5.4k / 4.9k / 23 FPS.

And at 1, so everything is instanced, it is: 5.4k / 4.9k / 21 FPS.

So even with the drop of 0.5k primitives from 5 down to 2, it actually lost 2 FPS due to the extra overhead for instancing calls (I believe) vs non-instancing. I was going through a big range then (100, 50, 25, 10, 5, 2, 1) but now we've had some experience with it I might re-run the test with a range more like (10, 9, 8, 7, 6, 5, 4, 3, 2, 1).