PDA

View Full Version : Detail- are we trying too hard?



rumour3
January 10th, 2016, 10:12 AM
Prompted by a discussion elsewhere about track LODs not displaying correctly, or smoothly, it got me wondering if we're actually trying too hard with detail at the top level, and aren't getting the balance right between looks and performance. Looking at videos of the competition, track is often un-chaired, and no attempt is made to get the rail profile right- just a basic rectangular profile seems to be used, with detail done in the texture. Users seem to be happy with this. Whilst this means that a good Trainz track pretty much always looks better than the competition at close range, this advantage is, IMO, usually more than outweighed by a) generally very obvious LOD transitions and b) very poor performance in areas with extensive track. In big yards, it feels like the mesh swapping and LOD activity is just overwhelming the game engine, and sometimes making the wrong decisions, leaving us looking at low detail track under the train that we're focussed on. Use two or three different tracks and the problem seems to get worse. Whilst I guess that the engine is doing its best, are we trying to push things too far with detail for most routes, as things currently stand? Could fewer levels of detail and simpler 3D modelling but better texturing be a better answer in most real-world situations? Trainz is getting a lot of flack in some quarters about poor performance compared with the competition but it strikes me that the creators on 'the other side' have got a much better understanding of where to focus detail, and where to leave it out.

Track is an area where smoothness really matters, and so we really need to spend some time getting this right. Thoughts please?

R3

clam1952
January 10th, 2016, 11:00 AM
My thoughts exactly which is why my pre TANE NG track is using box section for the track and simple shape for the chairs that works with just three lod settings and unless you sit looking at the track all day looks fine.

I have little problems with visible transition by keeping it simple, couldn't do it using the actual rail profile which while it looks good close up using lod creates very obvious visible changes and doesn't do much for frame rates either.

JCitron
January 10th, 2016, 03:08 PM
I think this goes for a lot of areas besides track including commodities and interactive industries. I'm sorry to say but do we really need to "carry" goods inside boxcars when we can't see them? :)

John

martinvk
January 10th, 2016, 03:55 PM
While I agree with the conclusion, we all know that the moment low-poly objects are introduced, there will be howls of protests and even derogatory comments about how poor Trainz looks compared to [fill-in]. This one of those can't win situations unless you can find the perfect poly-sized objects. And with the wide variety of equipment out there, that will be different for everyone.

Dinorius_Redundicus
January 10th, 2016, 04:14 PM
@ Rumor3: You're probably right given the way the Trainz game engine currently performs. However, having seen how much better games like Assassin's Creed smoothly handle much higher amounts of 3D geometry, texture detail, visual effects and complex animated objects in enormous open-world scenes, I feel that it's the Trainz game engine that is sadly lacking.


.

VinnyBarb
January 10th, 2016, 04:26 PM
You're probably right given the way the Trainz game engine currently performs. However, having seen how much better games like Assassin's Creed smoothly handle much higher amounts of 3D geometry, texture detail, visual effects and complex animated objects in enormous open-world scenes, I feel that it's the Trainz game engine that is sadly lacking by comparison.

Or perhaps the coding side of TANE needs good programmers like you just outlined above. It is not only Assassin's Creed, it is much older games like Skyrim, Dragon Age, etc., just to name a couple, who years ago mastered the myriad of walking, and other animated objects, highly detailed scenery, flowing and sloping realistic water flow on rivers including very realistic waterfalls, reflection in water, windows, realistic shadows etc. in one given scene, just to name a few features, does show us what competent programmers could do already years ago.

This begs the question, why not in TANE?

My opinion

VinyBarb

JCitron
January 10th, 2016, 05:23 PM
We also have to keep in mind that many of these other games were developed with in-house specific content with 100% control over the assets right from the beginning.

When a company starts introducing user-created content, even with specifications and guidelines, the content is not the same. Users who use Cities Skylines are finding this out now with some of the assets made for that program. Recently there were complaints on the forum about Sketch-up models causing performance problems. Sound familiar?

So it's a case of damned it you do, and damned if you don't. People will complain that there's not enough detail and then complain that the performance is bad because the highly-detailed assets are dragging things down. Even in our virtual world, it's all about compromises when it comes to stuff like this. As much as we'd like a never-ending perfect world, where we can build for miles and miles in an unlimited fashion, we're still facing real world limitations with computer hardware even today with the fastest personal computers available to consumers.

John

Dinorius_Redundicus
January 10th, 2016, 08:48 PM
You can blame the assets if you like, and I agree most of those SketchUp things should be binned, but I'm far from convinced they are the major reason why Trainz can't handle detailed tracks.

