How much detali?

[Approach_Medium]

Hi;
I'm working on a very large route, and am already seeing long (about 3min) save time, even on a system with a RAID0 array.
I am concerned that, when I start to add scenery (paint and scenery objects) to my route, the save time will become prohibitive, and that when I start running trains, performance will be low.

My system is 3.4Ghz Pent IV with GeForce 6800 250M video, 3G DDR RAM, RAID0 disk system running Win XP Pro.

I am just wondering how much detail other route builders have on large routes.
For example, should I restrict my detail to about 1 block from the RR lines, then just paint the ground and place occasional roads and buildings?

I guess much of this will come with experience, but since this is my first really big route, I have yet to gain that experience.

Thanks for any advice

FW

 

[Euphod]

For example, should I restrict my detail to about 1 block from the RR lines, then just paint the ground and place occasional roads and buildings?

I know the route designers at TPR follow this guideline, so I guess I would recommend it.

 

[lewisner]

The consensus of opinion seems to be that Objects are the cause of poor FS etc, so try to use Splines where possible.

 

[Euphod]

The consensus of opinion seems to be that Objects are the cause of poor FS etc, so try to use Splines where possible.

I question the validity of this advice. Splines will display "X" number of polys for each repeat, and use of too many can impede performance.

 

[HiBaller]

The DHR is a huge route in terms of content. We found right fast that having content sitting two KM away from trackside had a negative impact. With just a very few excursions away from trackside (schools up the hillside and the like) we give the impression of a lot more than was actually there. One item we used quite a bit was "false-fronted" buildings. Just a few polys each. We finally decided on this rule:

If it isn't within approximately 1 board or 750m from the track, then it doesn't get placed.

Effective use of background textures can also enhance scenery without adding any slowness. You might also consider using backdrops at the edges of a board.

Bill

 

[Dermmy]

Another endorsement of the '750meter max each side' rule of thumb, although on my Clovis Sub I pretty much stop at the railroad fence line!

Curious about that 3 minute save time though. I have done (or am doing) some pretty big routes and saves never take longer than a few seconds - well under a minute at any rate. One thing I have found is that always saving the route with a new name is quicker than saving over an old version, plus you have a series of handy backups if anything goes awry...

Andy

 

[2stepsteve]

I'm having the same questions floating around my head, I've done quite a large amount of detail on a 5km stretch of track. Each side of the track has detail that goes about 4 blocks back. The performance hit when i'm in that area is very noticable, mostly frame rates stutter into single figures.

I have to question the coding of Trainz and am i'm hoping Trainz 2009 will be more efficiently coded (but looking at TC3 maybe not?). Most objects aren't mega high poly count and the textures used on objects on the whole are quite low res and quality. Sure there can quite a high draw distance but i'm still left feeling conviced that trains could and should be running better. You just have to take a look at other PC games and how they run with the amount of detail in them.

 

[Dermmy]

Yes the graphics engine is out of the last century, but 'most other computer games' are not rotating dozens (possibly hundreds) of individual 3D models every frame...

Andy

 

[Approach_Medium]

Hi guys;
Thanks for the advice/help on this.
Thinking along the lines of poly count, etc; It would probably make sense to use high poly count objects trackside, then use low count further away. It wouldn't make sense to place any objects further than can be seen from the cab, unless you're trying to impress someone with the route as a whole.

As far as my save time, the route has 6298 TRS baseboard tiles.

Does the size of the route have anything to do with performance during Driver sessions, or would it be only the density of objects along the route being driven?
Another factor is that with a route so large, and so many RR lines, it is possible that I could have a dozen or more trains running at the same time. That would surely cause a performance hit.

Perhaps it's time to start trimming the route, better now, before I have done much work on it than later after I have spent lots of hours on sections I might throw away.

FW

 

[scorpio48]

