Location of .ace/.dds files? Relative paths and memory allocation
#1
Posted 27 September 2021 - 06:17 AM
It is a given that the exporters for shape files do not have an option to describe "fancy" paths to .ace/.dds textures. What I am aiming for is to be able to modify the shape file after export and insert relative paths.
The reason for doing this is save some texture memory, especially if one is using a 3D cab (separate directory) where the shell that will surround the outside of the cab uses the same textures as in the main directory for the given engine. I ask why duplicate the textures twice?
This leads me to another question that has dogged me for years:
If I have two shapes files in the same directory that shares the same texture file, does OR "know" that at runtime and only load that shared texture file once and only once? It seems that the answer should be "yes", as long as the texture is in the same directory. But what about relative paths?
Thanks,
Steve
#2
Posted 27 September 2021 - 10:11 AM
Yes, you can use relative addresses for .ace/.dds files in a shape file.
As with other MSTS files, the path separators may be '\\', '/' or '//', but NOT '\'.
If you've got the MSTS default Class 50 in your TRAINSET folder, the contents of the attached .zip file can be used as a demo :)
Sorry, but I can't answer your other queries :(
Cheers,
Ged
Attached File(s)
-
Relative addresses in Shape.zip (5.89MB)
Number of downloads: 194
#3
Posted 27 September 2021 - 10:17 AM
I would expect a relative path is just another path so if folders A and B had shape files with an identical relative path to folder C I suspect OR would see the two statements as identical and load the file one time, not two.
Some time ago I had the same concern you did -- how to optimize VRAM utilization. The course I took was to look for identical models placed in multiple folders (e.g., Tim Muir's USRA boxcars) and to rename the .wag, .ace file, and it's entry in each .s file to the car initials + number. Meaning carbody.ace becomes CNW 123456 in one file and CNW 123789 in another, including the reference to them in each .s file. I then set up a new folder (e.g., CNW USRA SS Boxcars) and copied everything to that.
What I "win" is the other 4-6 textures that are identical are now loaded only once, w/o regard to which .wag I load. This pays off extra when I add 5-6 .wags per car number where each .wag has a different lading (and name, weight, Davis resistance, and center of gravity). I could have moved ALL the USRA SS boxcars into one folder this way but I didn't do that on account of a concern over too many files in one folder cluttering things up.
#4
Posted 27 September 2021 - 05:32 PM
Coding paths into the 3D cab is unnecessary, however. Current versions of Open Rails have visibility parameters for child shapes such that it's unnecessary to include hoods and whatnot in the 3D cab, which means a single 3D cab can be used for many models without worrying about paths at all. Simply set up the hoods as an OR freight shape and set the visibility to "Cab3D." Here's the code for the hoods and figures on one of the NAVX GP9s:
ORTSFreightAnims ( MSTSFreightAnimEnabled ( 0 ) FreightAnimStatic ( Shape( ../NAVS_COMMON/SOO_GP9R_KIT/GP9R_0_B.s ) Visibility ( "Outside,Cab3D" ) Offset( 0, 0, 0 ) FreightWeight( 0lb ) ) FreightAnimStatic ( Shape( ../NAVS_COMMON/SOO_GP9R_KIT/GP9R_0_C.s ) Visibility ( "Outside,Cab3D" ) Offset( 0, 0, 0 ) FreightWeight( 0lb ) ) FreightAnimStatic ( Shape( ../NAVS_COMMON/SOO_GP9R_KIT/ENGINEER_E.s ) Offset( 1.121, 2.759, -3.739 ) FreightWeight( 220lb ) ) FreightAnimStatic ( Shape( ../NAVS_COMMON/SOO_GP9R_KIT/CONDUCTOR_A.s ) Offset( -1.164, 2.759, -3.297 ) FreightWeight( 220lb ) ) )
I would encourage you to grab the NAVS Soo GP9R pack and the NAVX switcher package from trainsim.com (which uses the whole bag of tricks to expand your GP9 fleet with addition of just 2 texture maps and 4 pairs of lead/trail ENG files). Those files were placed in the public domain precisely so other developers would have examples to work from, so decompress the shape files, examine the inner workings, and otherwise have at it.
#5
Posted 29 September 2021 - 05:38 AM
slipperman, on 27 September 2021 - 10:11 AM, said:
Hi Ged,
Many thanks for providing me with a graspable example here. I will take a look at this tonight on my modelling machine tonight.
Thank you!,
Steve
#6
Posted 29 September 2021 - 05:51 AM
Genma Saotome, on 27 September 2021 - 10:17 AM, said:
I would expect a relative path is just another path so if folders A and B had shape files with an identical relative path to folder C I suspect OR would see the two statements as identical and load the file one time, not two.
Just when you think you are covering some new ground here I realize over and over again that I am always in "catchup" mode!
It would be helpful if the software developer(s) could/would chime in here. As with all things regarding resources in this project, allocation and releasing of memory has been a bit of a moving target. Some frustration with pinning down as to how things really work has been ongoing quest. It worries me a little that working in 64 bit mode means that worry over resources is no longer a concern. I am still skeptical!
Thanks for your time and answer to this, it is very helpful,
Steve
#7
Posted 29 September 2021 - 06:02 AM
ErickC, on 27 September 2021 - 05:32 PM, said:
Coding paths into the 3D cab is unnecessary, however. Current versions of Open Rails have visibility parameters for child shapes such that it's unnecessary to include hoods and whatnot in the 3D cab, which means a single 3D cab can be used for many models without worrying about paths at all. Simply set up the hoods as an OR freight shape and set the visibility to "Cab3D." Here's the code for the hoods and figures on one of the NAVX GP9s:
I would encourage you to grab the NAVS Soo GP9R pack and the NAVX switcher package from trainsim.com (which uses the whole bag of tricks to expand your GP9 fleet with addition of just 2 texture maps and 4 pairs of lead/trail ENG files). Those files were placed in the public domain precisely so other developers would have examples to work from, so decompress the shape files, examine the inner workings, and otherwise have at it.
Erick,
Thanks for the heads up on this, it seems that I have a bit more digging/thinking and learning to do here, a bit of a paradigm shift! Without hesitation, thank you for putting the examples in the public domain. Rarely do I use what has been placed in the public domain train sim wise as is. So I will carefully examine what is available and add to my knowledge. My thank you is a rather weak gratitude, but it is sincere.
Other than the political, is there any reason why these public domain files are not here at Elvas Tower?
Many thanks,
Steve
#8
Posted 30 September 2021 - 05:59 PM