[stationmaster]

Hello everyone!
I am quite new to OR and modeling etc. My profession is really software development, and I have done some years of C# programming.
At the moment I am more into the modeling side and I have done some tutorials with GMAX etc.
Now GMAX is not the best tool in the world, in todays standards, so I have also spent some time to learn Blender. And I must say, when you get used to the user interface it's a fantastic modeling tool.

Now to my problem, the file types supported in OR. I have understood that so far OR only supports the MSTS file types, e.g. .s , .ace.
And non of these formats are supported by the modeling tools I would like to use, i.e. Blender and GIMP.

I read somewhere here on Elvas Tower that .dds was consider to complement .ace. Howabout other images filetypes, e.g. .png, .jpg?

And for the shape files. What do you think should be added here to complement .ace? .3DS?

Has any of this work started? Is someone interesting at working on this?

Ok, that's a lot of questions. Now lets hear your opinion.

Cheers,
//J

[James Ross]

stationmaster, on 26 September 2013 - 10:53 AM, said:

Now to my problem, the file types supported in OR. I have understood that so far OR only supports the MSTS file types, e.g. .s , .ace.
And non of these formats are supported by the modeling tools I would like to use, i.e. Blender and GIMP.

I read somewhere here on Elvas Tower that .dds was consider to complement .ace. Howabout other images filetypes, e.g. .png, .jpg?

And for the shape files. What do you think should be added here to complement .ace? .3DS?

Has any of this work started? Is someone interesting at working on this?

We've had various discussions on this, but few concrete conclusions reached so far.

One of the things I would be happy to see is support for "easy" formats alongside the "preferred for distribution" formats. For images, this is pretty easy - we can (with almost no effort) support PNG and JPEG next to DDS. For models, COLLADA is the "easy" format (because pretty much all modelling tools can export it), but it isn't clear what the preferred format should be.

[wacampbell]

James Ross, on 26 September 2013 - 11:04 AM, said:

One of the things I would be happy to see is support for "easy" formats alongside the "preferred for distribution" formats. For images, this is pretty easy - we can (with almost no effort) support PNG and JPEG next to DDS. For models, COLLADA is the "easy" format (because pretty much all modelling tools can export it), but it isn't clear what the preferred format should be.

Just a consideration ... file formats such as DDS and ACE are near optimal for small file size and fast loading into DirectX. The other types not so much. A few PNG and JPG wouldn't be bad, but if they are supported, they will become the dominant file type, and then route loading would suffer. Its the ongoing compromise between file formats that are optimal for loading and running, and others that are convenient for the artists. It seems we get the best of both worlds by providing conversion utilities in the artwork pipeline, allowing the artist to use png/jpg etc, which get converted to DDS/ACE for use by the actual sim.

Also, wrt Collada, it does have similar issues as I just mentioned, ie not being configured for easy loading into DirectX ( .s files are not much better in this regard ), but also I believe Collada doesn't have a mechanism to support LOD's, so it will require some sort of kludge with node naming etc. Again, conversion utilities seem like the best solution. Keep RunActivity fast and lean, and put the grunt work of conversion into the artwork pipeline.

[jared2982]

I regularly use .bmp and .pspimage for my artwork when doing a model. I build the texture in layers in PSPx4 pro using .pspimage format which can tgen be easily saved as a .bmp for use by GMax. Once I have it ready for testing I convert to .ace and load it in the sim. We need to stick to files that require the least amount of system resources to load but yet still provide a decent quality graphic. The .ace seems to work very well as is. As far as what would be best for a shape file I do not know. A few new exporters for our modeling programs that would export both the model to whatever format is decided upon and then also export the textures as well would be nice.

[James Ross]

wacampbell, on 26 September 2013 - 01:02 PM, said:

Just a consideration ... file formats such as DDS and ACE are near optimal for small file size and fast loading into DirectX. The other types not so much. A few PNG and JPG wouldn't be bad, but if they are supported, they will become the dominant file type, and then route loading would suffer.

I am well aware of this; however, the whole point of supporting "easy" formats is to enable content creators to have a better workflow. As long as we make clear that they are NOT optimal for distribution, and provide quick convert-all-content utilities, I don't think we'll have much of a problem in practice.

If we can't agree on the above, we simply won't support the "easy" formats.

[wacampbell]

James Ross, on 26 September 2013 - 01:28 PM, said:

I am well aware of this; however, the whole point of supporting "easy" formats is to enable content creators to have a better workflow. As long as we make clear that they are NOT optimal for distribution, and provide quick convert-all-content utilities, I don't think we'll have much of a problem in practice.

If we can't agree on the above, we simply won't support the "easy" formats.

It seems you have thought it through well. I support your decision in the end.

[jared2982]

James Ross, on 26 September 2013 - 01:28 PM, said:

If we can't agree on the above, we simply won't support the "easy" formats.

I personally ,as a content creator, would be fine just settling on a single or maybe even 2 standard file types for textures. I understand the convenience factor of the "easy" formats when it comes to this but I can see it causing problems in the future. Simply stated if they can use the easy formats then they will use the easy formats. Many of us understand the effects that are put on the sim from constructing models with way too much detail or using multiple texture files. Newcomers will bypass right over any guidance for constructing models and textures for distribution and just go with what works. Anyway just my 2 cents worth. I am in full support of whatever the team decides to go with.

[James Ross]

jared2982, on 26 September 2013 - 02:08 PM, said:

I personally ,as a content creator, would be fine just settling on a single or maybe even 2 standard file types for textures. I understand the convenience factor of the "easy" formats when it comes to this but I can see it causing problems in the future.

There is certainly a risk to it, which is why it's just a potential idea right now. My target for file formats is exactly 1 new format for each type of thing (texture, model, etc.) that is recommended and ideal for use with game data. (This could be, for example, DDS + X.)

There's also the option of (as I think Wayne was mostly suggesting) supporting a load of useful/common formats in tooling only. This could be optimised to a good degree - e.g. by having a tool which watches for file changes and automatically converts them to the 1 supported/recommended format whenever you save your PNG version. (Sky thinking would be even to have the game detect the change to the DDS file and reload it, meaning you save your PNG and a second or so later it appears in the currently-running copy of the game.)

[Genma Saotome]

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.

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.

[R H Steele]

[quote name='James Ross' timestamp='1380230891' post='130628']
I am well aware of this; however, the whole point of supporting "easy" formats is to enable content creators to have a better workflow. As long as we make clear that they are NOT optimal for distribution, and provide quick convert-all-content utilities, I don't think we'll have much of a problem in practice.

James, I am not as knowledgable about image formats as the people discussing here. 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. I think the idea of keeping the artistic pipeline open to many formats, then narrowing by conversion applications to a standard that is used by the sim is the only way to go. Each artist always has a prefered method/way of working, necessitating the use of many file types. The simulation, however, should be devoted to loading what it needs in a quick and efficient manner, with minimal use of precious resources. Don't you agree that standard usage for the sim would go a long way in achieving this? Cordially rhs (gerry)