[wacampbell]

Guille592, on 09 April 2017 - 03:26 AM, said:

Still doesn't resolve the issue with the new ORTS new shape format, I'm not suggesting/asking for an exporter from 3DsMax to .S format, all I'm saying is that it is actually a pain in the a** to export these days to ORTS if you're a 3dsMax user.

Someone said that you could make high detailed trains in the actual .S format, which is true, but then you have to separate the train in at least, 2 .S files if you're going through Gmax... So if ORTS would work with a new format + support the .S file for users creating with old tools, is here when I ask for a export plugin from 3DsMax and to ORTS.

Plus unfortunately, with the .S file format you can do reverse engineering, and sadly in the Spanish community, we've had other communities doing this and publishing content not fully developed by them as if they were the original authors, so yeah...

There are good reasons to extend or replace the .S file. For example, its data storage format is not all that DirectX friendly - most data has to be heavily processed before handoff to the GPU. And some aspects of its architecture inhibit efficient instancing within a model. For example every freight car has mesh data duplicated four times to represent the wheels, when really of course there should only be one copy instanced across the four wheel locations. And there are others. But the .s file is not all that easily replaced, few other 'common' open formats do a better job while still supporting essential features like LODs and Animation.

However even if we switch to a new format, your objectives are not likely to be met. We have already discussed the issues with supporting an expensive, closed commercial program like 3DsMax. The most you might hope for is that someone builds an importer for something 3DsMax can generate, Collada for example, to convert to something OR can read - .S or its future replacement.

And your second objective of securing your work from theft is technically impossible to accomplish with an open format and open source software. Open Rails has to have the decryption key. And if OR has the key, so does everyone else.

[Eldorado.Railroad]

Guille592, on 09 April 2017 - 03:26 AM, said:

Still doesn't resolve the issue with the new ORTS new shape format, I'm not suggesting/asking for an exporter from 3DsMax to .S format, all I'm saying is that it is actually a pain in the a** to export these days to ORTS if you're a 3dsMax user.

Someone said that you could make high detailed trains in the actual .S format, which is true, but then you have to separate the train in at least, 2 .S files if you're going through Gmax... So if ORTS would work with a new format + support the .S file for users creating with old tools, is here when I ask for a export plugin from 3DsMax and to ORTS.

What I will address here is that learning program interfaces is very time consuming.

Novices to Blender (including myself to some extent!) have to relearn where things are and how to do them. Blender also allows the user to make/modify importers/exporters. If you cannot use Blender, I would suggest exporting your model with UVs intact to something like 3DCrafter. 3DCrafter does not cost a lot of money, but it does have a MSTS shape file exporter that just works, even with polygon counts in excess of 200,000. The exporter is NOT fast when you are dealing with polygon counts that are that high, and its weakness is that you have NO control over how subobjects are created. But what you can do is run multiple instances of 3DCrafter, in my case 6, and each compilation occurs across one CPU core. As with all 3D programs, 3DCrafter has its annoying quirks to deal with. But it does deal with sorting of alpha objects such that you do not need things like PolyMaster.

3DSMax is a very powerful program and in some sense, too complicated for just making train models with the MSTS .s file. I really do not think that we should ever abandon the .s format as without its "openess", OpenRails would never exist. I do not see anybody creating an open source sim for rolling stock etc from Railworks. Multiple layers of encryption ensure that is hard(er) to do.

[sergio]

disc, on 12 October 2015 - 02:35 PM, said:

GPZ implemented gltf support, but he is inactive since months.

glTF 2.0

Im am very noob on this area, but i see nice things here
http://i.imgur.com/dKblyL2.png
They tell that is the jpeg of 3d.
Is getting updates.
it supports pbr materials, skining, animation key frames, png and jpg texture.

Blender will get direct export
Autodesk drag and drop FBX -> glTF translator

"-Proven by implementations using WebGL, Vulkan and Direct3D"
https://www.youtube....h?v=CHC3iwPKQAY

info on website
info on pdf

[James Ross]

sergio, on 09 April 2017 - 12:53 AM, said:

PBR system in Open rails would be outstanding but if we could get a shader system similar to DGT Train Simulator 2016 would be better than the current MSTS.

What in particular is it you like about their shader system?

I had a look at the copy on my machine and, apart from the amusing find of "App.fbk" from MSTS (with updated contents but still a SIMIS format file!), it looked mostly like they've got a much longer list of shaders than MSTS, but also including some that clearly take 2+ textures. Is it this bigger range of available shaders, or is there some other material configuration as well?

sergio, on 09 April 2017 - 08:54 AM, said:

glTF 2.0

IIRC this was a good candidate. We'll have to go back and check what other options are available, but I'd like to decide on a format for OR 1.3 (per roadmap), even if we don't necessarily have it fully implemented.