As I said before, the assets in these other games have far, far more detailed geometry at close range than anything we usually see in Trainz, the textures have far greater resolution (and much more elaborate optical effects). The scenes can be densely populated with buildings, trees, crowds of animated people etc. and you can run through the world without graphics stuttering, mip-mapping disasters or objects popping. I get the impression that if all these game engines had to render was a Trainz scene, they would absolutely eat it up despite the typically non-optimized assets. You would need to see something like Far Cry or Assassin's Creed Syndicate (or any recent AC titles) to really appreciate what a well-designed game engine is capable of and how far behind Trainz is.

JCitron
January 10th, 2016, 10:04 PM
You can blame the assets if you like, and I agree most of those SketchUp things should be binned, but I'm far from convinced they are the major reason why Trainz can't handle detailed tracks.

As I said before, the assets in these other games have far, far more detailed geometry at close range than anything we usually see in Trainz, the textures have far greater resolution (and much more elaborate optical effects). The scenes can be densely populated with buildings, trees, crowds of animated people etc. and you can run through the world without graphics stuttering, mip-mapping disasters or objects popping. I get the impression that if all these game engines had to render was a Trainz scene, they would absolutely eat it up despite the typically non-optimized assets. You would need to see something like Far Cry or Assassin's Creed Syndicate (or any recent AC titles) to really appreciate what a well-designed game engine is capable of and how far behind Trainz is.

I can't say that it's just the assets either and there is some part that has to do with code efficiency in the game engine. This I think too is the issue with the track and the redraw aspects we're seeing, and not necessarily LOD. What I think is happening, and I maybe totally off out on Pluto somewhere, is the assets can't be assembled in real time fast enough to match the forward motion of the trains at speed so instead of the parts appearing instantly, or near instantly, there's a delay as the parts are added. Remember how the trees used to draw in clumps as we moved along in TS12? This is similar to what's happening with the tracks. Chris and the rest of the dev team need to look at this in more detail. Maybe this should be brought up to the top of the list as something that needs a bit more than a glance at.

However, these games that you speak of operate in a canned environment and not one that is so open that everything and anything can be added infinitely. The content too in these other programs is controlled by the developer and hand created by the developer. Remember in these programs, they have set a memory budget that these assets can work in and the 3d-artists and animators worked within this known budget.

We also have a set budget too to use, however, that amount seems to be a secret that only Chris knows and there's no mention anywhere of that amount to work with. Many times we've asked for a graph of some kind to show us worse offenders on a map maybe have something like a heat map. We have the profiler in T:ANE and the performance statistics that run real time, but for many content creators, let alone the rest of us, this information is written in programmer rather than being easily explained.

Maybe the budget is controlled per baseboard or per camera view. We don't know exactly. It's like going on a spending spree that seems to be totally unlimited only to get hit with a major bill at the end. We just don't know how much we have to work with and where the limitations are.

With some kind of tools like this, we could pin-point whose causing the problems and who is not, and maybe use this to thin forests out because we've used too many trees, which happens to be very common on many routes. Then again if the code was more efficient then this would be less of a problem as well. Like a lot of things around here, it's all clear as mud.

John

WindWalkr
January 10th, 2016, 11:14 PM
There's nothing particularly fancy going on here. It's difficult to find a detailed breakdown of the polygon count across all the current-gen games. If you know of any for the recent AC games then I'd be interested to hear it. Infamous: Second Son has been quoted as rendering over 11m polygons per scene, and it's certainly quite a pretty game. Even assuming that's accurate, we don't know if that's the cost of the raw geometry, or a sum of all render passes. Assume the latter. Let's compare that with Trainz. A random view from the creek in Thurmond Empties using the preview tool with 6k draw distance, most settings turned up: 17m triangles, 583k objects in scene, 3.4k animated objects. I think it's reasonable to say that Trainz is keeping up in the "heavy scenes" department.

The real question is not whether we're capable of rendering heavy scenes; a scene in Trainz is quite often much heavier than a scene in a triple-a game. The real question is whether we're making efficient use of resources. For example:

* If we're rendering objects which are fully occluded behind a mountain, we're wasting resources.
* If we're rendering thousands of polygons for an object which is kilometres from the camera, we're wasting resources.
* If we're using lots of polygons to achieve a given visual quality, but with better models we could achieve the same visual quality with less polygons, then we're wasting resources.
* etc.

