News from the Trainz Dev Forums.

JCitron

Trainzing since 12-2003
We've been discussing this in the Trainz Dev over the past few days on how best to keep the rest of the community up-to-date on the goings on in the Trainz Dev forums. We know that the information there can be a bit daunting and overpowering to understand as it is a bit on the technical side which it has to be, so asking the rest of the community to go read the information is not quite what I would want, though many of you are probably quite capable of understanding this stuff.

As a group, we have no timeframe on patches or updates. We are only the lab attendants testing the vials as they come to us for testing. These test builds that we see, are just that, test builds, like those vials of stuff in the lab. What we see may never, ever make it out to a patch, or may appear in the future as part of a new product. There maybe things in here, that will be mentioned, that are just to try out a concept or tweak, which may or may not work. There are also things in here which are really cool too and we hope they do make it to a future build. When is the question? We really, really don't know. By saying this, I hope I'm not laying any expectations on things that may or may not happen as I don't want to disappoint anyone, including myself.

Keeping this in mind, here's what's been going on.

The latest build as of 6 August is Build 77730. This build was issued for us to check various things including the crashes to desktop, continued checking of LOD, CM and other issues. Yes almost unmentionable crashes, those bugger things which have been killing all of us and eating our data, or worse corrupting our routes we have had open at the time. This current build is by far the most stable in this respect. Many of us were able to work for hours in Surveyor and drive many kilometers with no crashing. Now even though I didn't experience any crashes, it doesn't mean they won't exist as Murphy is right there to ensure that so we're continuing to test for these.

In this regard, I spent 99% of my time, this time around, in Surveyor doing exactly what caused the retail version to crash, performing such things as replacing textures, assets, zinging around the route quickly, zooming in and out as I worked on an actual copy of my 500-mile merger route I brought over from the retail version. Yes, I did a complete clone of the database so I have everything, including stuff I imported from TS12 to work with so I can keep apples to apples comparisons instead of working with only a bit of test data.

There have also been some nice additions to the replace assets tool, which I surely hope appear in the future. In this build there is the option to delete assets. Yes! It's a percentage slider, but assets can be removed. Simply drag the asset to be deleted in to the replace asset box from the Surveyor asset-tabs on the right, set the slider to 100% and hit the Replace button... All gone - banished to bit heaven! :D On this same interface, there is now a progress bar too so we know how much is being done and the program hasn't gone off to visit a dead relative somewhere else.

Other things include a random asset placement tool. Pick a tree for example, and let it do its thing. You'll find these objects placed randomly on the route or in areas. Oh I forgot. On the replace assets tool too, there's that option to select a baseboard, whole route, and now a selected area. Nice!

The performance overall has been tweaked. I set my system to 8000m, high details, textures, trees, and medium shadows, plus the other advanced 'developer' settings, which I need to focus on more to learn more about them. The good news with these settings, I saw excellent frame rates, at least in the 30s and 40s on my pretty heavily forested route, and higher in the open areas. The temperature was quite reasonable too, meaning the code has been optimized. Yes, there was a spike when data is first loaded, but once everything is in place, the fans kick in and the temperature moved down into the high 50s-to mid 60s instead of remaining pegged at the maximum of 83C for my video card. This is the same setup as on my retail build so I felt pretty good with this.

There are bugs too, more than before like weird things in the preview window when looking at assets in surveyor asset tabs where assets hang to the right side. In driver and surveyor, the red and green junction lever arrows are missing. The switches work fine, but there is no indication which way they're facing. Other things too such as slower and slower performance too. Things start off really great then get a bit piqued by the end of the day. I will say I was replacing a gazillion trees on this 500 mile mega merger route, one that takes a full 4 hours to drive. I think this maybe the route that's at fault here as there is a lot of content. Further testing and confirmation is needed...

Content Manager has gotten hotkeys. Yes, we can Ctrl-something instead of mouse-clicking everything. These still need a bit of tweaking but the ones I tested worked fine. I'll let others report more on this. There are also more errors reported in this build that weren't in the previous one, or even in the retail build. There are numerous areas here, but mostly LOD-related errors which are in some cases false reports along with other false error reports.

In general there has been more testing is being done with LOD and this is still ongoing.

People are probably wondering why this is important. LOD really is important when it comes to performance as well as visually within the simulator. LOD helps eliminate the stuttering and stumbling we're so used to seeing in T:ANE now and in previous Trainz versions. LOD, aka Level of Detail, means an asset will have multiple meshes that sit in the same place, like those boxes in a box, inside a bigger box. Unlike those real boxes, each smaller version has less detail on it. Eventually, there is nothing more than a flat image to represent the train car or building the farthest away from the main object. These different objects are called targets that are placed invisibly and called up automatically at specific distances from the main object. What this does is allow for objects to render smoothly over distance. Without this objects will pop up suddenly, which causes stuttering and other performance issues. Besides, it looks awful too when buildings or trees suddenly appear in view, for example. But this has to do with more than just fixed scenery objects. Track and others splines, especially are really affected by this. How many of us have downloaded track that causes such awful performance and jumps into place. The same with grass splines, telegraph poles, fences, and other things. By requiring the targets be there and the placement enforced, unlike in other versions of Trainz where the content creator neglected them or did them poorly, this will ensure much better performance than ever.

