ORTS new shape format???
#131
Posted 20 September 2019 - 07:51 AM
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
Posted 21 September 2019 - 01:47 PM
btrs, on 20 September 2019 - 06:16 AM, said:
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
Posted 11 October 2019 - 02:49 AM
captain_bazza, on 16 September 2017 - 06:50 PM, said:
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
Posted 11 October 2019 - 04:23 PM
disc, on 16 November 2016 - 06:58 AM, said:
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
Posted 11 October 2019 - 04:55 PM
Genma Saotome, on 03 December 2016 - 02:06 PM, said:
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
Posted 12 October 2019 - 04:36 AM
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
Posted 13 October 2019 - 01:49 PM
AuzGnosis, on 11 October 2019 - 02:49 AM, said:
purpose clearly in mind. ....
Today I stumbled on following introduction;
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
Posted 10 January 2022 - 06:13 PM
- 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
Posted 10 January 2022 - 08:28 PM
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
Posted 12 January 2022 - 04:45 AM
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.