In each case, there are obvious solutions, however these solutions are not cheap. In the T:ANE kickstarter, you guys put in something like $190k (for which we are very grateful; you gave us a chance to take on a big project like T:ANE which would have taken much longer without your support.) On top of that, numerous content creators contribute their time and effort for every single version of Trainz. But to keep things in perspective, GTA V has a budget estimated at $300m. Neither programming nor art is cheap.

In short, it's quite possible to make Trainz look just as good as any other game, but if you're comparing a $1m game which spans thousands of kilometres, with a $300m game that spans just a few tens of square kilometres, you can expect that the visual quality in any random location is going to be a bit different.

That's not to say that we shouldn't continually improve over what we have. Content creation skills, content creation techniques, and the engine capabilities which back these techniques can and should all be improved. T:ANE is a pretty good step in this direction, but it's only a step and the path is never-ending.

chris

martinvk
January 10th, 2016, 11:33 PM
Those other games mentioned that have such incredible rendering are closed environments vs Trainz which lets you do just about anything in a scene. Want to add thousands of high poly trees, no problem, multiple buildings with various inefficiencies, sure, lots of ground clutter, etc. why not. And then they complain when the rendering engine stutters.

It's the freedom to do whatever you want that is the major Achilles heel of Trainz. If Trainz were to restrict what objects can be used and how many can be placed in any one scene, they would probably have just as fantastic rendering. But what fun would that kind of Trainz be? I would rather have the freedom and run the risk of overloading my route than play with a straight-jacketed game.

WindWalkr
January 10th, 2016, 11:44 PM
However, these games that you speak of operate in a canned environment and not one that is so open that everything and anything can be added infinitely. The content too in these other programs is controlled by the developer and hand created by the developer. Remember in these programs, they have set a memory budget that these assets can work in and the 3d-artists and animators worked within this known budget.

We also have a set budget too to use, however, that amount seems to be a secret that only Chris knows and there's no mention anywhere of that amount to work with.

Nope, no set scene budget. If you add more detail to the scene, the game will run slower. I could make one up for you based on our recommended hardware spec and settings, but at the end of the day who am I telling? The guy that is building the ten-polygon house? He could build houses all of his long life and not come close to the limits. The guy that's building the route? He possibly doesn't even know what a polygon is. The problem with the concept of a "scene budget" is that it is generally assumed that everyone working toward the "scene" has bought into the budget, and that you have some managers who are carefully negotiating how much of the budget may be used by each person on the team and for each component of each scene in the game. That isn't the scenario that we're in, so the concept starts to fall over.



Many times we've asked for a graph of some kind to show us worse offenders on a map maybe have something like a heat map.

T:ANE includes quite a few new tools to help give performance feedback. T:ANE SP1 especially, with the asset preview tools and Performance Analysis mode. We've also been working on a heat map tool (which I've talked about and screenshotted before) but I don't feel that it's useful to release in its current state. Among the problems with this tool are the sheer amount of time that it takes to profile a typical Trainz-scale route. When testing with the tool, I typically leave it run overnight for a single run. It's the kind of tool that would be amazingly useful i you could simply press a button and get a snapshot back, but you're talking about 10+ hour turnarounds and then you start to realise that you need to run it on different machines, and for multiple runs with different quality settings, and that the sampling frequencies used for one route might not be appropriate for a different route. And at the end of the day all you really get back in most cases is "this whole map is too heavy" which you could have determined by looking at the FPS indicator after loading it up the first time.

That's not to say that it's completely hopeless, just an explanation of why we don't simply slap together a tool like this and release it. I still hope to release the heatmap tool in some fashion once we've added enough features that we feel it's actually going to be worth the long turnaround time.




We have the profiler in T:ANE and the performance statistics that run real time, but for many content creators, let alone the rest of us, this information is written in programmer rather than being easily explained.

I agree. Unfortunately, there's no simple solution. Polygon count is only loosely correlated with performance. If we simply gave you a polygon count number and everyone built perfectly to that, we still wouldn't necessarily have good performance. It's a complex subject, so if you want to understand it, you need to learn how to read the information. I won't claim to be a particularly good teacher, but I'm doing what I can to get that information out to our users.

The good news is that most of this isn't Trainz-specific, so if you're really interested in this subject, then you don't have to rely on my explanations and you can go out and read game development and optimisations articles elsewhere. I would caution you to read detailed articles which discuss specific cases, rather than forum posts commenting on whole games- the latter has an unfortunate habit of being wrong. Some developers write post-mortems or GDC papers about their work, which can often be really interesting.


