[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).

[Genma Saotome]

 captain_bazza, on 21 August 2012 - 08:11 PM, said:

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

I don't see why AI rolling stock would have any different requirements than player rolling stock. Different content specifics, sure, but the same requirements for what is represented. As for NG, even NG cars often use identical trucks and couplers, brake gear too.

IMO it really comes down to being limited by what the original modeler thinks is truly custom vs. what could be reused. We don't think that way too much now because it's often too hard to reuse things -- or if we do reuse something, it's darn near impossible to edit all of the copies later on.
================

Anyway, this thread is about textures isn't it? Try this on for size:

Waaaay back in the dark ages of computing (that means pre-pc) virtually all computers used punched cards as the means to receive commands from a user. One of the typical features in this environment was remapping the name and location of a file from whatever it was encoded in the program to something else you wanted it to use instead. It usually looked something like this: The program wanted to read a data file so the programmer called that file something generic, like "InputFile1", and then on the punched card you remapped that generic name to a real file name, something that might have looked like "$InputFile1 = \path\cds4010d".

I mention all of that to contrast it with what we see with texture files within our cad files. If the cad file says to use MyLocomotive.ACE, you darn well better have a file called MyLocomotive.ace, something which leads reskinners to call completely different artwork MyLocomotive.ace too. OTOH, if we could do things the same way as the old computer hacks used to do, we could let the cad file call each texture by whatever name and then outside of the cad file, somewhere, map that name to a real file. IOW, doing MyLocomotive.Ace = \path\ATSF3661.Ace. The question is where is that somewhere?

IMO the obvious location is a modified .sd file. In this environment, one could have a single .s file of, say, a Santa Fe steam locomotive, a dozen .sd files all uniquely named, say, ATSF3661.sd thru to whatever, each one of which remaps the texture name of the mesh file to a real texture file, unique for each locomotive, and a dozen corresponding .eng files of the same names. The only change needed in the .eng files is the line where today's .s file name is entered -- it would need to be the .sd file name instead.

One mesh, 12 unique texture files, 12 unique .sd files, 12 unique .eng files, all in one directory. (Special n.b., to Marc Nelson: Think _SWT_ in particular).

Now, if a reskinner wants to add his own contributions to the above, he can name his files differently than those already in use.

A side benefit would be, IMO people would put a different meaning into their files than they do today. The directory and mesh file names used in the above example might be based on the ATSF locomotive class. The .eng and texture file names might all be based on the locomotive number. If you think about it, it's a much more sensible way to build and maintain a roster than what we're all used to from MSTS.

[Eldorado.Railroad]

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

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.

Isn't this exactly what is done with FAs in MSTS? There are quite a few models out there (even here at ET) that are split into two. The base, usually the movable stuff like bogies and wheels, and the FA for all the rest. Did I miss the point here? I remember reading somewhere an inquiry into allowing multiple FAs to be loaded from an .eng file with Open Rails, this would work exactly as required, i.e. a model could be split into multiple parts and used or excluded for viewing in the sim.

Example:
FreightAnim ( Part1_FA.s 1 1 )
FreightAnim ( Part2_FA.s 1 1 )
FreightAnim ( Part3_FA.s 1 1 )

There is already a precedent for this, that is the way smoke and steam are handled in OR where multiple "Exhaust1" statements are already "allowed" and displayed. (Personally very happy about that one!)

What I think would be very useful would be a method in Open Rails, where a models polygons, eg. a boxcar, would be loaded once and only once, and the renderer would affix the textures onto that common polygon frame. Right now, if you have a directory full of boxcars that use exactly the same polygon frame, and of course different textures, you not only have to load up the textures, but the boxcar polygons over and over, consuming a tremendous amount of memory.

Eldorado

[captain_bazza]

I've not used FA in any of the models I've made for OR only. It's interesting that OR actually allows more than one. FA in MSTS has a bug, sometimes the FA would flash off and on at some POV. I don't know if this occurs in OR, perhaps someone could comment?

What could be useful with FA, if used in OR, would be to have a LOD definition. This would allow the FA to be invisible at certain distances, or under some lighting conditions, such as night, etc. Even under some weather conditions..

Cheers Bazza