[Genma Saotome]

More data, this time several versions, same Activity, no camera moves, max view distance of 10km.

V2057, no extension of LODs to max distance:
- 02644 shadow maps
- 11192 primitives
- 00022 fps


V2057, extending LODs to max distance, no instancing:
- 02904 shadow maps
- 22518 primitives
- 00010 fps


V2162, extending LODs to max distance, using instancing:
- 02842 shadow maps
- 16142 primitives
- 00014 fps


What the above tells me is it looks like there is a universal application of extending the LOD to max viewing distance for all objects, whether they qualify for instancing or not. If that is correct then that is problematic because all sorts of primiatives that had been LOD-away are now being displayed w/o any benefit of instancing reduction.

If it were possible to limit the extension of LOD-to-max-distance to just those objects that qualified for instancing I believe the performance gains from instancing would be improved considerably. With that in mind, an interpretation of the above data under those conditions might result in data like this:

New Version extending qualified shape's LODs to max distance, using instancing:
- 02644 shadow maps
- 06376 primitives
- 00051 fps (theoretical max).

That looks like a before state of 22 fps and an after state of perhaps as many as 51 fps. On such a busy route that is a VERY BIG improvement.

[James Ross]

Genma Saotome, on 11 April 2014 - 02:09 PM, said:

What the above tells me is it looks like there is a universal application of extending the LOD to max viewing distance for all objects, whether they qualify for instancing or not. If that is correct then that is problematic because all sorts of primiatives that had been LOD-away are now being displayed w/o any benefit of instancing reduction.

You're close. Models that are instanced always use the highest detail LOD. The existing option for highest detail continues to control non-instanced models. The extend object viewing distance option applies equally to instanced and non-instanced models. I mentioned previously that I would like to apply LODs to instanced models but that it isn't as straightforward as the instancing itself.

[Genma Saotome]

James Ross, on 11 April 2014 - 12:05 PM, said:

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.

[snip]

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

It is likely to vary from scene to scene, something that is hard to dynamically control for in-game... and certainly vary from route to route. This is probably one of those situations where it's either better to let the end user choose a value for each route... or to be creating some meta data off to the side somewhere (before run time) that would be available to the software at run time and influence whether instancing was on or off given the camera location.

[Genma Saotome]

James Ross, on 11 April 2014 - 02:18 PM, said:

You're close. Models that are instanced always use the highest detail LOD. The existing option for highest detail continues to control non-instanced models. The extend object viewing distance option applies equally to instanced and non-instanced models. I mentioned previously that I would like to apply LODs to instanced models but that it isn't as straightforward as the instancing itself.

So can one use instancing w/o setting the max_lod value to on?

[Genma Saotome]

Genma Saotome, on 11 April 2014 - 02:20 PM, said:

So can one use instancing w/o setting the max_lod value to on?

Judging by the hour it seems James has turned in for the day so I poked around in the options screen and found it could do what I was curious to do:

2634 Shadow Primitives
9567 Shape Primitives
23 fps

No where near the change I expected to see.


Fiddling a bit further I see I was in error about the view distance... I thought it was 10km but in fact all the above tests were set at view to horizon (dunno why... I'd never set that for this route... must have been forgotten from another route where it might have made sense). Changing that to 10km gives these numbers:

2634 Shadow Primitives
7852 Shape Primitives
27 fps

And so when one plays with the variables long enough you can eventually stumble into improved performance. :sign_thanks:
==============

A few more thoughts... perhaps already in place -- if not then suggestions.

Wouldn't be likely that all of the cars in any static consist have no animation? They're actually static until they are added to a train, right? Checking those shapes for duplication could be an opportunity for instancing away more dups.

Very, very few models have LOD's set as far as 1000m and probably none have a subsetting LOD at or above 2000. Given that likelyhood it makes a lot of sense for anything past 2000m to be set to its 2000m display set -- the fewest details -- not the opposite at it's most detailed LOD. And given how there is a whole lot of viewable terrain past 2000m the difference between minimal and full detail could add up to be large a large number of faces as well as some number of extra drawcalls. Q: Is it feasible to subset the act of instancing? Perhaps trying something like everything to be instanced as one that are inside of 2000m gets all details and everything of that shape that is beyond gets the least? If it works and the overhead is nominal the code might be adaptable to instancing each set of multiple object placements by each LOD value.

[Csantucci]

Genma Saotome, on 11 April 2014 - 02:20 PM, said:

So can one use instancing w/o setting the max_lod value to on?

Yes.

[Eldorado.Railroad]

I must have a different non Nvidia setup from everyone else who has posted here. On one of the heavily forested SLI routes (Scenic Sub) I see a reduction in primitive counts with this feature on, but with Vsync on the framrates fall from 60 down to 40. The non-instancing actually performs better.

Ouch!

[Genma Saotome]

More feedback:

I continue to run tests only this time I bothered to move the camera after noting the numbers... and whoa! No models were displayed beyond the next tile (IOW camera location +2 tiles was empty.) Obviously something was wrong. I tried various changes in view distance thinking somehow that was the problem... and then I turned off instancing and everything returned to view as it should. Dunno if they were rendered somewhere else or not at all but clearly something is funky.

I continued to reflect on having the most detailed models show at all distances and concluded I'd suggest this: Assuming you construct a list of Position() values for each occurrence in a set of qualifying objects, how about parsing that set into two lists when rendering? One list contains all instances under 2000m distance and the other contains those over 2000m distant. Then do a call for each list sending the least detailed LOD for the second list. I dunno if the difference in the vertex count will make it worthwhile so this is just something to consider.

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

I spent a good few hours yesterday trying to get to the bottom of it but haven't worked it out yet. At least for the JP1streetlight case, the model has two sub-objects (so that it can be on/off for night/day) and it is the second sub-object that is misbehaving. The maths involved looked right (the sub-object has a different origin to the main model) but it obviously doesn't appear. The case continues.

[James Ross]

Right, got it. It's because only some of the scenery effects are PS3-enabled. Let's see how we can fix this...