And finally, other discussions, all on going, on attachment point issues, mesh stitching, performance, scripting (with lots of extra details) and even super elevation.

I am very sure my teammates in the Trainz Dev will have more to add to this, and hopefully we can continue with the updates on a frequent basis. Yes, T:ANE is moving along in the right direction even if it doesn't appear that way.

John
 
Thanks John for starting this off. Can I make a suggestion to take back? At present when we want to rotate or raise/lower an asset we have very limited control over it. It can often be a right pain when you need fine control. So could something like a box where we could directly input the value of rotation/raise/lower be implemented at some point?
 
Thanks John for starting this off. Can I make a suggestion to take back? At present when we want to rotate or raise/lower an asset we have very limited control over it. It can often be a right pain when you need fine control. So could something like a box where we could directly input the value of rotation/raise/lower be implemented at some point?

I think maybe we can setup another thread for suggestions, questions, etc. As this is out of the scope of the topic, though questions related to the build testing and the build as we see now are fine.

It's not that I wouldn't want to see this option either, as I definitely agree with you, but perhaps something on the line of the suggestion boxcar, but for T:ANE only might be better suited for this.

John
 
Thanks John for starting this off. Can I make a suggestion to take back? At present when we want to rotate or raise/lower an asset we have very limited control over it. It can often be a right pain when you need fine control. So could something like a box where we could directly input the value of rotation/raise/lower be implemented at some point?

I agree that a finer increment of movement is needed. Really nice assets need proper orientation and placement.
Thanks for the update. Enlightening and encouraging!
 
Thank's for the heads up John it's appreciated,after reading through your post I understand the priority of the bugs TANE crashing ect....TANE has never crashed once even the pre betas
and I think Im up to about 400th edit/save how lucky is that:)

I'm really enjoying the new engine and route buiding again and have started making my own assets so i'm busy,was just wondering if there is any news on assets that use the new DX11
lighting effects e.g streetlamp that uses per/pixel lighting effect someone from NV3 said some would be included in the next patch,some nice dim lamps would be great and has the headlights
(to bright)been dimmed down.?

Many thank's

Daz
 
There have also been some nice additions to the replace assets tool, which I surely hope appear in the future. In this build there is the option to delete assets. Yes! It's a percentage slider, but assets can be removed. Simply drag the asset to be deleted in to the replace asset box from the Surveyor asset-tabs on the right, set the slider to 100% and hit the Replace button... All gone - banished to bit heaven! :D On this same interface, there is now a progress bar too so we know how much is being done and the program hasn't gone off to visit a dead relative somewhere else.

I've been wanting something like that for some time! The big issue I'm having with the LOD's is that at some of the procedural junctions, everything except the switch blades show up. They do appear when I move or tweak the track, though...
 
I've been wanting something like that for some time! The big issue I'm having with the LOD's is that at some of the procedural junctions, everything except the switch blades show up. They do appear when I move or tweak the track, though...

These are still being tweaked and improved. Maybe we'll see something more as people work with the procedural track and make things better.

I hear ya on that replace assets/delete. I'm crossing my fingers on that one as that really was awesome to be able to do that.

John
 
This will bridge us to those who are hardcore technie from the Dev Trhead -- Have not read your entire post above yet, John, as I just stopped by and took a glance, since I have little's one roaming around on the pc next to me doing their ABCMOUSE activity, but later on will digest every word, promised! LOL :hehe:

Well done, sir --
Me thing you've taken the lead on this, and that's a good thing!:D

Ishie
 
Thanks John for the summary. I think more of this is what we need. It would be good if N3V had done it, but in lieu of that, this I think works well.

@Antony Et al RE Finer Placement Control
I have found that sometimes, under certain conditions, Holding the Shift Key will actually move things a bit slower. Ctrl will actually make things snap to Grid Positions when you're placing things. Its not perfect, and I think having the option to input Decimal's better would help (There still seems to be issues with Inputting Text, which drives me CRAZY), but try holding Shift during Placement and Elevation Movements and see if that doesn't help some.

-Falcus
 
:) Good work and much appreciated! Both ideas - this thread and a suggestion thread are good. Both should be sticky so we can follow from day to day!

pdw
 
Good Morning John --

