If we have an external camera view, is it possible that we could have a selection coded into rotues?

For example, the route developer could specify a series of camera view points, and the user could switch into external view, and then toggle through them.

My suggestion comes after having a play with the default route and having difficulty getting the camera into a suitible position before the train approached - if we had pre-defined views then you could cycle to the next one and watch the train. Of course, there could still be an option for free movement and adjustment of the position.

A possible syntax might be,

1000,.cameraview x;y;r,

Where x and y are the coordinates of the view and r is the rotation.

Just like happens in Zusi.

I like this one, Tom.

There is a disadvantage to a free-roving camera: BVE routes are designed to be viewed only from the cab and often don't make visual sense from outside a limited range of perspective. I actually think this is a *good* thing as it lightens the load both on the developer and the computer and I don't think it would necessarily be a good thing to have to design entire routes for full 360degree viewing from a mobile camera.

However, author-designated viewing points would allow parts of the route to be fully detailed and the rest to be constructed more simply, as now. There's no reason why the camera shouldn't still be movable by the use, just that it would be understood that the route wouldn't necessarily look its best from all points.

That was my idea. The 360 degree view is admirable, but it will be quite some time until routes are coded to take advantage of it. Also, the route authors could code camera points so as to 'show off' the best views of the route.

I had basically the same idea from the beginning. If we had camera view points in the route, the user could toggle to a fly-by camera view that takes the closest scripted view point. But toggling through them is a good idea then, too.

I have yet to investigate if BVE ignores commands it doesn't know, because then, it would be a backward-compatible extension. This is at the moment preferrable, because it will take time for this project to arrive at feature-completeness, but route coders can still start incorporating new features if BVE just ignores them.

The syntax is easy to add. The angle is a good idea if the fly-by mode is not used, but a fixed direction instead. The user would be able to toggle between fly-by and fixed and to move from camera point to camera point.

I will highly consider the sytax. If no other approaches arise, I will add it the syntax to the compatibility list of CSV (RW) routes.

Perhaps, SHIFT + PG UP or SHIFT + PG DN could move the camera forwards / backwards along the camera points? They could then adjust it from the defined point if they wished, and pressing SHIFT + PG UP / DN would move to the next/last defined point.

I think BVE throws up an error... would it be possible perhaps to see if openBVE could parse comments? So, we could add

;.cameraview x;y;r,

BVE would ignore this - openBVE would read it, realise it is an actual command, and parse it.

Then if we wanted to comment it out, we could use ;;? Or ;# or some other character.

I tested it with BVE 2 and BVE 4. Both throw an error when they encounter new commands, but you can easily ignore them and everything still works fine.

I wouldn't approve of using comments to introduce new commands. It would make the already quirky CSV format even more cumbersome to use. Instead, I think adding new commands the usual way is better, and I also think it is acceptable when BVE complains about it, because the user can ignore the error.

You can always run a route through a suitable preprocessor to strip out non BVE commands. In fact I think there are good arguments for making the simulator itself a back end that is *always* run via a preprocessing front end. I'll start a wishlist thread about this sometime.

Simon_G wrote:You can always run a route through a suitable preprocessor to strip out non BVE commands.

Yes, I can, but BVE can not. BVE will throw the error message. If you mean that the route developer should be able to have a tool that strips out non-BVE commands, so that the developer can provide two routes to users, one openBVE, one BVE, then this is a possibility.

For the release of version 0.8 (around 2008-07-31), this command is scheduled to be implemented. If there are any things to consider, please discuss them now.

However, I suggest changing the syntax to the following:

Route.ViewPoint X; Y; Yaw; Pitch; Roll

X is the horizontal distance relative to the player's track. Positive means translate to the right.
Y is the vertical distance relative to the player's track. Positive means translate to above.
Yaw is the rotation in the XZ-plane (along the Y-axis). Positive means rotate to the right.
Pitch is the up/down rotation. Positive means rotate up.
Roll is the rotation along the directional axis the camera is facing (tilting your head). Positive means rotate clockwise.

In the tradition of BVE, all distances are measured in meters (by default) and all angles are measured in degrees.

This extension has been implemented as of 2008-08-30.

I have made some slight changes, though. First of all, I did not like the initial suggestion of CameraView, as in my terminology, this refers to the cab view, the train-bound exterior view, fly-by view, etc., as different kinds of camera views. A name most commonly encountered, at least in the world of navigational software, is point of interest. Thus, the command is now called PointOfInterest.

Second, I have added an additional argument to specify the rail index. This way, points of interest can be easily defined relative to other rails but the player's rail, as it is possible with most other commands, too. Thus, the syntax is now:

Track.PointOfInterest RailIndex, X, Y, Yaw, Pitch, Roll

THe command will be available with version 0.8, along with keyboard commands to jump between all the points of interest defined in the route file.

Will it be possible to slightly improve Track.PointOfInterest command, add the unique name for "POI" and display the name of the current POI in the upper left corner. For example:
Track.PointOfInterest RailIndex, X, Y, Yaw, Pitch, Roll, POI_Name

Yes, this is a good idea. I will add it for the next release beyond 0.9.0.5. Obviously, if the text is left empty, no message will be displayed. So, the new syntax is as follows, just to summarize the official status:

Track.PointOfInterest RailIndex, X, Y, Yaw, Pitch, Roll, Text

Remember though that Text cannot directly contain characters which are important to parsing. These include AT, COMMA, SEMICOLON, OPENING PARANTHESIS and CLOSING PARANTHESIS. You will need to escape such characters via a $Chr directive if you need them.