Practical use of LOD's
#12
Posted 23 December 2012 - 10:34 AM
wacampbell, on 22 December 2012 - 05:45 PM, said:
The .s file format already supports this. It has provisions for a separate view sphere center and radius for each LOD and each sub-object within the LOD. Its just that I've never seen any of the 3D exporters actually use the feature.
....Which begs the question, why is it that a shape compiler for Open Rails is not yet available? The Open Rails simulator would benefit from the direct optimizations that its own shape compiler would produce. Given that the structure of the original MSTS shape file has not been a mystery for many years now, and indeed the only reason that Open Rails works is because a DLL can read its contents successfully, the logical conclusion is to have a compiler that will generate shape files FOR Open Rails that avoids the shortcomings of other commercially available compilers that are only really exporting for the limitations of MSTS Bin. People who have been modelling for Open Rails only, because MSTS Bin will not load that shape file already know using the current MSTS compiler tools are a "crapshoot" as to what will and will not work. Given the inertia over what shape file format OR will use, as its native format, creating .s shapfiles that are optimized for Open Rails is the way to go for the foreseeable future. Not being able to load those shape files into MSTS Bin is a moot point, because that is already happening anyway.
Anybody who uses 3D Crafter/Canvas as is presently available will know that the .s compiler forces subobjects at the 3000 polygon limit. From what I read here that means that a 90000 polygon model is going to force more primitives in Open Rails when the limit per subobject is 3000 polygons. An Open Rails .s compiler could circumvent that "rule" and allow for much larger groups of polygons, which would reduce the number of primitives.
It is troubling that the concern seems to be the sanctity of the MSTS shape file when it has already been "broken" years ago, how else would a non MSTS viewer like ShapeViewer exist, not to mention Open Rails? Both of these allow the viewing of "huge" .s files, circa 2012.
Eldorado
#13
Posted 23 December 2012 - 10:53 AM
Patience Eldorado ....
We are not married to the .s file and will introduce a replacement when the time is right. But all of that has to wait until our route editor is ready. For now we are tied to using the MSTS RE, and the .s files. The .s file format isn't in our way right now and for the near future we can achieve our goals without making changes.
Although someone could perhaps write an OR optimized compiler for the .s files now, I think it would be too soon as there are likely many more changes to the graphics processing and what is optimal now, might not be optimal by the time we reach a final product.
We are not married to the .s file and will introduce a replacement when the time is right. But all of that has to wait until our route editor is ready. For now we are tied to using the MSTS RE, and the .s files. The .s file format isn't in our way right now and for the near future we can achieve our goals without making changes.
Although someone could perhaps write an OR optimized compiler for the .s files now, I think it would be too soon as there are likely many more changes to the graphics processing and what is optimal now, might not be optimal by the time we reach a final product.
#14
Posted 23 December 2012 - 11:49 AM
First, people should not infer that any combination of the words .s file and replacement means the .s file would no longer work in OR. We just tend to use the word "replacement" because it takes less time to type it than "recommended alternative format that is better because it can do more"... the key word being alternative.
Second, when the subject of replacing .s files comes up everyone needs to be aware that another format probably also means replacing the various exporters for each of the popular CAD tools... or using a tool-neutral intermediate step such as collada from which the in-game OR files would be produced. If the former situation occurs, one should not assume all of the tools in use today would be ready at the same time... indeed, some might not ever be ready, a fact that could be very problematic for some significant number of people.
Second, when the subject of replacing .s files comes up everyone needs to be aware that another format probably also means replacing the various exporters for each of the popular CAD tools... or using a tool-neutral intermediate step such as collada from which the in-game OR files would be produced. If the former situation occurs, one should not assume all of the tools in use today would be ready at the same time... indeed, some might not ever be ready, a fact that could be very problematic for some significant number of people.
#15
Posted 05 January 2013 - 09:31 AM
wacampbell, on 22 December 2012 - 05:45 PM, said:
The .s file format already supports this. It has provisions for a separate view sphere center and radius for each LOD and each sub-object within the LOD. Its just that I've never seen any of the 3D exporters actually use the feature.
The Gmax gamepack exporter supports this feature.
#16
Posted 05 January 2013 - 06:37 PM
Just a wee bit of praise for the old shape format file - uncompressed it can be read (but maybe not everything understood) in plain english. This is very useful for checking certain things, such as the list of texture file names. You can also tweak many aspects of the model, as well as adjust the animation playback rate, etc.
Cheers Bazza
Cheers Bazza
#17
Posted 18 February 2013 - 01:27 AM
Just looked at this thread most interesting, A comment though for Captain Bazza,
Having as many file formats as possible as text files is almost a must, in my opinion any way.
There are a number of shape file formats that are text based, currently in use some of them are..... (theres bound to be others)
B3D (currently used in OpenBVE),Wavefronts obj, VRML.
Now I THINK the original model files for doom were just text files using the C language, basicly just defined data stuctures, total number of Vertex's limited to a relatively small number though.
Blender already exports to obj, I believe some one has got the B3D exporter updated to the 2.6 series. The previous major version of blender (the 2.4 series) had an in house exporter to VRML, so an up date should not be to far away.
So support sort of exists to some extent anyway,
Lindsay
Having as many file formats as possible as text files is almost a must, in my opinion any way.
There are a number of shape file formats that are text based, currently in use some of them are..... (theres bound to be others)
B3D (currently used in OpenBVE),Wavefronts obj, VRML.
Now I THINK the original model files for doom were just text files using the C language, basicly just defined data stuctures, total number of Vertex's limited to a relatively small number though.
Blender already exports to obj, I believe some one has got the B3D exporter updated to the 2.6 series. The previous major version of blender (the 2.4 series) had an in house exporter to VRML, so an up date should not be to far away.
So support sort of exists to some extent anyway,
Lindsay
#18
Posted 18 February 2013 - 03:07 AM
Quote
Now I THINK the original model files for doom
The original Wolfenstein 3D and Doom, were the ONLY two video games I ever 'clocked'. Everything else I got bored with and never completed....yet I spent many hundreds of dollars buying them. Hmmm, I may have got through the original Lara Croft adventure.
Cheers Bazza
#19
Posted 18 February 2013 - 10:03 AM
captain_bazza, on 05 January 2013 - 06:37 PM, said:
Just a wee bit of praise for the old shape format file - uncompressed it can be read (but maybe not everything understood) in plain english. This is very useful for checking certain things, such as the list of texture file names. You can also tweak many aspects of the model, as well as adjust the animation playback rate, etc.
Cheers Bazza
Cheers Bazza
Barry, you'd like the collada format then as well.