Hi
If you are anything like me, route building involves quite a bit of deleting, adding and backing up.
I noticed that this can have a huge effect on your HD becoming badly fragmented, which leads to slower saving, loading times Etc, especially if you are over-writing files as opposed to saving under a new name.
We tend to overlook basic computer maintenance, so I would first check your HD for fragmented files.
In one twenty-four period of route-building I had to de-fragment my HD twice, for this very reason
Cheers
Pete.

 

[Approach_Medium]

Actually, I've got a handle on the HDD maintenance. I just purchased and installed Diskeeper 2008 Pro, and have it set to run in the background. I also do a MFT and paging file defrag every few days.

I may start trimming my route anyway. It's so large that I'll never finish it, and will never be able to run trains over the entire route simultaneously.
The nice thing though, about such a large route is that I won't have to build another for quite some time, as this one will keep me occupied.

I'm looking forward to TS2009, but at the same time, I am a little apprehensive about the higher poly count, as performance could be slower than in 06. I'm just hoping that the new program will be coded so as to be more efficient, and take full advantage of whatever the hardware has to offer.
Even CMP in TRS2006 is painfully slow sometimes. The promise is for a much better one in 09.

FW

 

[JCitron]

Actually, I've got a handle on the HDD maintenance. I just purchased and installed Diskeeper 2008 Pro, and have it set to run in the background. I also do a MFT and paging file defrag every few days.

I may start trimming my route anyway. It's so large that I'll never finish it, and will never be able to run trains over the entire route simultaneously.
The nice thing though, about such a large route is that I won't have to build another for quite some time, as this one will keep me occupied.

I'm looking forward to TS2009, but at the same time, I am a little apprehensive about the higher poly count, as performance could be slower than in 06. I'm just hoping that the new program will be coded so as to be more efficient, and take full advantage of whatever the hardware has to offer.
Even CMP in TRS2006 is painfully slow sometimes. The promise is for a much better one in 09.

FW

Have you tried running Trainz wth the Invisi-tasking turned off? I found that this added some overhead and affected the performance of my computer. I had a Quad-Core Intel with 4-G of RAM and two hard drives (no RAID). The video is currently and 8800GTS. So needless to say, I run a manual defrag just before using Trainz and usually at least once a week in between.

The other thing I forgot to mention is Antvirus programs can really slow down the performance particularly if you're saving large files. They tend to scan files when they are written to the hard drive. I have turned off the AV program when running Trainz for better performance. There's no reaon to keep it running if you're not on the web or disconnect your computer while running Trainz.

John

 

[Blackfingers]

Very large routes are all very well - if you've got the pc to cope. However, give a thought to the many who don't have the latest very powerful machines. Not a lot of point in publishing a route if many can't make use of it surely?

Ian L.

 

[Approach_Medium]

Thanks for the advice. I had forgotten about shutting down the AV. I can easily do that, but I like to shut down my network at the same time.
I'll try shutting down invisi-tasking.

I have started removing unneeded tiles from my route. When I created the map in Transdem, I had the filter set to 2 tiles, so I do have lots of unwanted tiles, especially around the corners of the route.

FW

 

[Dermmy]

Very large routes are all very well - if you've got the pc to cope. However, give a thought to the many who don't have the latest very powerful machines. Not a lot of point in publishing a route if many can't make use of it surely?

Ian L.

Size doesn't matter. Content is crucial. A huge carefully detailed route will run on anything. I single very highly detailed board will bring the latest whiz bang machine to its knees.

Running numerous trains on a large route has some hit on performance because the AI is keeping track of everything, not just what you can see. But that is just background number-crunching. The big performance hit in Traiz is video performance, and that comes back to content and detailing no matter how big the route or how many trainz are running out-of-screen.

Andy

 

[Bista]

HMMMMM! (furrow brow in a pensive yet frustrated manner)

I think I'm falling victim to this but in a slightly differnt way (see "upgrading to TRS2004/2006" thread for the whole horrid storey).

My Longwall layout spreads out over about 15 tiles (not many granted but bigger than I intended, ther's always that other bit you can add isn't there?) and while building in TRS2006 I kept popping into the quick drive function to make sure things ran ok and they did.