[sergio]

James Ross, on 10 April 2017 - 01:23 PM, said:

What in particular is it you like about their shader system?

I had a look at the copy on my machine and, apart from the amusing find of "App.fbk" from MSTS (with updated contents but still a SIMIS format file!), it looked mostly like they've got a much longer list of shaders than MSTS, but also including some that clearly take 2+ textures. Is it this bigger range of available shaders, or is there some other material configuration as well?

In particulary nothing special but is nice to see the environment mapping reflecting on trains windows and the SSAO to stand out the modeling details, i thing the graphics are outdated but still better than MSTS.
So is the bigger range of shaders not the quality.

[btrs]

I think it is time to start the debate again on the new shape file format. More and more models are becoming OR-only (50000+ polys, 4096 px textures, ..) and continuing to support the antique .s format with its quirks is a nuisance.

As for the exact format, if we take James' list in post 52 (http://www.elvastowe...444#entry212444) it really boils down to 2 choices:

* glTF 2.0, with additional extensions for usage in the simulator (attachment points for bogies, pantographs, custom animations)
* A completely custom proprietary format optimized for the sim only.

The last option does entail the creation of a converter program or exporters for the 3D modelling programs..
For instance Zusi 3 uses this option: it has a shape converter/viewer that imports .x (DirectX 9 format) models from Blender and exports it into its own .ls3 format.

Collada may be nice as an interchange format, but I don't see it working well in a real-time game engine. OBJ has no support for animations as already mentioned and also no modern shader support.
3DS is a format from the DOS-era and should be avoided at all costs as well.

[Goku]

Creating custom proprietary format isn't good idea. In that case better extend .S file format, which is really good.

So, we have two choices:

- use widely supported format
- extend .S file

I don't know if "glTF 2.0" is good, because it describes all assets for a scene, and game engine has to have shared assets. For example different 3d models can use the same texture file.

[ErickC]

Some thoughts...

-Just about anything can export to standard .x format, even GMax, if one edits the materials in an MSFS .x file. Just a thought.

-Might it make sense, when more advanced shaders arrive, to handle additional maps in much the way night textures are handled now? Let's say, for example, we have a specular map and a bump map. Could we put texture files with the same name as the diffuse into /specular and /bump folders? That way, the model builder doesn't have to do anything special, if they're enabled in the .sd file, they work, if not, the sim doesn't look. Then older models could be "retrofitted" if creators so desired.

-If environment maps become part of the equation, I would recommend that the intensity be controllable via texture. A hypothetical setup that has served me well on other platforms is:

-Diffuse map alpha controls transparency
-Specular map controls specular highlight colour (thus intensity), alpha channel controls reflection intensity
-Bump map is as bump map does

-I would also recommend a global environment map with the option for the creator to specify a unique one. That way, those who don't want to make an environment map don't have to waste time on it (although real-time environment maps are definitely feasible with current computing power - see P3D - but might be better suited for much later development). This would require someone to make a global environment map. I could probably do that.

-I know there are a fair amount of people who like the idea of going the Trainz route for couplers and trucks and other parts, but I recommend against it. One, it's completely unnecessary, two, it sounds tedious and annoying. At the very least, allow us to do it either way. There is no need to do things the way the other guy does it for the sake of doing it the way the other guy does it. For example, coupler shanks could be very easily animated if they had two components - a rotation component and a motion component. The rotation component (probably a dummy) could respond to a set of parameters in the .eng file, not requiring animation (like trucks), whereas the motion component could be animated with full extension at frame 0, full compression at frame 100, and then the range of motion in the .eng file set to match. This would be absurdly simple. Suspension could be handled similarly.

-I am very, very glad that the OR team has decided against tightening Autodesk's death grip on the gaming industry. Kudos!

[SP 0-6-0]

The Trainz approach I can see the reasoning behind but I don't really support the idea all that much. I do agree the the SD file could be used more extensively than it currently is in MSTS. By definition the SD file is the Shape Definition file and could hold alot of data on how a shape is supposed to be loaded and rendered into the simulation.

I do remember the issues from the early days of MSTS models not being able to be animated correctly because of limitations of the .S file. The Milwaukee Road EF4 electrics come to mind.

However, A select few modelers have been succesful in getting large models with alot of moving parts into MSTS in one .S file as one complete object. German modeler Mad Mike was able to built a Milwaukee Road EP2 electric as one single shape and is fully articulated and animated in MSTS as a model built sometime between 2002 and 2003.

I feel there is alot still not fully known about the capabilities of the .S file? I feel the real limitation is more likely MSTS and crude modeling programs like TSM than any limitation of the .S file format.

Robert

[captain_bazza]

Isn't the .S format a derivitive of the .X format? MSTS was the "child" of Microsoft and both formats were theirs.

CB.