Read, and things across the horizon looks encouragement, especially the performance of load time, which is the number one issue that I always look at --- the fast it loads stuff the better! --- Just curious tho, how does it scaled up to those items made from SketchUp, etc ? -- If you're permitted to answer that, that is!

Thanks in advance
Ishie
 
Thank's for the heads up John it's appreciated,after reading through your post I understand the priority of the bugs TANE crashing ect....TANE has never crashed once even the pre betas
and I think Im up to about 400th edit/save how lucky is that:)

I'm really enjoying the new engine and route buiding again and have started making my own assets so i'm busy,was just wondering if there is any news on assets that use the new DX11
lighting effects e.g streetlamp that uses per/pixel lighting effect someone from NV3 said some would be included in the next patch,some nice dim lamps would be great and has the headlights
(to bright)been dimmed down.?

Many thank's

Daz

Good question, but sadly I'll leave this one for the other guys. It's probably best asked in the Content Creator's forum. I have a feeling that many of these effects will be improved over time and implemented as the post processing and lighting is improved. I remember reading somewhere from Tony that this area is still WIP even at the current release.


Good Morning John --

Read, and things across the horizon looks encouragement, especially the performance of load time, which is the number one issue that I always look at --- the fast it loads stuff the better! --- Just curious tho, how does it scaled up to those items made from SketchUp, etc ? -- If you're permitted to answer that, that is!

Thanks in advance
Ishie

I sure can answer this, at least I can try!

SketchUp models are SketchUp models and suffer the same problems. They come into T:ANE without problems but their performance is still poor because of how they are constructed. I found they can be used but sparingly, meaning don't fill a complete city with them, but mix one or two, or may three of them in a given area with other models and things load okay. The current build 77730 is better at handling these, but like hot peppers they are best used in small quantities. :)

John
 
Good question, but sadly I'll leave this one for the other guys. It's probably best asked in the Content Creator's forum. I have a feeling that many of these effects will be improved over time and implemented as the post processing and lighting is improved. I remember reading somewhere from Tony that this area is still WIP even at the current release.




I sure can answer this, at least I can try!

SketchUp models are SketchUp models and suffer the same problems. They come into T:ANE without problems but their performance is still poor because of how they are constructed. I found they can be used but sparingly, meaning don't fill a complete city with them, but mix one or two, or may three of them in a given area with other models and things load okay. The current build 77730 is better at handling these, but like hot peppers they are best used in small quantities. :)

John

John -- :wave:

Then I do wonder, John, if these items can become a serious issue later down the road -- If TANE, with all it's tweaks and stuff, can handle these heavily poly items, but still yet they behave the same way, so then who to say that we might not be here a year from now back to square one, in terms of TAME loading performance problems?

I just wonder if an asset will ever have a mb limit that can be uploaded to the DLS -- After all, that was always the problems of the passed that things where uploaded unnecessarily right, but yet they still work! -- get the meaning? A different type of standards can easily be introduced in later years to handle these heavily poly items! ...

I know, this is more of a speculation, and I' m not sure if it merits such speculation on this thread, so I'll leave it to you, sir to answer here, or let me know otherwise if the question needs to be post elsewhere.

But don't get me wrong, because I have use and seen some great sketchup's items, still yet, scare to use them in bulks, and even more nervous to use them now that its' clear that even in TANE these items will not change their behavior, there goes my day, LOL ...

Anyhow, sir, thanks for answers! :)
Ishie
 
John -- :wave:

Then I do wonder, John, if these items can become a serious issue later down the road -- If TANE, with all it's tweaks and stuff, can handle these heavily poly items, but still yet they behave the same way, so then who to say that we might not be here a year from now back to square one, in terms of TAME loading performance problems?

I just wonder if an asset will ever have a mb limit that can be uploaded to the DLS -- After all, that was always the problems of the passed that things where uploaded unnecessarily right, but yet they still work! -- get the meaning? A different type of standards can easily be introduced in later years to handle these heavily poly items! ...

I know, this is more of a speculation, and I' m not sure if it merits such speculation on this thread, so I'll leave it to you, sir to answer here, or let me know otherwise if the question needs to be post elsewhere.

But don't get me wrong, because I have use and seen some great sketchup's items, still yet, scare to use them in bulks, and even more nervous to use them now that its' clear that even in TANE these items will not change their behavior, there goes my day, LOL ...

Anyhow, sir, thanks for answers! :)
Ishie

This is an interesting question and this might be related.

There are some trucks, by whom I can't remember who created them, that are extremely high poly. The mesh and textures were about 176MB, and though they loaded up in TS12 like a baby whale sucking down a bucket of fish, T:ANE CM barfed and would not allow the asset to load. It didn't crash, but it wouldn't load the model. I can't remember the exact error and the thread is mentioned somewhere in the Trainz Dev forum. This I think is a good thing as the assets on the TS12 install would cause such awful stutters that the game would choke and halt.

