[Lindsayts]

I apologise for the size of the image, its required to see the required detail.

Below is a cabview showing what OR can now do in 2D cabs.



This is the entire cabview, of a SAR Bluebird railcar, Note the two rotary switchs, some what left of centre on the panel




Here is an inset of the two switchs concerend, the left hand one is standard MSTS fare. the right one (the reversing) control has been done in hi-res.
It is a three frame animation each frame being 200x200 note how sharp it looks. I normal use some amount of 2 pixel blur as it blends the item into the background better.
Note the image manipulation on the switch was done at 1500x1500 pixels, when each frame was finished it was scaled down to 200x200 and copied onto the final texture.

Basicly any cab control (includiing text windows) can now be animated with this clarity.

Below is the appropriate part of the CVF. The scaling is controled by the last two digits of the "Position" statement.

                TriState (
                        Type ( DIRECTION TRI_STATE )
                        Position ( 445 397 35 35 )
                        Graphic ( Switch_nob_3.0_Transmission.ace )
                        NumFrames ( 3 3 1 )
                        Style ( NONE )
                        MouseControl ( 1 )
                        Orientation ( 0 )
                        DirIncrease ( 0 )
                )

It would probably be worth while to include this in the manual to show what is possible.

Lindsay

[elvasleis]

Hi Lindsay,
A bad cabview spoils a good model.
Any thing that enhances a cabview I fully support.

Regards Geoff.

[Lindsayts]

elvasleis, on 17 May 2015 - 06:43 PM, said:

Hi Lindsay,
A bad cabview spoils a good model.
Any thing that enhances a cabview I fully support.

Regards Geoff.

I quite agree, Its the exact reason I chose to go down this path, 2D cabviews being both easier to display and easier to do.

It being quite possible now in OR to do a REAL first class 2D cabview.

There is nothing at all wrong with 3D cabs, to do a good job requires a good deal of work and being able to use a program such as blender or some other like it.
A friend of mine who is a beta tester for Trainz told me the difficulty of doing a good 3D cab is holding back loco development in that sim.

2D and 3D cabs should not been seen as enemies, just a different way requiring different skills, a "horses for courses" situation.

A final point an MSTS cabview is seen as difficult to do, this quite puzzles me as I did not take me long to find my way around cabviews without using the MSTS cabview editor.

Lindsay

[captain_bazza]

That includes the lack of suitable reference material for cabs of any MPU.

Cheers Bazza.

[Lindsayts]

captain_bazza, on 24 May 2015 - 03:52 AM, said:

That includes the lack of suitable reference material for cabs of any MPU.

Cheers Bazza.

Sorry, the above line is not clear, what reference material and whats an MPU.


The real big problem in doing cabviews is a lot of them are real shoe box's, the SAR Bluebird in fact being one of the worst but most mainline locos are little different.
It being nearly impossible to get a good clear photograph without severe perspective distortion. With most steamers one at least has a bit of space.

LIndsay

[dekosoft]

Nice, thanks for the tip!

[captain_bazza]

MPU is Motive Power Unit, a generic term that covers all types of powered head of train unit, ie steam, diese-electric, electricity, etc.

Reference material is plans, photos, etc, of use when making a 3d model of a type of cab. Such internal POV material is rare compared to external POV prototype photos or plans.

Cheers Bazza

[superheatedsteam]

I am working on a 2D loco cab and having problems with the scaling values in the position function.

Position ( 155 348 x y )

Using the above for reference, if I change the 'y' value the animation graphic scales as documented. However changing the 'x' value appears to have no effect on the scaling. I have tried values form 0 to 100 with no visible effect.

This is for a MultiStateDisplay > Type ( THROTTLE_DISPLAY MULTI_STATE_DISPLAY ), multi-frame animation as used in the default Dash 9 locomotive.

The background 2D texture of the cab is 1920x1080. The area that the throttle_display physically occupies on this background texture is 30 x 40 pixels. I therefore created a 9 frame animation graphic comprising 3 frames across and 3 frames down that totals 90 x 120 pixels. I assumed this would provide a non distorted, pixel perfect overlay over the background image.

When in game I used the the y value to make the throttle_display fit horizontally within a border. This was fine but the vertically the graphic was only filling in 80% of the border. To work around this I increased the vertical height of each animation frame in order to fill in this space but this in turn changed the horizontal scaling in game. Do I need to perform jiggery pokery with the animation graphic dimensions and scaling factor to get it to fit pixel perfect, or am I missing something in relation to the scaling parameters for animation frames?

I am using OR v 1.0.1.3095.

Cheers,

Marek.

[Lindsayts]

superheatedsteam, on 16 October 2015 - 10:07 PM, said:

I am working on a 2D loco cab and having problems with the scaling values in the position function.

Position ( 155 348 x y )

Using the above for reference, if I change the 'y' value the animation graphic scales as documented. However changing the 'x' value appears to have no effect on the scaling. I have tried values form 0 to 100 with no visible effect.

This is for a MultiStateDisplay > Type ( THROTTLE_DISPLAY MULTI_STATE_DISPLAY ), multi-frame animation as used in the default Dash 9 locomotive.

The background 2D texture of the cab is 1920x1080. The area that the throttle_display physically occupies on this background texture is 30 x 40 pixels. I therefore created a 9 frame animation graphic comprising 3 frames across and 3 frames down that totals 90 x 120 pixels. I assumed this would provide a non distorted, pixel perfect overlay over the background image.

When in game I used the the y value to make the throttle_display fit horizontally within a border. This was fine but the vertically the graphic was only filling in 80% of the border. To work around this I increased the vertical height of each animation frame in order to fill in this space but this in turn changed the horizontal scaling in game. Do I need to perform jiggery pokery with the animation graphic dimensions and scaling factor to get it to fit pixel perfect, or am I missing something in relation to the scaling parameters for animation frames?

I am using OR v 1.0.1.3095.

Cheers,

Marek.

Its good to some taking advantage of this adavance. Now I am not the author of this code, I discovered OR could do this during a deliberate search for such a feature (Note 1). The effect you are describing is the way it works, you have to do the graphic for the animation in an aspect ratio that makes the control look right on the panel. I may say I have never had any problem with this. I always do the graphics as one sees them in real life, ie one cannot scale the aspect ratio of an animation only the graphics size, one has to set the scaling factor by trail and error as it seems to vary from cabview to cabview. (Note 2)

Have you tried my Bluebird cabview, I meant to include the original graphics in TGA format as an example so that anyone could see how I achieved the final result. Note I have only actaully done tthree control animations and two of these are on the Bluebird. The reason for this is all my cabviews are based around the instruments so the driver can read them correctly. This usually means most controls are out of frame.

Note 1: I saw that OR could scale the cabview to suit the monitor, I reasoned i it could do this maybe it could scale the gauges and animations as well.

Note 2: I have OR set up NOT to scale the aspect ratio of the cabview (i cannot rememeber exactly what the option is at the moment), I do this so the controls look correct.

If there's any more questions please feel free to ask.

To the Elvas Towers GURU's, this is now the second question on Hi res 2D cabs, would it be possible to gather both together and make i "sticky" some where so anyone else could see the particular question was asked. The manual delibrately contains little practical info to keep it from getting into "epic" proportions.

Lindsay

[Lindsayts]

Note: The Position statement now excepts floating numbers, so one can have a position statement like the following

Position ( 155.3 348.8 x y )

I requested this feature as I found that addressing hi-res background was not fine enough, this is particlarly noticeable in rotary gauges.

Lindsay