[ATSF3751]

hey everyone,

As I do a lot of sounds for steam locomotives something has come to my attention that may be of use to everyone if possible. It not only would save space but end up being less work for everyone that does sound design. Being there has to be 2 different sound sets for interior and exterior sounds. Wouldn't it be possible and more efficient to just have the exterior sounds play for the interior sounds as well? That way we do not need to have a stereo sound set and a mono sound set as we currently have.

It would make sound design much quicker to do and would also save quite a bit of space on everyone's PCs.

Another thing I thought of is we have a lot of the same class of locomotives, freight and passenger cars in the same paint scheme and the only difference is the #s. Would there be a way to render Open Rails so we could use one paint scheme for a specific locomotive and railroad and then have a way to just change the number on the locomotive? We could do the same thing for locomotive cabs as well. Have the same cab with a way to just change the number in the cab instead of a whole different rendering of the same cab just for a locomotive number.

Just a few thoughts I had.

Brandon

[Weter]

Hello.
That's good, You care for disk space.
In one thread over here, Erick told, ORTS doesn't care, stereo or mono, so, it's possible.
About numbers (decals/plates) we have freight animation attachments for main shape.
Alias-paths give us some economy; Include-files allow to go further with it.
:offtopic:
I see, that bar graph about laptop's disk turned red: 4.3GB free of 56.
At 1999, I've spent $200 for addition 4.3GB HDD to my 1.6 with W95

[ErickC]

The reason we use separate clips is locomotives sound vastly different inside than outside given the insulation and soundproofing in the cab. There are also vibrations from engine harmonics that are audible in the cab but not outside, plus the sound of traction motor blowers and the like. Turbochargers and roots blowers in particular tend to sound vastly different between inside and outside. It's an artistic choice, so there's no technical reason not to use the same clips for the interior and exterior. Even MSTS didn't require a separate sound set for the interior. MSTS didn't actually need the interior clips to be in stereo, either; whether or not an SMS used stereo samples was determined by the presence or lack thereof of a Stereo() flag at the top of the SMS. Typically stereo samples are used in the interior to give the impression of a 3D space, whereas mono is used in the exterior because the locomotive becomes a point-source in a 3D space anyway.

I will say that sound designers need to be conscious of what the content is in the actual clips - there's no reason to use a 44100Hz sample when there's no content above 11,025 KHz. A 22050Hz sample rate would be more appropriate for that particular case.

I would argue the single biggest culprit of rolling stock waste in the OR world is probably using a bazillion copies of the same model in a bazillion individual car folders given that OR will load textures from wherever the WAG file is even if the model is located elsewhere - think of all the models that could be culled this way.

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.

This image shows the placement of the decal shapes on my 100-ton triple hopper:



And this is the corresponding decal sheet:



I set my decals 0.25" above the surface of the car - this seems to provide a good compromise between minimizing the appearance of floating above the surface and minimizing z-buffer issues at most viewing distances.

[griggs]

I've found the greatest source of used space on my computer for OpenRails to come from the overhead accrued by many of the files on my hard drive. Often its the routes that I have that take up the most space, being able to store them in uncompressed zip files so that the game can still read what is in them without having to do any decompressing would make a huge difference, though I think this was something talked about with the additions of a "virtual filesystem." Have any developments been made on this yet? I believe it was something that was to come with 1.5 but I think it might have been delayed for a future update.

[engmod]

>Have any developments been made on this yet?

I doubt it as it will effect older system too much.
Older system have much lower i/o speed and looking through large zip files will take much longer that looking for individual files.

[eric from trainsim]

I'm also a big decal user... my fleet of 30+ Metra F40s is a single SLI model with 30 FAs that have the light boards and numbers/names on the individual FAs. Did the same for my UPRR business car fleet on the freeware BLW cars.
I've carried that into other areas like CTC boxes at control points. Much easier to make tweaks to the shape details for the base model...

[cjakeman]

A useful tool is the Auslogics free duplicate file finder

It's very fast and has a neat interface with a preview to help you remove duplicates (but keep the last version). It will find activities that you forgot about long ago.

[Jovet]

Another big thing to think about with MSTS and Open Rails is hard drive cluster size.

A cluster is the base unit of allocation on a file system. When a file is created, space for it is allocated in multiples of that cluster size. MSTS/OR use many tiny files, yet those tiny files can still consume an entire 4K cluster. (*On NTFS drives, if the file data will fit inside the Master File Table entry for the file, it will be stored there and regular data space will NOT be allocated/wasted.) For this reason, it can be advantageous to use a lower cluster size than the usual 4096 byte default. Unfortunately, this is something only to think about when setting up your computer or formatting a new hard drive. It can't be changed without wiping the drive's data and reformatting it.

[eric from trainsim]

Honestly... local storage and cloud backup have become so cheap that I stopped worrying about it.

I can't fill a 1Tb drive if I tried.

[Genma Saotome]

I use a fair number of symbolic links. I started that to save on disk space but that's not much of a problem anymore. I continue to use those links to avoid the duplication of files. For example, I have all of my sim directories grouped by region and a date range. A route may appear in 3 of those date ranges. The symbolic link means only the disk space for one is used and if I were to edit that route the changes appear in all three locations. The \trains folder is unique to each of the date ranges. I also link \global to all locations and for the most commonly used rolling stock I've moved/edited the files into one folder (e.g., XM_SP_B-50-15) and linked that to the appropriate date ranges.

For good measure I have a daily .bat file in each region = date range that writes a file showing the links and that file is backed up daily. It's not in dos command format but it can be edited quickly to become one so if I lose a disk I can rebuild with a minimum of effort.

[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