[roeter]

ErickC, on 23 January 2023 - 05:08 PM, said:

Insofar as alternate road numbers go, I have had great success using decal shapes for this purpose. They're simple planes with alpha textures applied that are set up as freight shapes. Typically, I do them in sets of 32 (usually a 1024 x 1024 pixel texture sheet with 32 256x128 pixel texture slots), meaning a single car folder can have 32 roadnames. I generally build car kits so that each texture folder can have 4 paint variations in it. That's why my 100-odd BN hoppers only really take up 44MB of space. This might sound like a lot, but I had 100 road numbers across 16 weathering variations - 44MB isn't a lot considering what it would have looked like with 100 individual car textures. Given that a single 1024 x 1024 pixel DXT5 image is around 1.5MB, and that a car of that size would typically need 2 of them, that's 3 MB per car or 300MB across a 100-car train using conventional methods. These cars were also set up to use the remotely-located models from the base package, meaning those 4 models were it. No duplicate models located anywhere, just the same models from the base package being used by 4 separate car folders with textures in them.

How do you define the different decal positions for the different wagons? Do you use FreightAnimations to display the decals or do you use different .s files?
The reason I ask is that OR loads multiple used .s files only once. So if you have many similar wagons, only with different numbers defined as FreightAnimation, the .s file is loaded only once. However, if you use different .s files, these will all be loaded individually. When running long or many trains, this can make a very significant difference in memory usage for OR.
That is why the possibility of setting alternative texture files for shapes, e.g. defined within the .eng or .wag file, is a very interesting idea as it will allow single .s files being used on multiple instances which differ in number only. Another interesting use of alternative textfiles could be to define the required textures in parameters in timetables, such that trains can change destination boards and such items while on route, e.g. on forming another train.

Regards,
Rob Roeterdink

[ErickC]

roeter, on 24 January 2023 - 01:54 PM, said:

How do you define the different decal positions for the different wagons? Do you use FreightAnimations to display the decals or do you use different .s files?
The reason I ask is that OR loads multiple used .s files only once. So if you have many similar wagons, only with different numbers defined as FreightAnimation, the .s file is loaded only once. However, if you use different .s files, these will all be loaded individually. When running long or many trains, this can make a very significant difference in memory usage for OR.
That is why the possibility of setting alternative texture files for shapes, e.g. defined within the .eng or .wag file, is a very interesting idea as it will allow single .s files being used on multiple instances which differ in number only. Another interesting use of alternative textfiles could be to define the required textures in parameters in timetables, such that trains can change destination boards and such items while on route, e.g. on forming another train.

Regards,
Rob Roeterdink

That depends on what you mean. When shapes are located remotely, OR will load textures from wherever the WAG or ENG file is located. So one model located in one folder can have as many alternate paint jobs as you like. In this way you can use as many alternate texture files as you want with the limitation that you can only have one copy of a texture map in a folder as the filename must match the name in the model. This is why I build models in groups of 4, because each car folder can have 4 main texture variations with the decal shapes providing the road numbers.

I use one set of 32 models for all of the decals used on a particular piece of rolling stock. For example, there is a set of 32 for my 100-ton triple hopper, and another set of 32 for my 70-ton triple hoppers. Each decal model consists of 4 planes that are large enough that the painter has a great degree of latitude on where the numbers are positioned. While this means that 32 separate models are loaded (if the painter uses all 32 available slots on the texture sheet), only one set of these models is necessary for multiple repaint packages. These models are defined as freight shapes. Here is a sample WAG file (please note the trucks and carbody are separate to allow for easy truck swapping):

SIMISA@@@@@@@@@@JINX0D0t______

Wagon ( NAVS_Hopper_DRGW_14606_LD
	WagonShape ( ../NAVS_COMMON/Hopper_70t_Triple_Type1/Hopper_70t_Triple_Truck_ASF_roller.s )

	ORTSFreightAnims (
		MSTSFreightAnimEnabled ( 1 )
		FreightAnimStatic (
			Shape( ../NAVS_COMMON/Hopper_70t_Triple_Type1/Hopper_70t_Triple_Type1_00.s )
			Offset( 0, 0, 0 )
			FreightWeight( 0lb )
		)
		FreightAnimStatic (
			Shape( ../NAVS_Hopper_70t_Triple_Type1_BASE/Decals/Decals_Gen_00.s )
			Offset( 0, 0, 0 )
			FreightWeight( 0lb )
		)
	)

	Include( "../NAVS_COMMON/INCLUDE/AAR_Type-E.inc" )
	Include( "../NAVS_COMMON/Hopper_70t_Triple_Type1/Hopper_70t_Triple_Type1_LD_1_roller.inc" )

)

