[disc]

Usually not the count of the triangles are the bottleneck, but the quantity of the objects as each individual object need at least one draw call to be drawn. That's why some open world games are using combined shapes ( one big building complex, or forest object, where the whole thing is actually one shape, so it can be drawn by a single draw call).
Draw calls are made by the CPU, and can be done in only one thread, at least below direcx 11, that's why single CPU core performance is more important than multi core performance in games.
Really the draw call quantity for an object looks like this: nodecount*materialcount.
A diesel locomotive in game ideally looks like this: 2x nodes of bogies/trucks with 1 material, 1x node of locomotive body with 2 materials (normal body texture, + something for transparent faces, like glass. Which means 2x1+1x2=4 draw calls. But since the 3d modelers use multiple smaller textures for the locomotive body(they shouldn't instead they should use one bigger texture), it makes this number higher.

If you have a tree object with one node and one material, and you want to place 6000 of these as a forest, it will be 6000 draw calls. But if you attach these 6000 trees into a single node in 3d editor, then it could be drawn in game by 1 draw call.

Some game engines support draw call batching (where the game engine combines the non moving non animated objects in run time, into a single object), but as i heard it have big limitations, so still the most of the performance depends on the 3d modelers and the map editors.

You can see how much draw calls are used in OR, by watching the "Render primitives" number at the debug informations.

[Genma Saotome]

In the FWIW category.... 2000m vs. 4000m view distance (models .s manually edited):



Sometimes the extra view distance makes a big difference.

[jtr1962]

I started a very similar thread in the OR development forum: http://www.elvastowe...ods-above-2000/

I think the best way to move forward is to have the sim calculate on the fly which objects to draw based on their size, and if they're not occluded by other objects. I think the 250 to 300 number for distance to height/width ratio suggested by Lindsay sounds reasonable. We can even extend this idea to details on objects. If it's not visible, it's not drawn. You can reduce GPU power somewhat by not doing things like showing shadows for objects until those shadows would be clearly visible. The only problem I can see with all this (besides possibly taxing the CPU/GPU) is that Open Rails needs to load more tiles in order to know about the details of the objects on those tiles. At 2000 meters viewing distance you only need to keep 9 tiles in memory. At 4000 meters this expands to 25. The numbers for 6000, 8000, and 10000 meters are 49, 81, and 121. I would imagine though the saving grace is most routes usually don't have a huge number of tiles perpendicular to the track. In practice with a 10,000 meter viewing distance, you'll usually only be looking at perhaps 30 to 40 tiles. Now I have no idea what 30 or 40 tiles in a dense urban area might mean in terms of memory requirements, but at least we're no longer bound by 2 GB if need be. Just setting the LLA flag gives us up to 4 GB on a 64-bit system. I think it's safe to say at this point the majority of people running OR will be using 64-bit hardware under a 64-bit OS.

I'm usually not a huge fan of eye candy over other aspects of the sim, but large objects just popping into view long after they would be clearly visible in the real world greatly distracts from the realism. With modern game engines and PCs, there's no reason to continue to be bound by the LOD structure needed by MSTS to cope with the limited computing power available at the time.

[Genma Saotome]

As you noted, as distance increases the tile count grows by leaps and bounds... but remember: only what's in the view frustum gets rendered.

Thinking of performance, in the view above the far buildings are being displayed w/ a 4000m view distance. Obviously the terrain runs out about as far. What is not apparent is that in this scene 2/3's of the draw calls are for the track (Scalerail). Given that fact the best thing that could be done for performance here would be to either not use Scalerail or to vastly reduce the number of individual track shapes that are rendered individually.

IMO the look of Scalerail is so vastly better than Xtracks I cannot imagine not using it and so that leaves me looking at what might be done waaaay down the road... and what comes to mind procedurally generated track. The OR teams knows how to do it (OR does procedurally generated track to replace dynamic track shapes). There's a template that provides for alternative profiles (including one that looks like Scalerail). What's not been done is any analysis of optimizing lots of track for rendering performance. Does one divide up a tile into 500m squares and render all track within each square as-if it were just one shape? That's 16 calls per tile... very cheap. 250m squares? 1000m squares? Or go a completely different way and do it by signal sections instead. Or something altogether different? Don't know. But IMO there is a big opportunity to get performance improvements by designing a solution.

[jtr1962]

Genma Saotome, on 26 April 2013 - 07:48 PM, said:

Thinking of performance, in the view above the far buildings are being displayed w/ a 4000m view distance. Obviously the terrain runs out about as far. What is not apparent is that in this scene 2/3's of the draw calls are for the track (Scalerail). Given that fact the best thing that could be done for performance here would be to either not use Scalerail or to vastly reduce the number of individual track shapes that are rendered individually.

Procedurally generated track is probably the way to go in the future other than for switches. Properly defining switches procedurally gets pretty complex, and even then the end result isn't always what you want. That's why in my opinion I think it's better to stick with shapes for switches, and generate everything else procedurally. As for Scalerail and also DB Track, despite the hit on performance I can't see not using them either.

Semi off-topic but do any profiles exist for DB Track? I've converted one route but the procedurally generated banked curves severely clash with DB Track.

[Genma Saotome]

I'm confident that procedural turnouts are feasible. What remains (somewhat) problematic is any animation. I suppose a model with animated points and switchstand is a reasonable compromise, tho I think it would be better if all rails were part of the procedural solution, points included, so they can share a common profile.

[James Ross]

Just on the topic of procedural generation of track and switches, I've had the idea that we could make a tool which creates a static switch shape from a track profile and some switch parameters, and then you can add animation manually. Obviously the generated shape would need to be in a 'better' format than Kuju shapes but I believe it can be done. Whether the amount of work adjusting and animating the static shape is any better than just doing it by hand is something I can't really figure out.

[Genma Saotome]

James Ross, on 27 April 2013 - 04:09 AM, said:

Just on the topic of procedural generation of track and switches, I've had the idea that we could make a tool which creates a static switch shape from a track profile and some switch parameters, and then you can add animation manually. Obviously the generated shape would need to be in a 'better' format than Kuju shapes but I believe it can be done. Whether the amount of work adjusting and animating the static shape is any better than just doing it by hand is something I can't really figure out.

Understood... that's why I thought the moving points might need to be modeled with the switchstand.

The profile work Walt did for DT made a lot of sense to me but AFAIK nobody took the next step and examined the question of how to apply that to non DT shapes; One would think it would be a straightforward 1:1 replacement, which in turn could lead to the next step of figuring out how to merge n number of continous segments... and on to n number of adjacent segments. What do you think of my idea of simply dividing up a tile into fixed sized squares and figuring out how to generate a single shape for all track found within each square? So long as the .tdb remains in use the game doesn't really care how the mesh to render as track was created.

[James Ross]

Sounds like a reasonable idea, the less objects in a tile the better for rendering performance. If it's all generated, we'll have plenty of freedom to do things like this easily, too.

[Lindsayts]

one thing that may be worth thinking about is if a particular scene being drawn has a low object count increase the viewing distance. One way to do this would be set the viewing distance based on the frame rate or on the number of objects loaded. From my experiments the routes that most benefit from a longer drawing distance is the sparse scenery rural routes. For most others like suburban of hill/mountain railways a viewing of over 3000 metres is a none issue. It is unlikely to be necesary (or possible) to require a long viewing distance for all routes. This is a point that some posters appear not to have understood.

The improvement that a loading distance of 4000 metres produces in a rural route is vast being way more realistic. On the NE vic route I am using as a test bed I have now done all 60 odd trees higher than 10 metres, curiously it appears to have made little difference to the frame rate. I will have to do a before and after editing the LOD's test to see the exact effect on the frame rate. I will post the results in the near future.

Lindsay