kind regards,

chris

pcas1986
January 10th, 2016, 11:50 PM
Getting back to the point about track: Yesterday I tried my hand at making a video capture for one of my sessions and, as part of that, I was jumping between drivers. The most noticeable issue was the very delayed rendering of the track. The scenery and consist were rendered almost instantaneously but the track was a distant last. This issue was talked about during recent beta discussions but I know that a later version made it better. I was using the ECML route for testing and the flow of track LODs was much better in the later version.

So, when creating a "new scene", for want of a better term, in what order are assets rendered? Just to be clear, by new scene I mean creating the scene after a different driver/consist is picked.

BTW, I was running 80330 from an SSD installation. I regularly get 60FPS when running sessions.

My attempt at video capture was very ordinary so I've given that activity the flick.

WindWalkr
January 11th, 2016, 12:15 AM
This issue was talked about during recent beta discussions but I know that a later version made it better. I was using the ECML route for testing and the flow of track LODs was much better in the later version.

The track in question was adjusted to favour appearance over performance. It now costs more, performance-wise, but since it's only one object out of the whole scene, that doesn't appear to make too much difference overall. Visually however, it's very noticeable.



So, when creating a "new scene", for want of a better term, in what order are assets rendered? Just to be clear, by new scene I mean creating the scene after a different driver/consist is picked.

* The objects that we want to display are placed onto a list.
* The list is sorted by distance from the camera.
* We then allocate a certain amount of time per frame to preparing the objects for loading, determining whether they've finished loading, performing any setup, etc.
* Resource loading occurs in sorted order, but keep in mind that once a given house is loaded, we don't need to reload that same house for each instance in the scene- so if a house is near the camera but also has instances far from the camera, they may all load at the same time. This includes loading the geometry and textures to the GPU.
* After loading is complete, stitching may be necessary. This is processed in roughly request order, but when many instances are processed in quick succession which can all be stitched together, the result may be delayed until all the objects have been processed, rather than repeating the stitching individually for each new object instance that is processed. We may also delay stitching in some cases to avoid negatively impacting something else which is already in the pipeline.
* The stitched results are then uploaded to the GPU. This is rate limited because the GPU typically can't render while receiving new data from the CPU, so it introduces stalls.
* Some types of data are loaded at lower LOD initially, and then this is increased to the appropriate level once the system is under less load. This allows us to show the scene more quickly prior to paying the full costs of loading the higher-detail data. In most cases this looks better, because having a few things at lower detail temporarily is better than having things missing entirely.

hth,

chris

rumour3
January 11th, 2016, 01:02 PM
Thanks for the replies, all.

Chris, I understand the point that T:ANE is shoving a lot of generally very un-optimised data around, and that this will inevitably cause most systems to bottleneck in certain circumstances. The specific thing that prompted the question was what is happening from around 4.00 mins onwards in this video:


https://www.youtube.com/watch?v=B2gHzVwnjbA

In particular, the game engine just sticks at the low detail track and doesn't appear to make any attempt to draw a more detailed version, even though it is under the player train, and on the current path. This is the same concrete sleeper track that is used in the ECML. Up until this point, the game was doing a reasonable job of keeping up with the track LODs but the massive yard at Old Oak Common, to the right of the train, seems to be where the performance problems really start. This was what prompted me to suggest that we might want to think about good looking, lower poly track. If we can't prevent the game engine from doing this under load, then IMO we need to rethink the lowest LODs and perhaps go back to something like the old mesh reducing track, which at least had rail geometry at the lowest LOD. If we need to sacrifice some detail at the highest LODs, to allow for modelled rails at the lowest, then this might be a reasonable price to pay at this current point in Trainz development.

R3

JCitron
January 11th, 2016, 01:24 PM
Thanks for the replies, all.

Chris, I understand the point that T:ANE is shoving a lot of generally very un-optimised data around, and that this will inevitably cause most systems to bottleneck in certain circumstances. The specific thing that prompted the question was what is happening from around 4.00 mins onwards in this video:


https://www.youtube.com/watch?v=B2gHzVwnjbA

