What are the frame rate KILLERS?

C

ccowan2126

Member
When "planting" trees and shrubs in great numbers, which are best to use: splines, or individual trees? I'm am replicating Appalachian forests of NC and will be needing huge quantities of trees and don't want to slow things down too much. Any suggestions? Also, what is the effect of "paint" on frame rates? If I over paint and then overpaint areas again to get the desired balance to an area, what does that do?

Thanks, in advance.
 
ccowan2126 said:
When "planting" trees and shrubs in great numbers, which are best to use: splines, or individual trees? I'm am replicating Appalachian forests of NC and will be needing huge quantities of trees and don't want to slow things down too much. Any suggestions? Also, what is the effect of "paint" on frame rates? If I over paint and then overpaint areas again to get the desired balance to an area, what does that do?

Thanks, in advance.
Click to expand...

Fran1 is correct, individual items need a low as buffer count as possible and total buffer count should never exceed 2,000

As for trees, spline types kill any system if you put enough of them in, same as individual billboard type trees, been there done that one. Speedtrees are best, can use mine, have quite a selection on the DLS and can make extra on request.

If you need help with speedtree placement and use, let me know. Try not to use more than 6 different types in the same camera view, will give a performance impact depending on your system specs. Also you don't need as many speedtrees in a given scene to get good coverage.

Peter
 
Watch out for assets with lots of texture files, and those made in Sketchup. For locos and rolling stock avoid ones without lod, and scenery versions put a lot less load on the machine than ones that move. The problem with buffer count is sometimes you deliberately want to use something with a high buffer count, a block of 48 houses for example has much lower impact than 48 single houses but much greater than a single house.

The overheads are 200 poly equivalent per texture and 300 per mesh, so a small house has an overhead of 500 poly equivalents before you start so if its 12 polys or 50 it doesn't matter that much, its the overhead that kills you. Repetition helps the overhead is much less. You might find "aus house" under my name to be useful especially the multi versions that have a gap between two house big enough to drop in a different house to avoid the repetition look. Note that all assets with night mode have a second mesh.

Cheerio John
 
Instead of trees and grass, you can use textures like: Forest1, Forest_1 and Boeshung Moos, as they look pretty much 3D trees/schwubbery from a distance.
 
how do you interpret the stats? worst buffer count, then the kuid of that item, then to the right.it displays a number in parenthesis that should be below 2000?
 
so total buffer count is at the top, what is bad for individual? I get about 20 in a yard area, and that count is for some jvc grass
 
justinroth said:
how do you interpret the stats? worst buffer count, then the kuid of that item, then to the right.it displays a number in parenthesis that should be below 2000?
Click to expand...

I was wondering the same thing... What exactly are you looking for? And how do you track down the bad kuids by name to replace them? (Short of searching all installed items in CM by kuid - although, that may be the only answer...)
 
Don't feel bad guys about being confused. I can't quite figure out the vague numbers either. I test my route in Surveyor by walking the ROW using ALT+Y and moving along at ground level. If an area has the stutters, then I know there's something causing a problem. This also gives me a chance to look over the landscape and find any bumps and to find baseboards to cull out because they'll never be seen from the train.

John
 
Terrain and performance

Apologies if this is slightly off topic, but I have questions on two areas which relate to potential frame rate performance.

1. Is there any way of measuring the impact that ground textures are having on performance?
Presumably high resolution textures hit harder than lower resolution, as would excessive blending and over painting, particularly using small radius, but how can you measure this?

2. Does a complex landscape (before textures are applied) have a bigger hit on performance than, say, a totally flat board. With a flat board the z axis would be identical for all vertices, but would this allow the system to generate the terrain any faster?
 
I do a similar routine like John's. I pick a spot that has a good view of things and spin around in surveyor. If an area consistently stutters as it comes into view, then I do some reworking there. I found a grove of trees in the distance that stuttered as it came into view, so I replaced the whole lot and got rid of the stutter. Be careful though, spinning can make you dizzy if you do it long enough. :confused:

Andrew
 
mezzoprezzo said:
2. Does a complex landscape (before textures are applied) have a bigger hit on performance than, say, a totally flat board. With a flat board the z axis would be identical for all vertices, but would this allow the system to generate the terrain any faster?
Click to expand...

I doubt if land form makes much difference, each triangle still needs to be calculated and drawn irrespective of whether the resultant image is 'flat' or 'steep'....
 
Last edited:
Thanks for the response Andy.

I often wondered whether there was more of a delay in loading complex terrain compared with flat. I guess it just seems that way; high terrain popping into view is simply more obvious than flatter areas.

With regard restricted views, I always thought that anything beyond the immediate terrain could still be “seen” by the software, even if the camera view is being obstructed by foreground terrain.

This seems to be borne out by this view in Surveyor alternative wireframe mode, where the complex mountain ridges in the background at 3,500m distance can still be “seen” through the hill immediately in front of the camera.

I’ve tried turning around, backing off and navigating back up to the same viewpoint and the appears to be no cancelling and reloading of the “hidden” terrain. It seems to stay put.


mountainseethrough_zpsd595dc7e.jpg
 
Hi Casper

I have never seen a definitive comment from anyone who knows (Chris! they're calling you!) as to exactly how assets inside camera range and in line-of-sight but hidden from view by terrain or other foreground assets impact on performance.

My assumption is that those 'out-of-sight' assets are still loaded and calculated (how else does the graphics engine know they are out-of-sight?) but are not (obviously) drawn. My guess would be that the processor load was pretty much the same or possibly even higher, but the graphics load is lower. The question whether this adds up to a net gain or loss, or doesn't make a blind bit of difference still stands though. My hunch is that routes with naturally restricted views perform better because less 'stuff' gets drawn, but I would love to see a definitive comment on exactly how 'hidden' assets get treated...

Andy
 
Andy,

The program may use what's called back-face culling where only what's displayed in camera view is what is rendered. This keeps the load down on the system substantially when it comes time to render objects. I agree, Chris would be the one to confirm this.

John
 
You must log in or register to reply here.

Similar threads

F
What is the current wisdom on splines?
Replies
7
Views
966
frogpipe
F
C
Speed tree revelation
Replies
19
Views
5K
Cpt_Haddock
C
D
NV3 whats the future of Trees and shrubs for Trainz?
2 3 4
Replies
62
Views
15K
JCitron
J
G
How are the frame rates with 2019?
Replies
6
Views
1K
JCitron
J
T
TRS19 SP3 Release Candidate now available
2 3
Replies
41
Views
12K
capdiamont
C
Back
Top