As an example, the 100-car unit train I mentioned above is divided into 4 folders. Each folder contains two 2048 x 2048 pixel carbody texture sheets, one decal texture sheet, and all the WAG files. That's it. The same set of models (4 carbodies and 25 decals) is used for all of them and are located remotely. Prior to implementing this scheme, I ran tests to determine whether the additional drawcalls incurred by the decal shapes was enough to offset the performance gain from loading fewer models and fewer texture sheets overall. The end result was a significant performance boost. Insofar as memory usage goes, 32 decal shapes is a whole lot more than 1 shape with 32 texture references defined in a WAG file, but each decal shape is about a kilobyte. So it's the difference between 1 kilobyte and 32 kilobytes, which is pretty minimal.

I was considering memory usage less than I was considering performance in this particular case. After running a whole bunch of tests, I determined that the single biggest determinant of framerate across an entire train was the number of texture files loaded. Using the method I outlined above decreased the number of texture sheets across a train significantly. My 100-car BN unit train had a grand total of 13 images, since each car folder had two 2048x2048 pixel carbody textures and one 1024x1024 pixel decal sheet. The 13th texture is the truck texture. The models have a hard-coded texture path to a single texture sheet for the trucks, located in the same folder as the models. I can get away with this being a separate image because trucks are animated, meaning they're always going to be an additional drawcall. This freed up a lot of space in the model and means that multiple models of different freight cars use a single set of truck textures located in a common folder.

If a system was developed that allowed us to change the texture filename used in the WAG file, then further savings in the number of models could be incurred, but it might come at the cost of additional texture maps, which would probably have a much bigger effect on performance as you'd need a separate sheet for each decal instead of 1 sheet that is used across a bunch of different decal shapes - and you'd only be making a gain of a few kilobytes. In my tests the number of textures impacted performance more than the size of the texture sheets, although I go to great length to minimize both. In either case, OR is loading a single small set of common models, so I'm not sure being able to specify an alternate texture filename would impact memory usage across a large train all that much. It would, however, remove any limitations on the number of alternate textures in a single folder, which would indeed be very nice!

[Genma Saotome]

I agree that having replacement texture files recorded in .wag and .eng files is a great way to deal with many unique visual instances of a single .s file (so long as those .wag and/or .eng files have been bundled into the same folder).

[Eldorado.Railroad]

Genma Saotome, on 31 January 2023 - 01:13 PM, said:

I agree that having replacement texture files recorded in .wag and .eng files is a great way to deal with many unique visual instances of a single .s file (so long as those .wag and/or .eng files have been bundled into the same folder).

I will add my vote to this. It may be too complex to add this to .eng or .wag files. The creeping feature list that these two files endure makes me wary of adding something as "simple" as more texture references. From what I know of other train sims, there is often a special external script that is used to "randomly" select textures so that consists will look less "visually boring" when the same shape is used. Some might suggest that a more deterministic "method" is desired to select specific sets of textures.

As an example of simplicity:
shapefile.s (polygons/uv that make up the shape in question)
The texture section would just be:
a.dds
b.dds
....
z.dds

shapefile.tex (a simple text file that lists the possible textures(with locations on a storage device) to be applied shapefile.s)
Each textures/element group would be:

shapefile ALT tex 1
{
a.dds=someplace in storage texture file
b.dds=someplace in storage texture file
....
z.dds=someplace in storage texture file
}

shapefile ALT tex 2
{
a.dds=someplace in storage texture file
b.dds=someplace in storage texture file
....
z.dds=someplace in storage texture file
}

shapefile ALT tex 3
{
a.dds=someplace in storage texture file
b.dds=someplace in storage texture file
....
z.dds=someplace in storage texture file
}
....

shapefile ALT tex n
{
a.dds=someplace in storage texture file
b.dds=someplace in storage texture file
....
z.dds=someplace in storage texture file
}