In particular, the game engine just sticks at the low detail track and doesn't appear to make any attempt to draw a more detailed version, even though it is under the player train, and on the current path. This is the same concrete sleeper track that is used in the ECML. Up until this point, the game was doing a reasonable job of keeping up with the track LODs but the massive yard at Old Oak Common, to the right of the train, seems to be where the performance problems really start. This was what prompted me to suggest that we might want to think about good looking, lower poly track. If we can't prevent the game engine from doing this under load, then IMO we need to rethink the lowest LODs and perhaps go back to something like the old mesh reducing track, which at least had rail geometry at the lowest LOD. If we need to sacrifice some detail at the highest LODs, to allow for modelled rails at the lowest, then this might be a reasonable price to pay at this current point in Trainz development.

R3

Maybe in cases like this we need to use a matching spline track for yards and other complex areas, and restrict the Pro-track for the points and the mainline. This would be like we used to do with 4m versus 2m (or was it the other way around) type tracks back in the TRS2006 and before days.

This isn't an ideal situation, but it may help with the performance.

John

rumour3
January 11th, 2016, 05:24 PM
Now, here's a thing...

I dusted off my old UK Bullhead track (the Mesh Reducing Track version, with simple near and far LODs). Reskinned it with a 2048x2048 texture based on my later Bullhead tracks (far too big, I know, and I could easily halve this, but it was an experiment) and swapped it out for the concrete sleeper track in the Westbury route. I'll need to test this more thoroughly, but it looks and seems to perform pretty good. Can't see the LOD transition, and the overall look is close to the 09 version, but at only 214 polys for the high detail mesh and 18 for the low, it's really got me questioning whether all the extra hassle of current LOD models is worth it. I'm going to experiment a bit more, but perhaps there's a case for bringing back Mesh Reducing Track? As things stand, I guess that I couldn't up-version this far enough to upload it but for other creators out there, maybe give it a go using a hi-res texture on my UK Bullhead (kuid:79563:1042) and see what you think?

R3

pcas1986
January 11th, 2016, 06:32 PM
I substituted the Auran Oak Track in one of my routes with a procedural track I made for LOD testing. My procedural track has red coloured LOD0 track parts, yellow at LOD1 and blue at LOD2. There is a LOD3 but this is hardly every visible.

This is a screenshot during a session:

http://i1188.photobucket.com/albums/z410/casper131/Ashampoo_Snap_2016.01.12_10h15m19s_003__zps7uy9xic g.jpg

The LOD0 track only shows immediately under the loco apart from the odd LOD0 sleepers that seem to be used as fillers when rendering. When driving the train in the exterior view and looking forward the LOD0 track is hardly ever visible.

I think LOD0 procedural track meshes should only be viewable at very close range, say 5 metres at max. Currently, I have this particular track set at 10 metres.

WindWalkr
January 11th, 2016, 07:26 PM
In particular, the game engine just sticks at the low detail track and doesn't appear to make any attempt to draw a more detailed version

Try increasing the detail update rate in the (launcher) performance settings.

chris

rumour3
January 26th, 2016, 10:38 AM
Chris

I've not come back on this because been doing a lot of experimenting in the meantime. Even on ultra settings it's still too easy to 'overtake' the game engine and be left looking at the low detail mesh for unacceptably long periods, sometimes without any sign of the high detail mesh appearing. If we're stuck with this behaviour it suggests to me that the low detail mesh needs to look significantly better, and, as a minimum, it needs to include modelled rails. The 'textured plane' with no rails that many tracks use for the lowest lod looks far too noticeable on the frequent occasions that it is seen too close. My current track has 32 polys for a 12m length at the lowest LOD, 20 polys per 4m at the second level and 222 per 4m at the highest LOD. This seems to perform reasonably well, and the lowest LOD still looks reasonable if I do manage to overtake the LOD transitions when whizzing around the route. I know the argument that you can't see rails at 15KM draw distance but unless the game code can do a better job of keeping the lowest LOD out of close-range view I think the additional 12 poly per length overhead of modelled rails is worth the performance hit.

Incidentally, it looks like T:ANE just ignores the lowest mesh on old mesh-reducing track assets, so any performance benefits I was getting appear to be due to the 'low poly' nature of the detailed asset.

R3

Kevin16c
February 4th, 2016, 11:24 PM
I'm unable to check this myself at the the time of this post, but out of curiosity does T:ANE attempt to draw the lod0 segments while at track speed? Say we are moving at say 60+mph does the game engine, when the camera is close to the track, attempt to swap in the lod0 meshes? If so, would it not be more efficient to elect for a lower lod such as lod1 while at speed to offset the redraw costs since when at speed you don't have time to admire that expensive lod0 mesh? In other-words, if its not already implemented I'm suggesting track the speed at which the camera is moving and as the speed increases past a certain threshold we start ignoring the lod0 and use lod1.