[alkomv]

Genma Saotome, on 26 September 2013 - 02:49 PM, said:

If OR doesn't yet support use of .dds format images I'd certainly vote on behalf of having it do so ...
-------- snip ---------

I'd also vote for .dds. WRT Collada, I also agree it would be ideal if used as an intermediate format.

At the end of the day the easier the solutions to produce content for OR, the more people who will want to be involved and share ,,, a conversion utility can do the hard work, we will get win-win.

thanks for reading.

[James Ross]

Genma Saotome, on 26 September 2013 - 02:49 PM, said:

If OR doesn't yet support use of .dds format images I'd certainly vote on behalf of having it do so (with all of it's inherent features, such as bump maps), as soon as possible.

We can trivially add loading of DDS, but support for any new features available in that format (like bump mapping) will require actually coding them, so would have to wait.

Genma Saotome, on 26 September 2013 - 02:49 PM, said:

Q: what is the difference to performance between our use of .s files and whatever it is that DirectX uses? If it is large enough then it might be worthwhile to look into being able to convert certain native cad formats into whatever DirectX wants to use, starting w/ Collada. Collada might not be able to do everything... but it can be produced by nearly everything and so if there is a performance gain to be had that in itself has value.

It's very hard to know what would perform best, although it is pretty clear Collada will be a slow format to load (it's a very verbose XML format). I don't know if DirectX even has a moral equivalent of DDS - DDS is loaded by just copying the file directly in to memory, basically, with almost no processing at all. X is the "native" format as far as I know, but it is also a text or binary format (two variants) and support in tools seems wavy.

R H Steele, on 26 September 2013 - 03:30 PM, said:

I have always thought of myself as an astute observer of human behavior and I think you may rue "I don't think we'll have much of a problem in practice". Humans, mostly love the way of least resistance, and quickly adapt ways of practice that may make sense to only themselves and their process.

That just means we need to make the path of least resistance the one where they convert the formats to DDS/X (or whatever) prior to distribution. For example, the automatic conversion I mentioned earlier: the textures are authored in PNG or JPEG, converted to DDS by a tool that you just leave running (it could be built in to the editors we make) and then loaded only from DDS files.

[gpz]

As I read on internet, there is no 3D model format that current graphics hardware support out-of-the-box, unlike the texture format of DDS that can simply be loaded into video memory with the uncompressing handled by GPU directly. So in this regard any format can be used.

The .x format, as I read, was only an example format provided with some earlier version of DirecX SDK, to show how to load and handle models generally. It is no longer developed by Microsoft, and is also not a high quality format with few capabilities, according to most sources.

[James Ross]

gpz, on 27 September 2013 - 02:08 AM, said:

The .x format, as I read, was only an example format provided with some earlier version of DirecX SDK, to show how to load and handle models generally. It is no longer developed by Microsoft, and is also not a high quality format with few capabilities, according to most sources.

It's got built-in support in DirectX 9, which is the only reason it gets mentioned with DDS; but I also haven't seen a format that is clearly better than it. They all seem to have poor support in existing tools and/or completely undocumented structures, which is a great shame. I'm not very keen on specing our own format. :lol2:

[Genma Saotome]

James Ross, on 27 September 2013 - 12:48 AM, said:

It's very hard to know what would perform best, although it is pretty clear Collada will be a slow format to load (it's a very verbose XML format).

Misunderstood... I wasn't asking for OR to load Collada files but for a Collada translator to whatever cad file format is best for OR to load.

Based on the replies so far it seems there isn't an obvious candidate for a cad file format that is best for OR to load... something I did not know beforehand. <<sigh>>

[Genma Saotome]

Returning to the base note on future file types, it has long been my opinion that OR can and should take advantage of the .sd file to convey to the game software things about the mesh file that cannot be defined by the mesh data itself, or cannot be easily changed by the end user.

Consider that some mesh files do have extensive "behavioral modification" files: .wags and .engs are nothing more than very verbose sets of of parameters that are not defined in the .s file. Enhancing the .sd simply takes that existing concept and applies it to all other categories of models.

