[James Ross]

copperpen, on 04 February 2014 - 07:59 AM, said:

I see a problem. MSTS needs ace files. OR would like to use DDS. The s file for a model contains the names of the files required for the model. OR also reads this s file.

The nature of the problem is that you cannot have a model looking for ace files where there are only dds, and you cannot name the dds files with the ace extension because they will not work in MSTS. That means you need a second shape file to call the dds files, but that will break activities. Unless OR reads the s file and substitutes the dds for the ace.

That's the plan - have OR check for "foo.dds" every time it sees "foo.ace". That's why I am suggesting we have it controlled by a setting to start with, as it isn't clear if this would cause problems (performance or otherwise).

[Eldorado.Railroad]

From 04 February 2014 - 07:59 AM:

The nature of the problem is that you cannot have a model looking for ace files where there are only dds, and you cannot name the dds files with the ace extension because they will not work in MSTS. That means you need a second shape file to call the dds files, but that will break activities. Unless OR reads the s file and substitutes the dds for the ace.

Not really...

eg (before):
..\Mytrain
foobar.eng
foobar.s
one.ace
two.ace
three.ace

eg (after):
..\Mytrain
foobar.eng
foobar.s
one.ace
two.ace
three.ace
one.dds
two.dds
three.dds

Note: THE ONLY THING THAT CHANGED is the addition of one.dds, two.dds, and three.dds. ALL of the other files remain EXACTLY the same.
Yes, we will have to access just how much of a penalty it is to load and process a .dds file instead of an .ace file. The tradeoff is that there are many tools/formats to create .dds files and the creation from .ace files could be automated in simple batch scripts (you only need to do this conversion ONCE). Nobody will be FORCED to convert anything if they choose not to. The price paid for 100% compatibility with existing MSTS tools, etc is more hard disk space. With 4TB drives on the market, how expensive is that progress?

And, we move OR into the mainstream, simulation graphics wise.

[Genma Saotome]

Put it into the .sd file. ALL shapes have a .sd file. I'm pretty sure KUJU meant .sd to mean shape description. You want to use .dds? just record the replacement in the .sd file. OR looks there... if it says use def.dds for .abc.ace... no problems.

TextureSubsitution (
	Replace ( oldfilename, newfilename )
	etc.
)

It's so simple and it only comes into effect when somebody adds the parameters with the data.

Stick it on the .sd for cars and locomotives and you have a simple reskin. No need for a new folder, copying all the other files that remain shared; Just drop in the new texture, write a new .sd and .eng. Done. Consider... there are hundreds of re-skins of a PS-1 boxcar model. They could all go into one folder called PS-1 40ft Boxcar instead of the hundreds of different folders there are now. Ditto for all those American Locomotive models... get rids of dozens, if not hundreds of folders and have F-7, SD-40, etc., etc. Or SLI_SD_90's. Whatever. Vastly better organization -- IF someone wants to do it that way.

FWIW the exact same technique can be use to replace ancient LOD settings... 100m becomes 500. No big deal:

MeshFileAlterations (
	TextureSubsitution (
		ReplaceTexture ( oldfilename, newfilename )
		etc.
	)
	LODSubsitution (
		ReplaceLOD ( oldvalue, newvalue )
	)
)

It's a simple way to help people update old content to more modern expectations and setting it up as MeshAlterations() let the OR team put anything that sometime down the road into the same general area... stuff like bias, maybe even shaders. It can't change anything more or less than what's already defined in the mesh but it will allow some changes.

Down the road new features, like time of day to turn on/off night textures go into a different section -- they're not changing the mesh, they're doing something new.


Bottom Line: Using the .sd as I suggest not only address migrating to .dds but also addresses other similar issues about the shape when it is being loaded, and doing it all the same way, which, IMO is better than addressing them all ad-hoc.

[disc]

I don't understand why are you overcomplicate this texture thing. Trying to load DDS first (no needed for any modification), if no dds found then load ace method will have immeasurably small performance penalty, while the properly compressed files in DDS will surely increase the performance of the game.

As you can see in the other topic: here
I've made a small app to list ACE files with specific format, and this list can be used for batch dds conversion(BGR565 and BGRA5551 -> DXT1 dds, BGRA4444 to DXT5). Now the only thing is needed, a command line application that can convert and compress ACE files to DDS, for the batch script. Is there any application for this task?

[Genma Saotome]

disc, on 04 February 2014 - 02:50 PM, said:

I don't understand why are you overcomplicate this texture thing.

I don't know to whom you are asking the question but if perchance it's me the answer is there are many opportunities to do more w/ textures than what KUJU gave us in MSTS. One is to use some other format besides .ace; Another is to make it easy to replace texture file names that are recorded in the mesh file; Another is to reduce the amount of unnecessary duplication of files when someone reskins a car.

You can solve each of those one by one... probably different people at different times, taking a year or two to get them all done, or you can get them all done by enhancing the text file that rides along with every shape -- the .sd file. ANYTHING done in the .sd file to add features is in plain sight, can be clearly structured, and is completely up to the end user to apply. IMO fixing several problems at once is a far better solution than a simple if then else tweek to fix only one, letting the other feature suggestions twist in the wind for several more years beyond the several years they've already been hanging out to dry.

[gpz]

DDS format support has been committed. It is available in recent versions, that can be downloaded from the usual place.

[cjakeman]

Hi Dave,

Genma Saotome, on 04 February 2014 - 09:51 PM, said:

I don't know to whom you are asking the question but if perchance it's me the answer is there are many opportunities to do more w/ textures than what KUJU gave us in MSTS.

I don't know either, but I did want to say that I'm glad you look ahead for issues and put so much effort into nudging OR in a good direction..

[gpz]

Dave,

I'm just wondering why we should mess with these old .sd files at all. The modifications you propose mean a complete restructuring of the .eng format, which would mean we move away from it completely. Rather than trying to fit everything into the old format, a new tech data format specification could be made.

While we are stuck with current eng files, until our own AE is ready, we have to keep the current eng files anyway. So there is not much point in partly restructuring it. The only benefit of keeping the formal eng file would be that MSTS would not crash while reading it, but it isn't a real benefit, since MSTS could not use the restructured form anyway.

But otherwise you could also make a new complete reference example configuration of a widely available locomotive, how it supposed to look like. Then we could start talking about it in detail, so that when a coder will be assigned to this task, there would be a package, that could be passed to him, saying "Here it is, implement this!" For a coder sometimes takes more time to think about what the code supposed to do, than actually do the coding. Making a reference implementation is not necessarily a "coder" task, and there would be something to "peddle" with. ;)

[scottb613]

Morn'n Folks,

Just curious - what is DDS actually buying us here ? It's a more efficient so we should see better performance over all ? It's a better quality of compression graphic ? Is this leading into supporting bump maps ?

Thanks,
Scott

[gpz]

All of the above.