Removing reliance on MSTS default route data.

[hminky]

Well, 3DCanvas, I've been told, IS supposed to open TSM source files (I asked the good folks at Amabilis about this directly). Now, I haven't done it, and I haven't spoken directly with someone who has, but, well, there it is. I don't know if texture mapping is preserved or not (with some of my models, I really would cry if I had to re-map them).

I have the free trial version of 3DCanvas, have sat down with it a couple of times. I just need to break down and buy the full version and play with it. My birthday IS coming up...

Steve

I just opened the example TSM Seico boxcar in 3d Canvas 8.2 and if you move the texture file into the same directory the textures come with the object. I also opened an S2 that I don't remember where I got it from and it opens with almost all the textures.

Harold

[SurvivorSean]

There are a couple of things in particular I would like to see that are used on similar simulators. Perhaps another thought of course is what I would like to see. I'm already coding my own operations standard in RTS in Visual C# and may at some point contribute to the project. Signals, dispatching, multi-player are all mentioned as something either in progress, or planned in the near, and far far future (which to me is better than not mentioning it at all). But there are 2 things that I haven't seen that I would love considered for ORTS roadmap:

LAYERS:
Based on my understanding of Flight Simulator scenery can be added to the world in layers such as you would see advanced paint programs apply layers etc. The purpose of that is if someone wanted to add advanced scenery to a region they could release the layers of scenery to the public without causing an issue with either re-releasing a copyright route, or creating multiple version of routes. The route in fact would remain the same, but the layered scenery would allow some of the many people who enjoy adding to freeware and even more so payware routes the chance to showcase their talents. It's a shame that I can't see some of these worlds because in doing so I'm either obtaining an illegal copy (even if I own the route).

SIMPLIFIED CAR SYSTEM:
I don't think I mentioned this here (but on another forum) so here goes. Having a realistic yard full of complex cars is a huge drain on even the best gaming systems. It is the one smoking gun I'm worried about as I push RTS to the next level. The alternative is to do what programmers have been doing for ages and that is reducing duplicity. The reskins and renumbers of many stock is also a perfect example of wasted resources. Many changes or adaptations of the original model is to either show a new paint scheme, or simply change the number of the car.

To me cars or engines for that matter should have a base model. In other words have the cars specifications to what it's dimensions are, and can even go down the where each rivet is. Not only can the format of this 3D model be smaller in size by 1 key factor and that is remove the color, fonts, weathering, and your left with a basic 3D model.

What makes these models unique is paint color, logos, font, reporting marks, weathering, graffiti, and car numbers. All of these can be called up in a specification file that points to the original model. All of this data can probably be stored in much less space. Take weathering and graffiti for example these can be randomly generated by the simulator based on data such as age, and security variables. A car that is in high security environments such as auto and IM are less likely to be impacted by these factors, but age has not only an effect on weathering but even an older car winding up falling victim to graffiti due to being old and sitting in a storage track far away from any industry.

The font aspect and logos are just like how your operating system handles images and text. A simple change in a car number should only be stored in as little as one double integer. But most are actually in an array of many pixels that get rendered and called up over and over again for each new car type which is very wasteful. Having the car numbers actually match a field with proper reporting marks is also very inviting.

So I'm all for backwards compatibility but I think ORTS is open enough to already do things that MSTS can't do. It would be really nice to see some of these features considered in a simulator. But the fact is as simple as it is for storage and retrieval there is one complicated factor and that is it will take quite a bit of coding and the routines aren't simple but it is certainly doable. I know that is probably way way down the road on any road map, but boy would that be special.

Thanks

Sean

[Erick_Cantu]

To me cars or engines for that matter should have a base model... What makes these models unique is paint color, logos, font, reporting marks, weathering, graffiti, and car numbers...

I already touched on this, sort of. I don't think there's a particularly realistic (in terms of programming and how model making actually works) way of implementing it the way you want (you could have reporting marks done sort of like the 'decal_nnumber' function in FS, or the way locomotive renumbers are done on certain RailWorks models, but, to be quite honest, it looks like garbage, the lettering 'layered' on top does not blend well, the fonts are usually totally inaccurate and inflexible, and on real freight cars the positions of reporting marks are not uniform), however, I mentioned the way multiple texture folders are handled in FS using a single model and various texture sets set in aircraft.cfg.

Ultimately, however, rendering the mesh isn't what eats up performance, it's the number of bitmaps, the number of UV coordinates, and various other factors that most people making content for rail simulators don't seem to get. At this point, when I download a locomotive that has a billion textures, it's extremely unlikely that I'll use it, or even let it live outside the recycle bin. Time and time again it has been stressed that one big texture is better than many small textures, yet few model makes seem to get it, and it's a shame because not only is it important, it's easier to deal with in the first place. If you feel the need to map a part to a 4x4 texture, instead of saving it as its own file, find a 4x4 space in another texture and put it in there. Simple.

In any case, the method you outlined wouldn't improve performance. As the above text indicates, it would actually make it worse. Creating rust and weathering - anything that isn't a solid colour - requires texture maps. If you want the colour and weathering to be separate and applied by the sim, it means multiple material layers (and these materials would need maps). Since the big performance problem is rendering texture maps, and instead of using one, you're using three or more, performance would suffer greatly.

[eric]

One of our beta testers is working on an application that would make substitutions of shapes in a route's World files. With a compiled list of default - replacement shapes, this app could solve the problem of OR users that do not have MSTS of using routes that contain default MSTS content. There is a upload in the forum library that has pictures of all the default shapes including the hidden ones.

Subbed routes could then be safely made available to OR users that do not have MSTS.

That sounds like the safest approach.... One can do that a shapefile at a time today with Route_Riter, but having a script that rips thru a CSV file would be better and less prone to error...

Creating new shapes with the same file names might be a lot closer to copyright infringement (imposterware?) but replacing with new objects and filenames takes this farther into the realm of user generated content.

I also like the concept of libraries vs. individual files.

Now, if only OR could take it up a notch and allow replacing world file and TDB structures with real XML....

[SurvivorSean]

I can see your point on rendering and by no means am I an expert on processing time for 3D graphics.

But at least on the current version of MSTS loading new content is just as costly as it is something that can be handled by cheap RAM or processor speed. I can see for the average person running in explore mode with an average train performance would certainly decrease. But having a fully populated area I still believe processing power is capable of doing much more than loading each and every car into memory.

I won't debate 3D rendering issues, and if it looks like crap in FS perhaps it's not a good thing. As for the position of logos, reporting marks, etc. all it takes is two additional x y integers. You could say spacing would require an additional issue as well perhaps. Maybe by the time we ever get there the performance and technology would be able to handle it better.

Thanks

Sean