As for error modes, the lack of a .tex file would indicate to simply use the texture names given the the .s file. There might be other exceptions, but this is the general idea. It would be highly desirable that textures loaded from the same location in storage be loaded once and only once into memory. No changes to .wag or .eng files would be needed. If a little less time was devoted to refactoring code I am sure some "method" could be implemented to address this long standing issue. After all, refactoring is geared towards efficiency, and efficiency/simplicity in the use of memory is refactoring by another name.

Steve


EDIT: Yes someplace in the .eng/.wag file would have to indicate what texture set to use for a given shapefile.

[roeter]

Eldorado.Railroad, on 09 February 2023 - 09:46 AM, said:

From what I know of other train sims, there is often a special external script that is used to "randomly" select textures so that consists will look less "visually boring" when the same shape is used.

But random texture files is not what is intended here.
One aim is to provide distinctly numbered units (may be engines or wagons) using the same shape file. In that situation, the texture to be selected for that instance is unique and applicable to that specific .eng or .wag file only. Another possible way to do this might be to create a list of possible texture files and let the system select one when it loads an instance. But that is far more complicated as the system must keep track of a selected instance to ensure it always uses that same texture on that unit, and does not use that texture on another unit.
Another aim is to provide changeable destination indicators, using a list of possible textures and selecting this through a specific command (probably only possible in timetable mode).

Regards,
Rob Roeterdink

[Eldorado.Railroad]

roeter, on 09 February 2023 - 10:15 AM, said:

But random texture files is not what is intended here.

Yes.....that is why I wrote what I wrote....sorry....editor dumped this to a post before I had completed my thoughts! Oops!

[Genma Saotome]

Late to the conversation... a long time ago James explained to me that a texture file is loaded only once in the GPU. It is probable this singularity requires only the combination of full path and texture file name and that the name of the shape file that uses that texture is not relevant.

Can that observation be verified by someone on the OR Team?



WRT how this relates to draw calls: when identical static objects have multiple instances placed on a tile the many instances / one drawcall per texture/material type will only occur if the Instancing option is turned on (FWIW, LODs are tossed out). There is no instancing for rolling stock. That fact should mean that N numbers of the identical .wag files in a train will require n drawcalls for each .wag file/shapefile/texture/material type combination.

Can that observation be verified by someone on the OR Team?

My reason for posting this is to ensure our assumptions, especially Erick's are correct. I think Erick is right about loading texture files to the GPU. I do not think single instances of texture files in the GPU reduces draw calls when the subject at hand is rolling stock.

[James Ross]

Genma Saotome, on 16 February 2023 - 10:17 PM, said:

Late to the conversation... a long time ago James explained to me that a texture file is loaded only once in the GPU. It is probable this singularity requires only the combination of full path and texture file name and that the name of the shape file that uses that texture is not relevant.

Yes, only the texture file path and name are used; it does not care what is using that texture

However, even though it is an absolute path, it is not currently fully normalised - it leaves in "\..\" and other weird items - but the practical difference may be minimal (1233 vs 1235 textures in my test of MEP > Baby Blues)

Genma Saotome, on 16 February 2023 - 10:17 PM, said:

WRT how this relates to draw calls: when identical static objects have multiple instances placed on a tile the many instances / one drawcall per texture/material type will only occur if the Instancing option is turned on (FWIW, LODs are tossed out). There is no instancing for rolling stock. That fact should mean that N numbers of the identical .wag files in a train will require n drawcalls for each .wag file/shapefile/texture/material type combination.

Yes, I believe so: we only apply instancing to the Open Rails classes "StaticShape" and "StaticTrackShape" and only when loaded from a world file

If it is not loaded by a world file, or is another type (e.g. "TransferShape", "SpeedPostShape", etc.), it will not be instanced

However, do note that this is only for simplicity - there are no animations or movement to worry about for those kinds of shapes - and we could, in principal, instance more dynamic things in the future, like rolling stock

Genma Saotome, on 16 February 2023 - 10:17 PM, said:

My reason for posting this is to ensure our assumptions, especially Erick's are correct. I think Erick is right about loading texture files to the GPU. I do not think single instances of texture files in the GPU reduces draw calls when the subject at hand is rolling stock.

I believe you are correct, though we provide in-game counters for shapes/textures loaded as well as actual draw call counters, so if someone wanted to verify this, they should be easily able to do so

