Multiple FreightAnims in OR ?

[GoGoran]

Hi,

just a small suggestion there, which could make a lot of difference for many users and creators:

Could OR enable the use of multiple FreightAnims ?

I thought about a number of up to 11 per waggon or locomotive, i.e. the normal MSTS-FA and ten additional ones, coded as "Comment ( FreightAnim0 ..." thru "Comment ( FreightAnim9 ..." or something along those lines for keeping basic MSTS-backwards-compatibility.

The background being that many, if not most, current locomotives come factory-equipped with a FreigthAnim, making changes or additions for repaints impossible, unless you touch the original shapes ... whereas with additional FAs, there would be much room for all sorts of changes without touching the original shape. Other applications include loading empty waggons with more than one shape, i.e. a truck and a jeep, or a container and a machine part, etc., without having to unite them in a 3d program like gmax (which involves quite a lot of work and requires advanced skills at any rate).

[mstsbe]

I already asked that question some 6 months ago, although nobody found it important enough to answer...

I again want to visit the topic "freightanim". In Europe, some repainters make a freightanim to add inscriptions, logos, or to add parts to a loco for which they don't have the original model files (and the original author lost them).

Will openRails support more than 1 freightanim ? In this way we can spread different parts over different models. I don't know if this will be more performance-friendly than 1 "big" model however...

When openRails will switch to its own modeling format (which was already discussed in the other thread), wouldn't it be better that openRails implements a Trainz-style model behavior ? I mean: in Trainz models have several attachment points (a.bog0, a.bog1, a.pant0, a.pant1, ..) for different model parts like bogies/trucks, pantographs, couplers etc.

[longiron]

While the OR team has not spent a lot of time discussing support multiple "freightanim", we are discussing how to make train content more modular (i.e. re-use trucks, couplers, bodies, etc). Beyond the customization possibilities, there are some potential performance advantages of not loading the same mesh & texture 50 times or more during an activity. However, the modular content approach demands some kind of content management system in order to map the dependencies and ensure all the parts are available at run time. The OR team is just in the stage of kicking around pro's and con's of the strategy and the implications (storage, file and the like).

[GoGoran]

While the OR team has not spent a lot of time discussing support multiple "freightanim", we are discussing how to make train content more modular (i.e. re-use trucks, couplers, bodies, etc). Beyond the customization possibilities, there are some potential performance advantages of not loading the same mesh & texture 50 times or more during an activity. However, the modular content approach demands some kind of content management system in order to map the dependencies and ensure all the parts are available at run time. The OR team is just in the stage of kicking around pro's and con's of the strategy and the implications (storage, file and the like).

Thanks for this information, longiron.

Unfortunately this does not answer my question. The concept of modular models which you laid out above sounds interesting, but complicated and has no direct relation to the plain old concept of FAs. I hope you will seriously consider to implement multiple FreightAnims, if possible.

[3Directions]

Thanks for this information, longiron. Unfortunately this does not answer my question. The concept of modular models which you laid out above sounds interesting, but complicated and has no direct relation to the plain old concept of FAs. I hope you will seriously consider to implement multiple FreightAnims, if possible.

There's some merit in what you're looking for imho,in particular the wagon loads.A lot of what you mention,,repaints or road specific parts, think MARS lights,ditch lights and similar , would be possible in the system mentioned by longiron i.e. instanced/referenced/xRefed mesh items and textures , taken to extreme/out of the box thinking it would be possible to "build" a complete locomotive with the user supplying nothing more than the appropriate texture sheets and an plain text or XML file referencing community supplied prebuilt items .

A content management system with a dialog box for choosing parts would be good ... Max xRef is a good example

I'm interested in what happens with this idea .