Yes, the SketchUp models will load, just as in TS12, but the problem is the overall load on the program just as in TS12. You see SketchUp is a different beast. The meshes themselves aren't always very high poly, though they are higher than we would like in most cases even for a simple cube. We well get back to this after. The problem with these models is how they are put together as a whole, and this also relates to the texturing.

The latest modeling requirements, now I'm going by what I understand and I hope I've got this right, require UVW maps instead of individual textures like in the old days. This makes the models far more efficient as the texture is loaded up into memory in one shot and the mapping coordinates determine where the texture is. I picture this as having a decal sheet with each picture on it that the internal parts of the program know where to place the different images. With SketchUp this is different because it's not producing the models for animation, and instead just puts the individual texture bits that are assigned to the mesh in various places in the old-fashioned way of modeling. This might be an artefact of the model exporter, but I'm not sure. Sure this is great if you're making a pretty object, one that will sit there in a still image and everyone will admire, but if you put this in an animated, interactive environment, where everything is constantly being redrawn we have a problem because each and every one of these textures has to be loaded up, again and again each time the object is viewed. The mesh loads up into memory, but the textures are constantly loaded as tiny bits. Some might be cached, but not all. The meshes too are in a gazillion pieces as well which need to be loaded up too. There's a lot more complexity to these simple models than there should br. :)

Now getting back to Sketchup meshes. Don't get me wrong, there's nothing wrong with the modeler, but it's not the best tool as we've found out to make the totally efficient models we need. The meshes in SketchUp are different. They are either B-spline or Nurbs model-types; I can't remember which and sometimes get the two mixed up. Unlike old GMax and Max, Lightwave, or even Blender, these are not polygons in the sense that we think of. If you were to make a box for example in Sketch-Up, you will have a single poly. I think of this as a tarp on a simple frame. All surfaces are done this way whether it's a cube, n-gon, sphere, etc. Each one is made like a big tarp or sheet that covers the frame. Now here's the problem. Trainz and many other programs use polygons so these models have to be converted to polys to work. When these big sheet surfaces are broken up into polys, we have lots of them. The surfaces too, become individual strips with individually placed textures due to how the model is built and possibly the exporter, which only add to the complexity of the model. So instead of having a single model mesh with a single texture map, we now have the equivalent of multiple models in a single place. This is why the models also perform poorly. The program has to load up lots of bits instead of a single model. Sure locomotives and other models are made up of many parts, but they are handled differently internally, and they make use of attachment points to hold the individual sections in place instead of just creating a single object semi-glued together.

There are workarounds for this which some people have done. Perhaps they will speak up and contribute some details on this. Instead of taking the SketchUp model out of SketchUP and plopping it right into Trainz, some people have exported the models into Blender. With the model in Blender, they have cleaned up the meshes, simplified the models, and unified the textures on a single UVW coordinate texture map.

Keep in mind, that this issue is not just common to T:ANE or Trainz in general, and not just with SketchUp. Any 3d-rendering program that is animated will face the same problems. A good example is that new Cities Skylines by Colossal Order. Some people have already started importing SketchUp models into the program. At first glance this is a great idea, however, as it turned out there were reports of really bad performance, pop-up models and stuttering. People have also imported those really nice, awesome vehicles from Turbo Squid. They too have caused problems both in CSL and in Trainz in a similar fashion, but due to the overly complex meshes. Hmm... Sounds familiar. :)

I hope this helps and I think it was a good question asked here. Hopefully some others can help explain.

John
 
Thanks John for your detail explanation of the matter! :udrool:

On a side note: I am surprise somewhat that more folks around here haven't asked more questions about this subject, as this is one issue that will effect performance in trainz, and it seems that will not change in TANE! :(

Take care now, John
Ishie
 
Thanks John for your detail explanation of the matter! :udrool:

On a side note: I am surprise somewhat that more folks around here haven't asked more questions about this subject, as this is one issue that will effect performance in trainz, and it seems that will not change in TANE! :(

Take care now, John
Ishie

Sadly it's because it's how these models are made and as I said it's not just T:ANE that's affected by the problem. Other 3d-interactive programs have the same issue. It's the very nature of the little beasts coming out of Sketch-Up.

One of the things I noticed with a Sketch-Up model is how the model is divided into sections. A tall building I exported had lots and lots of .IM files. Each one of these .IM files corresponded to a section on the office tower, and each strip contained a gazillion individual window images. It's all this overhead that's causing the problems and it doesn't matter how good a program is to read the data, it still has to be loaded, processed, converted, and spat out in real time on the display.

This has been asked in various places in the forums, but now it's stickied in one place. Thank you for asking.

John
 
Back
Top