Then I added driver commands to the trains and boy what a mess, kinda reverse animation, all stop frame.

Now, most of the tiles are textured and there are a modest number of buildings to try and keep things down. I've put the main junction in a cutting (lined with splined wall to reduce the distance you need to see where the track is most complex) and the buildings are generally only those asociated with the railway (factories etc) with a a small representation of a couple of towns. This does mean some concentration of scenic assets but lets face it, if you have a station, you need a town. I have no reason to believe that TRAINZ passengers would be any more inclined to walk miles from an unseen town than real ones:hehe:

The thing is, these assets seemed to have no real effect on the frame rate when driving trains "manually" but as soon as I set up Driver Commands to keep things moving it went pear shaped. So pear shaped in fact it appears to have become a bannana which I seem to have stepped on in order to end up on my arse in the middle of this mess!

THe route is basically a double track figure of 8 with some separate freight lines and some interactive industries and stations. I though keeping some sections straight might help, at least from the driver cab view (I figured not having to keeping moving the landscape about the yaw axis might help) but it sems to pop and stutter around no matter where a train is heading. It even does it from static trackside cameras and the only thing moving there is the train and not the background so is the landscaping an issue?

Running initially from Driver with the draw distances turned down and the train polys lowered it runs slick as greased weasle poo, but change anything through Surveyor and you have to get out of TRAINZ altogther then back into driver to get rid of the stutter


HEEELLLLP!

Cheers

Bista

(Trying to make a virtual railway work better than the real one he works on!)

 

[Approach_Medium]

Very large routes are all very well - if you've got the pc to cope. However, give a thought to the many who don't have the latest very powerful machines. Not a lot of point in publishing a route if many can't make use of it surely?

Ian L.

Actually, I wasn't thinking about publishing this one. But perhaps I would be able to create a smaller version of the route, say from NJ to Selkirk, or maybe the Conrail Shared Assets in NJ (a lot of RR in a small area).

This project started out as the CSX Riverline from Jersey City to Selkirk, but gradually spread to cover a lot of NJT's lines. I think I should just have settled for the CSX line, or even just a part of it, but I have a habit of "biting more than I can chew" with things like this.
I am seriously thinking of paring the route way down now, and saving the rest for another time. I can do it now, since I haven't done much work with the Transdem generated map, and what I have done is in the area that interested me in the first place.

I'll have to experiment and see where I have to cut off to make it small enough for the DLS.
Thanks for the advice.

FW

 

[Approach_Medium]

Have you tried running Trainz wth the Invisi-tasking turned off?

Uh, er... what is invisi-tasking? Is it something in TRS, or in Windows?
FW

 

[Approach_Medium]

Size doesn't matter. Content is crucial. A huge carefully detailed route will run on anything. I single very highly detailed board will bring the latest whiz bang machine to its knees.

Running numerous trains on a large route has some hit on performance because the AI is keeping track of everything, not just what you can see. But that is just background number-crunching. The big performance hit in Traiz is video performance, and that comes back to content and detailing no matter how big the route or how many trainz are running out-of-screen.

Andy

That said, is it better to stick with a few good textures than to have 100 in a mix?
I like to mix paint textures like grass, dirt, etc to make a more realistic look, but if having so many textures causes a performance hit, then I'll keep it down.

Also, looking at my previous post, do you think my route with over 6,000 tiles is too big for any PC to handle, let alone for DLS?
I'm really starting to think about creating a really scaled down version right now, before I start detailing.

FW

 

[TheStoon]

Uh, er... what is invisi-tasking? Is it something in TRS, or in Windows?
FW

Its in Diskeeper.. its the technology that allows Diskeeper to run the background defrag.

Its supposed to watch and wait for the free resource rather than have it allocated by the OS. So if it needs access to the disk it waits until its idle before it uses it. Same goes for CPU/network etc. Hence Invisibile Multitasking.