Elvas Tower: Location of .ace/.dds files? - Elvas Tower

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Location of .ace/.dds files? Relative paths and memory allocation Rate Topic: -----

#1 User is offline   Eldorado.Railroad 

  • Foreman Of Engines
  • Group: Status: Contributing Member
  • Posts: 874
  • Joined: 31-May 10
  • Gender:Male
  • Country:

Posted 27 September 2021 - 06:17 AM

I have seen and known about relative paths in .eng and .wag files. These were implemented some time ago. Quite useful really! The question I have is whether it is possible to have the same inside a shape file?

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 User is offline   slipperman 

  • Engineer
  • Group: Status: Active Member
  • Posts: 602
  • Joined: 09-February 12
  • Gender:Male
  • Location:North Nottinghamshire
  • Simulator:MSTS & ORTS
  • Country:

Posted 27 September 2021 - 10:11 AM

Hi Steve,
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)



#3 User is offline   Genma Saotome 

  • Owner and Admin
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Owner
  • Posts: 14,476
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 27 September 2021 - 10:17 AM

I think OR uses the entire path with texture names and sends it all to the GPU. Consider: Folder A and B both hold a texture file named coupler.ace -- but they are actually different files with a common name. If the software didn't hang on to the path it wouldn't be able to keep the two texture files individually. Add the path and it would.

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 User is offline   ErickC 

  • Engineer
  • Group: Status: Active Member
  • Posts: 686
  • Joined: 18-July 17
  • Gender:Male
  • Location:Hastings, MN, US
  • Simulator:ORTS
  • Country:

Posted 27 September 2021 - 05:32 PM

All NAVS equipment uses relative paths for common textures stored remotely like trucks. Note also that OR will load the textures from wherever the WAG is, whether the model is physically located there or not (so you can cut a lot of waste by using a common set of models located remotely). Try grabbing one of the NAVS hopper kits off trainsim.com and inspecting those cars for ideas. The Soo GP9R kit (also available at trainsim) uses hard-coded paths for cab textures so that one set of textures can be used in all locomotives utilizing those cabs.

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 User is offline   Eldorado.Railroad 

  • Foreman Of Engines
  • Group: Status: Contributing Member
  • Posts: 874
  • Joined: 31-May 10
  • Gender:Male
  • Country:

Posted 29 September 2021 - 05:38 AM

View Postslipperman, on 27 September 2021 - 10:11 AM, said:

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 :)


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 User is offline   Eldorado.Railroad 

  • Foreman Of Engines
  • Group: Status: Contributing Member
  • Posts: 874
  • Joined: 31-May 10
  • Gender:Male
  • Country:

Posted 29 September 2021 - 05:51 AM

View PostGenma Saotome, on 27 September 2021 - 10:17 AM, said:

I think OR uses the entire path with texture names and sends it all to the GPU. Consider: Folder A and B both hold a texture file named coupler.ace -- but they are actually different files with a common name. If the software didn't hang on to the path it wouldn't be able to keep the two texture files individually. Add the path and it would.

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 User is offline   Eldorado.Railroad 

  • Foreman Of Engines
  • Group: Status: Contributing Member
  • Posts: 874
  • Joined: 31-May 10
  • Gender:Male
  • Country:

Posted 29 September 2021 - 06:02 AM

View PostErickC, on 27 September 2021 - 05:32 PM, said:

All NAVS equipment uses relative paths for common textures stored remotely like trucks. Note also that OR will load the textures from wherever the WAG is, whether the model is physically located there or not (so you can cut a lot of waste by using a common set of models located remotely). Try grabbing one of the NAVS hopper kits off trainsim.com and inspecting those cars for ideas. The Soo GP9R kit (also available at trainsim) uses hard-coded paths for cab textures so that one set of textures can be used in all locomotives utilizing those cabs.

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 User is offline   ErickC 

  • Engineer
  • Group: Status: Active Member
  • Posts: 686
  • Joined: 18-July 17
  • Gender:Male
  • Location:Hastings, MN, US
  • Simulator:ORTS
  • Country:

Posted 30 September 2021 - 05:59 PM

I'm lazy and uploading to FS/TS is an old habit (to the point where I still write a file_id.diz without thinking about it and only just started using file names more than 8 characters long). That's mostly it.

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users