[captain_bazza]

Intro....

[captain_bazza]

As of version 1170, most of the MSTS protocols appear to still work in OR. Source files are .BMP or .TGA depending on their purpose. Alphas (.TGA) work okay once you get the hang of the display order. MSTS based protocols and MSTS based conversion tools are still required.

OR handles 32bit/24bit standard skinning textures in square format, ie 32x32, 64x64, 128x128, 256x256, etc ~ through to 2048x2048 and it's rumoured also 4096x4096.

2d cabview texture protocols are a different ballgame. See the MSTS original documentation.

I only use ZLIB compression, so perhaps someone might like to comment on other compression protocols, thanks.

The above information may change at a future date.

Cheers Bazza

[Lindsayts]

OR, well the cabview in v0.7 anyway will handle textures larger than 2048x2048 and will handle rectangular textures. I having tried 2560x1600, worked OK. Although my default resolution for the hi-res cabviews is 2048x1280. Note, these are the textures sizes actaully used.

Lindsay

[thegrindre]

I threw together a small corner Open Rails logo for any Open Rails models exclusively..
You are welcomed to use it for any OR models of your own.

Here's a blown up shot for clarity.


The original 64x100 bit map file can be DLed here;
 ORmodelLogo.zip (9.06K)
Number of downloads: 563


I'm using it like this;



:wub:

[captain_bazza]

The trick is how to define what the difference between and OR and MSTS compatible model.

At the moment, I believe that would be too difficult to define a certain standard, unless at some stage OR allows model functions (including additional shaders) that will not work in MSTS. Model complexity is also a factor.

I guess the best method of testing scenery type objects built for OR, is to choose a test route and install models in it. The route should be one that can easily be reinstalled and one you can avoid opening in MSTS.

Cheers Bazza

[thegrindre]

As I mentioned elsewhere, any model that won't load or run in MSTS but will, for whatever reasons in ORTS, would constitute an Open Rails model. Be it special texturing techniques, exceptionally high polygon count or any additional wagon or engine file additions that MSTS doesn't recognize.
That's putting it in a nut shell but is pretty easy to understand, IMHO. :pleasantry:

:oldstry:

[captain_bazza]

Quote

As I mentioned elsewhere, any model that won't load or run in MSTS but will, for whatever reasons in ORTS, would constitute an Open Rails model.

That's a good starter. :pleasantry:

Cheers Bazza

[B & O GUY]

Quote

The trick is how to define what the difference between and OR and MSTS compatible model.

At the moment, I believe that would be too difficult to define a certain standard, unless at some stage OR allows model functions (including additional shaders) that will not work in MSTS. Model complexity is also a factor.

I guess the best method of testing scenery type objects built for OR, is to choose a test route and install models in it. The route should be one that can easily be reinstalled and one you can avoid opening in MSTS.

Cheers Bazza

Quote

As I mentioned elsewhere, any model that won't load or run in MSTS but will, for whatever reasons in ORTS, would constitute an Open Rails model. Be it special texturing techniques, exceptionally high polygon count or any additional wagon or engine file additions that MSTS doesn't recognize.
That's putting it in a nut shell but is pretty easy to understand, IMHO.

Guy's

I'm building models in what would be considered past the ability of MSTS to load. Their not in the terrible range but have more animation's and more poly's than some of the high poly models that currently work in MSTS. And although it has been said somewhere here that a few have 100,000 poly models in MSTS that cause no problems, they have few complex shapes in them. The complexity of shapes is what causes the problems in MSTS but have little affect on OR. OR is way more flexible when it comes to model's with no or few sub object's in their makeup. OR is the easy path to victory. Too bad some of the new aspiring modelers out there haven't discovered this yet.

Allen

ADDY; Open Rails will run models with NO textures. No kidding.

[Mipman25]

That's pretty interesting, Allen. Would separating a high-poly model into two pieces (i.e. Tom Werb's Baldwin 4-4-0) allow it to run in MSTS, or would texture and animation quirks get in the way?

[B & O GUY]

Dustin

This is an Open Rails discussion forum. We're talking about model definition. Not what if's.

Allen

[captain_bazza]

Separating a model into two, or three, individual component 'locos' is an old MSTS dodge. When it's done well it works well but is very complicated to setup. But the problem is how complex are the sub-objects that comprise a model.

MSTS can be surprisingly forgiving, but it also likes playing tricks on the unsuspecting. IME, each model is an experiment, whether it's for MSTS or OR, and some models win, some don't.

Cheers Bazza

[Genma Saotome]

That's one reason Barry why I proposed being able to logically "combine" multiple models as-if they were one, be it freight cars or static structures. IMO the combination instructions belong in something that's roughly equivalent to the .sd file. Looking at it from the outside, the file would appear to be for a single model. Open it up and look inside and there you find the instructions for using multiple models. In the ideal, include a means to substitute textures too.

I suppose the short of it is this: take the hierarchy of any car or locomotive, break them into individual models, and use the kind-of .sd file to reassemble the hierarchy. The fun of reskinning suddenly morphs and expands into doing restructuring as well.

Such an approach would give OR the means to reuse complex models, like trucks (bogies) or (if the original modeler was kind enough to build it this way) to pull off a steam locomotive cab model and replace it with a different style (different windows, longer overhead, whatever).

[captain_bazza]

Hi'ya Dave, perhaps this would work better for AI type stock? Or for models of common stock types. But there will always be the need for individual types, too, such as you frequenly see on narrow gauge setups.

Cheers Bazza

[Lindsayts]

Genma Saotome, on 21 August 2012 - 06:04 PM, said:

That's one reason Barry why I proposed being able to logically "combine" multiple models as-if they were one, be it freight cars or static structures. IMO the combination instructions belong in something that's roughly equivalent to the .sd file. Looking at it from the outside, the file would appear to be for a single model. Open it up and look inside and there you find the instructions for using multiple models. In the ideal, include a means to substitute textures too.

Openbve works this way using the xxx.animation file. The file format has instructions for tranlating, rotating and scaling as well as changing textures of objects, all from some kind of definable external trigger. The primary use is to of course animate anything but it can also be used to construct complex objects out of a lot of simple objects (Note, it is specified one can do this in the animation file documentation). Makes it simple to make a library of regularly used items such as wheels and axles, boggies, coupling gear, pantographs, ladders etc.

Note, I have never used Openbve but I found some of its file formats suited my mind perfectly so I have used them in my own terrain simulation program.

Lindsay

[Hack]

RW has one of the better parent/child object schemes going. I've built objects where several buildings, vegetation and even vehicles are all built and defined in the parent blueprint to form one very large complex - the biggest took up an area of one-half square mile. As a single model the poly count would easily exceed 100k, but alone each object is very manageable. The position of each object is built with the usual 0-0-0/X-Y-Z axis, but is offset in parent blueprint using a matrix. Also defined in the parent blueprint is a relative path and unique ID for each child object (pointing to the child blueprint and not the object itself).