In so far as consolidating textures go, even if it wouldn't reduce draw calls, it could well reduce GPU memory usage which may be the difference between good and horrible performance

[ErickC]

Genma Saotome, on 16 February 2023 - 10:17 PM, said:

My reason for posting this is to ensure our assumptions, especially Erick's are correct. I think Erick is right about loading texture files to the GPU. I do not think single instances of texture files in the GPU reduces draw calls when the subject at hand is rolling stock.

That depends, also, on what everyone's interpretation of my assumptions are (as I've noticed some misinterpretations in a few posts, not necessarily yours). My assumptions are:

• Since OR calls textures from where the WAG file is, not where the model is, users can have many texture variations, but avoid multiple copies of a single model by just calling one model from a single location.
  
• Placing multiple carbodies in a texture allows me to utilize texture space more effectively, which eliminates the need for multiple images/materials in a single model. This reduces the number of drawcalls on any one model.
  
• Using a separate texture on trucks or wheels isn't a problem because animated parts are always going to be separate drawcalls anyway.
  
• Hard-coding texture paths for items like trucks that don't need to change between repaints saves the user from having a bunch of unnecessary copies of the same image, but won't do anything about the number of drawcalls as that's a material-dependent property of the actual model.
  
• Using decal shapes imposes an extra drawcall on each model as the decal shapes are separate models (which also use a separate texture).
  
• Using decal shapes allows the user to have many road numbers without many different carbody textures, saving disk space and clutter
  
• Using fewer overall images means fewer images are loaded into the GPU

Point 6 is important since most renumbers of freight cars or locomotives are otherwise identical to the original, just with new numbers. So you add another whole texture file when a tiny part of the actual image data changed. My method allows a whole bunch of cars to use a single image for the base texture, and a second, smaller image for the road numbers. I don't know necessarily that this decreases the number of of images loaded into memory (I would assume that a whole bunch of iterations of a model using the same image in the same spot would mean that specific image is only loaded into memory once), but I did note a significant performance increase across a train with cars using this method verses the control train that used a bunch of old SLI stock with comparable drawcall and triangle counts in my tests. Your results might vary and my computer is probably more marginal than most, so the changes might be minor for people with better computers. For me, this made the extra drawcall imposed by the decal shape a worthwhile compromise.

With that said, it's unclear to me if this is down to the cars reusing the same image or something else that's different between my models and the SLI models I was using. As an example, I am much more thorough in reducing texture vertices than most model builders are because I come from the MSFS world where this is critical to performance. I plan texture layouts and polygon smoothing far in advance for this purpose and weld UV coordinates judiciously.

I do wonder if OR only loads a single instance of a particular texture file when there are multiple pieces of rolling stock that use it, though. I had made that assumption, but it's just an assumption. When you call for a model located in another folder, OR will load textures from wherever the WAG or ENG file that calls for the model is located, which makes me wonder if OR considers the texture file on a per-model basis in all cases and loads multiple iterations of the same file when multiple cars call for it.

James Ross, on 17 February 2023 - 05:14 PM, said:

In so far as consolidating textures go, even if it wouldn't reduce draw calls, it could well reduce GPU memory usage which may be the difference between good and horrible performance

That's actually the core assumption behind why I build rolling stock the way I do - that the extra drawcall imposed by the road numbers being in a separate texture is greatly offset by the massive reduction of images in GPU memory across a train. This also allows me to get away with making the trucks a separate model, which hypothetically adds another drawcall for the top node on that model (usually a dummy), but makes swapping trucks easier so the user can easily customize the model for a particular road. I use rectangular texture layouts (usually 2048 x 1024 pixels) so that cars don't need to use multiple materials, and then I put the textures for two carbodies in a single image. The net result is that two carbodies use one large texture, while the trucks use one small texture, and the decals all use a third small texture. Most of my current freight cars will have 2 carbody texture maps for 4 colour variations in a car folder, with a third image for 32 road numbers, and the trucks hard-coded to a single image in a remote location. 32 cars, 4 images. Add a second car folder for 4 more colour or paint scheme variations, and then you have 64 cars using 7 images (4 main textures, 2 decal textures, and the single hard-coded truck texture). Provided OR loads images the way I suspect it does, of course.