For example, as the mesh file defines what texture files are to be used, it seems reasonable that the .sd file is the place to define replacements. Similarly, the .s file defines LOD distances; with older models still in use those defined LOD's may well have been just right with 2001 hardware but today may well be too short -- I've seen trucks and wheels wink out at 500m... looked ok in MSTS as everything was sort of fuzzy anyway but in OR the car is obviously just floating along, LOD-levitated above the rails. The .sd file would be the right place to provide replacement LOD distances.

The .sd already conveys to the game something about the circumstances of display... that too can be extended to things like what hours are night textures to be active.


In future the team may choose not to include ".sd" as a go-forward file extension but that decision, should it occur, should not change very much of how the game code takes in and uses whatever parameters and data we might now put into the .sd file (e.g., replacement textures are replacement textures, w/o regard to where the definition occurs).

[gpz]

As an example, Unity game engine supports the following file types: link

The most mature is .fbx among them, but unfortunately that is proprietary. Collada or .obj are the remaining to speak about. The biggest problem with the current .s format is the lack of export tool for some modern 3D drawing program, like Blender. (I will never call these programs as CADs, because they are incomparable in regard of precise designing functionality with real CADs.)

[disc]

I think only dds should be the loaded format into the game. I know some developers who aren't know(and care) how a GPU, cpu or a 3d engine is working, just developing content. They don't think about performance, they just say when i ask for example "why did you used 4096*4096 textures where it's not needed at all?" and the answer is, "my pc have no problem with it, no fps loss, so why not?" while he is testing the 3d shape on an empty map... And then i resize that texture to 1024*1024 and no visible loss in quality, he says "ok, but HDDs are cheap, so let's stick to the better texture, just in case".
Or others making wagon shapes with 300000 triangles(oversmoothed curves, bad geometry, and these usually lead modelling errors due to the limits of vertex position precision, double faces, double edges, z fighting faces), or for another train sim, there is a common saying "why not? MSTS had 50000 triangle limit, but this isn't", while the same visual quality can be done by using just 40000 triangles. Moreover, some don't even use mipmaps, or using negative mipmap bias, to make their textures look sharper(while of course they are not use anisotropic filtering)...
As i see ace is support uncompressed textures, and non dds compression too, and a lot of creator use non dxt compression, just because don't know how this affect the performance. If i compare how the environment, and locomotives look like for example in TS2014, and see the memory usage of it and compare to OR or MSTS, and see the draw call numbers in OR, it's clear that the most of the msts content are wasting the resources. Too many unnecessary uncompressed, and non dxt compress textures, to many shape nodes that aren't attached together to a single shape, while none of these are animated.

That's why, i think it's not a good idea to let the content developers to use formats that are "far" from the hardware. For texture formats dds will be the best, it's widely supported, natively supported by gpus, and usally enought for everything.
About the 3d shape format, i don't know what what would be the best, but i don't think that common 3D easily reverseable formats will be very popular for payware developers, and even for some free developers (there are a lot of free developers, but there are just few "open source" content developers, the most of them are "free to use, but closed source" developers). However i don't know if it's possible to make a non reversable 3d format for an opensource software. .S was a closed non-reverseable format once... until it was reverse engineered :sign_thanks:

But there is something that no one mentioned. Sound formats? I think wav isn't too efficient as it is uncompressed, and for a game even a lossy sound format whould be enough. What about Opus codec? It's free, as it is made for realtime applications, it's probably have low resource usage at decoding, and it have very good quality/bitrate ratio.

[James Ross]

disc, on 30 September 2013 - 04:35 PM, said:

But there is something that no one mentioned. Sound formats? I think wav isn't too efficient as it is uncompressed, and for a game even a lossy sound format whould be enough. What about Opus codec? It's free, as it is made for realtime applications, it's probably have low resource usage at decoding, and it have very good quality/bitrate ratio.

At this time, I'd prefer MP3 over Opus, due to massively more support across the board and that we're not actually a real-time application. :sign_thanks: (Opus is good for recording in real-time but we're not interested in that for content sounds.)

[disc]

MP3 why? It's old, and have bad quality/bitrate if it's about support, then why not AAC? That's much better, and that's a standard today, supported everywhere.