Elvas Tower: ORTS new shape format??? - Elvas Tower

Jump to content

  • 37 Pages +
  • « First
  • 12
  • 13
  • 14
  • 15
  • 16
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

ORTS new shape format??? Rate Topic: ****- 3 Votes

#131 User is offline   Rj Zondervan 

  • Apprentice
  • Group: Status: Active Member
  • Posts: 40
  • Joined: 09-March 11
  • Gender:Male
  • Simulator:MSTS/ORTS
  • Country:

Posted 20 September 2019 - 07:51 AM

Hi BTRS, I am not a team member, but I can imagine that the implementation of a new shape format is postponed to the moment the conversion to Monogame has become more stable (that is, that it is included in the testing version and is not removed from the unstable branch every now and then). That in order to make use of the possibilities of Monogame and preventing to have to invent the wheel twice, once for XNA and once for Monogame. But, once again, that's my perception as an outsider with some knowledge about software implementation, not as an insider.

Btw: I second your wish for a 3ds max converter, as that is also my 3D software of choice. I might look into building such a converter myself, but that's given that I have time to do that.

#132 User is offline   Guille592 

  • Fireman
  • Group: Status: Active Member
  • Posts: 210
  • Joined: 25-November 12
  • Gender:Male
  • Simulator:MSTS, OR
  • Country:

Posted 21 September 2019 - 01:47 PM

View Postbtrs, on 20 September 2019 - 06:16 AM, said:

since I will absolutely not be using Blender. 3dsmax is my tool of choice and I want to be able to do the complete model (including textures & UV map) there and not via an intermediate Blender conversion..


I know these feelings, hope we get someday a powerful and independent file format for rolling stock, .S would be more than enough for the buildings/scenery.

#133 User is offline   AuzGnosis 

  • Fireman
  • Group: Status: First Class
  • Posts: 113
  • Joined: 05-July 19
  • Gender:Male
  • Simulator:OpenRails
  • Country:

Posted 11 October 2019 - 02:49 AM

Been wandering through this thread getting increasing more confused till I reached Captain Bazza's line,

View Postcaptain_bazza, on 16 September 2017 - 06:50 PM, said:

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


It is even more Byzantine than that.
https://en.wikipedia.org/wiki/VRML I was involved in the whole
VRML standardization process (at the turn of the century){BUT I could be wrong from here as I lost the immediate following,
decade sick} Anyway from the little what I've seen of the human readable text-form Microsoft .S format(is nearly pure VRML
with some built-in/internal/hidden; Prototypes/Classes/Subroutines, using some other thing than Gzip to do the compression.

When one starts talking about computing, formats, graphics, languages, it is very important that you keep your final
purpose clearly in mind. One of the original features of VRML that seems to be inherited somewhere in the genetic .S format
is how the object-names maybe understandable self-documenting of the hierarchy of things being describe.

W'Shawn G

#134 User is offline   AuzGnosis 

  • Fireman
  • Group: Status: First Class
  • Posts: 113
  • Joined: 05-July 19
  • Gender:Male
  • Simulator:OpenRails
  • Country:

Posted 11 October 2019 - 04:23 PM

View Postdisc, on 16 November 2016 - 06:58 AM, said:

Many highpoly 3D cab, and exterior models still rotting in TS20xx because it would be a real pain to convert them to .s format to load in OR...

Had few years at the height VRML popularity crunching back high polygon-count to what was plausible for the web of the day to handle in real-time over copper-wire. So dare I ask exactly where be these TS20xx highpoly 3D-cab & exterior models rotting?

Thanks. Shawn in Auz.

#135 User is offline   AuzGnosis 

  • Fireman
  • Group: Status: First Class
  • Posts: 113
  • Joined: 05-July 19
  • Gender:Male
  • Simulator:OpenRails
  • Country:

Posted 11 October 2019 - 04:55 PM

View PostGenma Saotome, on 03 December 2016 - 02:06 PM, said:

Is there a reason an enhanced .s format is the wrong way to go? Going down that path would mean changing or writing new exporters. Might that be easier to accomplish than changing OR to accommodate a significantly different file type? Perhaps just one program: collada to enhanced .s. Not because collada is great for games but because most modeling software can produce a collada file.


Genma's question points to the difficulty at the heart of the whole thread. By comments relating to various features user appear to desire or use; high-polygon counts, bump-maps, meshes, u-v mapping, colours & textures in the history of computer graphic [CG] many of these items were mutually exclusive due to the technical philosophy underpinning the initial graphic files creations, along with the intend function. Bump-map & meshes were originally strategies for avoiding large polygon counts.

Thanks Shawn in Auz.

#136 User is offline   scottb613 

  • Vice President
  • Group: Status: First Class
  • Posts: 2,973
  • Joined: 06-July 09
  • Gender:Male
  • Location:Downeast Maine (soon)
  • Simulator:ORTS
  • Country:

Posted 12 October 2019 - 04:36 AM

Hi Folks,

My desires are a tad less ambitious (I think):

Support texture directories where a simple line in the ENG/WAG defines which texture is applied to the shape - negates need to have numerous copies of the shape for each and every texture variation...

Support fallback texture directories - where you can specify a default if the texture isn’t found in the specific paint directory - for the stuff that wouldn’t normally change between various paints...

Unlink any and all requirements between LOD’s - a LOD model should not have any dependencies on previous or subsequent LOD models...

Support bump maps...

Support PBR textures - we’re just getting into using PBR textures on Flight Sims and they make a substantial difference...

Regards,
Scott

#137 User is offline   AuzGnosis 

  • Fireman
  • Group: Status: First Class
  • Posts: 113
  • Joined: 05-July 19
  • Gender:Male
  • Simulator:OpenRails
  • Country:

Posted 13 October 2019 - 01:49 PM

Previously I wrote;

View PostAuzGnosis, on 11 October 2019 - 02:49 AM, said:

When one starts talking about computing, formats, graphics, languages, it is very important that you keep your final
purpose clearly in mind. ....

Today I stumbled on following introduction;
"There exist many different file formats for storing polygon mesh data. Each format is most effective when used for the purpose intended by its creator. Some of these formats are presented below: "

Followed by a detailed table at the bottom of this webpage;
https://en.wikipedia...ki/Polygon_mesh

Hope that is helpful for folks. W'Shawn Gray

#138 User is offline   Serana 

  • Conductor
  • Group: Status: Contributing Member
  • Posts: 489
  • Joined: 21-February 13
  • Gender:Male
  • Location:St Cyr l'Ecole (France)
  • Simulator:Open Rails
  • Country:

Posted 10 January 2022 - 06:13 PM

Not really the right moment to restart the discussion. Just wanted to add some info about glTF 2.0 in order not to forget it.

- Microsoft and Asobo have decided to use glTF 2.0 as a shape file format for Microsoft Flight Simulator. So they recognize the format is mature enough to base their game on it and the user base is growing quickly. (https://docs.flights..._Principles.htm)

- MonoGame considers fully supporting glTF 2.0. Currently, support is basic. They are creating a new 3D model C# class in order to support all functionnalities. (https://github.com/M...ame/issues/7371). The first demo uses a library called SharpGLF (https://github.com/vpenades/SharpGLTF) made by one of MonoGame's contributor. I don't know yet which MG version they are targeting.

#139 User is offline   wacampbell 

  • Member since Nov. 2003
  • Group: Fan: Traction Nuts
  • Posts: 2,342
  • Joined: 22-November 03
  • Gender:Male
  • Location:British Columbia, Canada
  • Country:

Posted 10 January 2022 - 08:28 PM

> gltf

I agree. A good candidate for OR. It’s optimized for real time, loads fast, supports modern shaders, is well supported by 3d model building software. But some work needed to standardize support for lods.

#140 User is offline   gpz 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,771
  • Joined: 27-October 12
  • Gender:Male
  • Location:Budapest
  • Simulator:OpenRails
  • Country:

Posted 12 January 2022 - 04:45 AM

I'm actually experimenting with adding glTF to OpenRails. Some years ago I attempted to make a loader for 1.0 shapes, and could load even skinned shapes, but I stopped with the work because at that time there were extensive efforts by Khronos to create the 2.0 specification, and it was a moving target. But a couple of weeks ago I've updated my study loader to the 2.0 spec. The geometry is easy, but I'm struggling with adapting that PBR lighting stuff, those #&@!%/ matrices never want to screw the same way that I want, I hate these shaders. :-) It is happy when they work for the first time after a modification, but when not, it is extremely hard to debug them. The best debugger I've found is RenderDoc, it is possible to grab a generated frame, which is actually a screenshot containing all the state changes and drawcalls that produced that picture. It is possible to analyze the finest details of any drawcall, any object, even a pixel how that got the color it has, or disassemble the shader and see step-by-step how the registers change when it runs.

By the way, glTF has an official Microsoft extension for lods: https://github.com/K...Vendor/MSFT_lod
Interestingly it is not the method what is used in MS Flight Simulator. There each lod is saved as a separate glTF file, and the screen coverage setting is managed externally.

I wouldn't count on MonoGame support. Even if it will have it, that will be integrated into their own model structure, possibly for being able to load only preprocessed at authoring time, as it is now with their other model classes, and which would not work for the OR. And honestly, I'm not sure that MonoGame is not a dead end. It stuck with DX10 for years, and I don't see much bustle around updating its architecture. But this is just my sentiment, we will see.

  • 37 Pages +
  • « First
  • 12
  • 13
  • 14
  • 15
  • 16
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

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