[cjakeman]

Just to announce that I've started work in implementing the ideas proposed some time ago by Genma Saotome.

These will provide cameras which are no longer hard-coded but configurable, with up to 10 cameras in a camera set, and multiple camera sets which can be route specific.

It may lead to new camera types (e.g. a camera fixed to a vantage point) and possibly camera sets geared to roles such as driver, fireman, guard, brakeman etc..

For the blueprint and some of the past discussions, see:

"Camera Sets"
"Roles"
"ORTS Wish List - 2013-11 #4" and following
Launchpad Blueprint

This work is targetted towards the next release v1.3 and I'll post here with updates.

If it works, this will be my first major contribution for a while, so please be patient.

[Genma Saotome]

Chris, while tring to wake up the other morning a thought came to mind: Right now when a camera augers itself underground the software bounces over to camera 1. With camera sets that behavior doesn't have to continue. Adding another parameter to the static camera definitions, or to the camera set definition (either has its good and bad points) would allow a configuration to specify which camera to bounce to when the aforementioned condition occurs.

For example, a front tracking camera set, with bounces specified at the camera level, right-side low might bounce to right-side high, right side high might bounce to left side high, and so on.

This would keep the player's active camera above ground and in a relatively similar position as it was before and so I do think it would be a worthwhile improvement.

This idea is not present in the data model I sent you.
==============

On a different note, it also occurred to me that when the time comes to define cameras and the sets they are used by it might be worthwhile to have multiple front end tracking sets -- one general-purpose sets that positions the cameras around the front end at various heights and positions but then a couple of others that would be intended for the kind of locomotive they're tracking.

For example, a camera set for a steam locomotive could include some cameras down low that are positioned to give the rods and wheels in motion center stage. A set for a street car (or similar self powered passenger unit) might position a few cameras very close to the windows, as-if a passenger view had been defined and said passenger was looking out his window.

I think it quite likely that some people would enable use of both a generic front tracking and a locomotive oriented front tracking set so as to get the maximum value out of the camera set feature.

[Mike B]

It was annoying, but with MSTS the camera would sometimes detect that it was going to go underground and instead deflect the camera. For instance, panning around a train in hilly ground and hitting the cut slope above the track would deflect it upward. The omg I'm underground thing didn't happen. How did MSTS do that? I don't consider it critical, but it might be interesting to try to figure that out and add it to OR.

[cjakeman]

Genma Saotome, on 24 March 2017 - 11:46 AM, said:

it also occurred to me that when the time comes to define cameras and the sets they are used by it might be worthwhile to have multiple front end tracking sets -- one general-purpose sets that positions the cameras around the front end at various heights and positions but then a couple of others that would be intended for the kind of locomotive they're tracking.

So, not just route-specific cameras but also loco-specific cameras? Neat idea.

I wonder if we could find and automatically load a camera-set for a loco (where one had been created).

[Genma Saotome]

cjakeman, on 25 March 2017 - 11:11 AM, said:

So, not just route-specific cameras but also loco-specific cameras? Neat idea.

I wonder if we could find and automatically load a camera-set for a loco (where one had been created).

I had not considered that but now that you have, wow, that's pretty interesting!

[Eldorado.Railroad]

cjakeman, on 25 March 2017 - 11:11 AM, said:

So, not just route-specific cameras but also loco-specific cameras? Neat idea.

....and that would be useful for 3D Cabs as well such tha a user can bounce from side to side as needed..etc. This would be similar to what TS20x does, however without all the hidden/encrypted rubbish, just a plain text file would be great!

While it might be a headache to define..the ability to have "n" cameras for any given master camera mode...that is cameras #2, #3, etc would be great. I still feel after all these years camera #6 should be able to move around and not just pivot at a pre-defined point.

Steve

[Genma Saotome]

Steve, the spec I wrote allows for an unlimited number of individual cameras to be defined, each one pretty much along the lines of what MSTS allowed but with several additional features.

Then the cameras are grouped into sets, 1-10 cameras per set. I expect one of these sets will replicate the standard MSTS definitions.

Ideally you then assign any of those sets to a route, tho it may turn out differently, a list of sets available to all routes.


What I hope the end result allows is for most end users to use pre-defined sets made up of pre-defined camera specifications and be completely happy with those, while the more adventurous can create other sets from that list of camera, or even define new cameras if they wish.

I included in the specification that both a camera definition and a camera set definition have some sort of information that identifies who created it -- call it Owner if you will. That way if I share a custom set for front tracking with you it could be marked as Type: "Front Tracking" and Owner: "D. Nelson". This way it won't over-write a front tracking set you created for yourself.

My hunch is there will be a flurry of new sets distributed and then taper off as most of the neat ideas will have been implemented.

[Jovet]

I'd like a camera that can lock onto and travel along TDB/RDB lines (ideally at a variable height, adjusted with Up/Down).

[cjakeman]

Jovet, on 28 March 2017 - 05:56 AM, said:

I'd like a camera that can lock onto and travel along TDB/RDB lines (ideally at a variable height, adjusted with Up/Down).

Nice idea. How would you control speed and direction of travel?

[conductorchris]

The camera view I've always found not quite to my liking is to represent the conductor on the ground. Before departure one should pump up the air and then walk the train to do a brake test. But the cameras don't quite allow for that. Or walk around throwing switches.

I'm probably showing how my railroading experience is all short-line and branchline with nobody at terminals to do brake tests but me, the conductor and no power switches to be seen.

Christopher