Camera rotation angle and moving suppression for Panel.animated

[ginga81]

I think that this proposal is important, Please try to consider about this. When we are attempt to create 3d cab, if we do not create full 3d cab, when we are moving or rotate the camera, we are thrown into the air. And now, most of Train data is mainly to 2D panel. But , if we create only of front area of 3d driving panel, and suppression to rotate, we more create the 3D panel easily. If the moving is suppression, we can move only the cab. I proposal that rotation angle and moving suppression for Panel.animated.

[Rotate] RotateXaxisofDegree=startdegree,enddegree RotateYaxisofDegree=startdegree,enddegree RotateZaxisofDegree=startdegree,enddegree

to rotate the camera suppression to half hemisphere RotateXaxisofDegree=-90,90 RotateYaxisofDegree=-90,90 RotateZaxisofDegree=-90,90

moving is Train.dat's #CAB position base: [Moving] MovingXarea=minimum_position_of X_from_cabX, maximum_position_of X_from_cabX MovingYarea=minimum_position_of Y_from_cabY, maximum_position_of Y_from_cabY MovingZarea=minimum_position_of Z_from_cabZ, maximum_position_of Y_from_cabZ

Train.dat https://openbve-project.net/documentation_hugo/en/trains/train_dat.html#cab

CAB

-900 2750 -1000 [Moving] MovingXarea=-1000,2500 MovingYarea=-900,1000 MovingZarea=-2000,800 Xarea = -900-1000=-1900,-900+2500=1600 Yarea = 2750-900=1850, 2750+1000=3750 Zarea = -1000-1000=-2000, -1000+800=200

[ManuelMejias]

It will be a great idea, but you're missing another factor.

It's also necessary the FOV value on some CabViews.

[ginga81]

This idea is 'animated Panel2.cfg'. And it is cab area box such as cube shape.

Most of Japanese Train data is only for Front Of View. In this case, for example to animate the wiper, rotation degree is not change, so the train panel is for vertical only. If the new command, such as 'rotateneedles', it is difficult to programming. But, Panel.animated is already has all.

For example, Shinkansen is very sharp, the window is very slant. If wiper is only for vertical, it is very incompativility. If the main panel is panel.animated and not rotate, wiper is very slant and animated. It is easy to fit. As the same, Needles are easy to slant. The photo base Panel2.cfg, needles cannot slant. So, some of case, needles are overflow from gauge's photo.

If the currently panel.animated, put the photo only, 3Dcab can rotate. But if rotate, because of nothing create another driver cab parts such as floor, we are flying.

And if driver's moving area are moving suppression, the creator can only to create the driver's cab area. I think that this idea is easy to create 3Dcab. So I suggestion.

[leezer3]

I did a little playing with this yesterday.

It's definitely something implementable, but not quite as easy as it first looked....

The existing camera restriction code operates solely in 2D screen space, as opposed to world space. In order to actually make this work, we'll need something a little like the following:

• Define two points relative to the cab (e.g. our box)
• Update the world-position of these two points once a frame- Probably want to hook this into the same code loop that updates the verticies for the cab / exterior objects.

It might also be possible to add a rather hacky way of doing things, by just storing the total X / Y / Z movement of the camera when in cabview & comparing this to set maximums, but the worldspace test is a much better idea really.

[leezer3]

This is a first implementation for camera restrictions in 3D cabs: https://github.com/leezer3/OpenBVE/tree/CameraRestriction

Only implemented for XML trains at present:

<CameraRestriction>
    <Forwards>3</Forwards>
    <Backwards>-3</Backwards>
    <Left>-3</Left>
    <Right>3</Right>
    <Up>3</Up>
    <Down>-3</Down>
</CameraRestriction>

We could probably also add to the train.dat , but whether this is a good idea not sure.... Each number is in meters, and is relative to the center of the cab object. (As a secondary thing, it'd be rather useful if the XML formats understood units, so that for example we could declare these values to be in meters, centimeters etc.)

It's not quite working perfectly, as the camera sticks when it hits the edge of the restriction, as opposed to allowing it to be moved back again. I can't see an immediate reason for this, need to play around a little....

Also probably wants a little optimization.

[ginga81]

I attempt to try to test this version. Is this need the complete Train.XML? At the tail of the Train.XML, add to this new section?

[leezer3]

Add it to a car node of train.xml (As multiple interior views are supported, it made sense to have multiple restrictions) See this complete example:

<?xml version="1.0" encoding="utf-8"?>
<openBVE xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <Car>
        <Length>20.8</Length>
        <Width>2.6</Width>
        <Height>3.6</Height>
        <MotorCar>True</MotorCar>
        <Mass>80000</Mass>
        <ReadhesionDevice>TypeA</ReadhesionDevice>
        <FrontAxle>6.5</FrontAxle>
        <RearAxle>-6.5</RearAxle>
        <Object>External\D1015.animated</Object>
        <Reversed>False</Reversed>
        <LoadingSway>False</LoadingSway>
        <FrontBogie>
            <FrontAxle>1.85</FrontAxle>
            <RearAxle>-1.85</RearAxle>
            <Object>External\bogie_f.animated</Object>
            <Reversed>True</Reversed>
        </FrontBogie>
        <RearBogie>
            <FrontAxle>1.85</FrontAxle>
            <RearAxle>-1.85</RearAxle>
            <Object>External\bogie_f.animated</Object>
            <Reversed>False</Reversed>
        </RearBogie>
        <InteriorView>panel.animated</InteriorView>
        <CameraRestriction>
            <Forwards>3</Forwards>
            <Backwards>-3</Backwards>
            <Left>-3</Left>
            <Right>3</Right>
            <Up>3</Up>
            <Down>-3</Down>
        </CameraRestriction>
        <DriverPosition>-0.7,2.7,-2</DriverPosition>
        <Brake>
            <Compressor>
                <Rate>5000.0</Rate>
            </Compressor>
            <MainReservoir>
                <MinimumPressure>690000</MinimumPressure>
                <MaximumPressure>780000</MaximumPressure>
            </MainReservoir>
            <AuxiliaryReservoir>
                <ChargeRate>200000.0</ChargeRate>
            </AuxiliaryReservoir>
            <EqualizingReservoir>
                <ServiceRate>50000.0</ServiceRate>
                <EmergencyRate>250000.0</EmergencyRate>
                <ChargeRate>200000.0</ChargeRate>
            </EqualizingReservoir>
            <BrakePipe>
                <NormalPressure>627500</NormalPressure>
                <ServiceRate>1500000.0</ServiceRate>
                <EmergencyRate>5000000.0</EmergencyRate>
                <ChargeRate>10000000.0</ChargeRate>
            </BrakePipe>
            <StraightAirPipe>
                <ServiceRate>300000.0</ServiceRate>
                <EmergencyRate>400000.0</EmergencyRate>
                <ReleaseRate>200000.0</ReleaseRate>
            </StraightAirPipe>
            <BrakeCylinder>
                <ServiceMaximumPressure>440000</ServiceMaximumPressure>
                <EmergencyMaximumPressure>440000</EmergencyMaximumPressure>
                <EmergencyRate>75000</EmergencyRate>
                <ReleaseRate>50000</ReleaseRate>
            </BrakeCylinder>
        </Brake>
    </Car>
</openBVE>

Will try and do some more work on this later in the week, but I'm a little busy at this time of year :)

[leezer3]

n.b. Might rename it InteriorCameraRestriction , as this would be a little more descriptive.

[leezer3]

The linked branch now works correctly for movement restriction in 3D cabs with the above syntax.

Rotation restriction will probably be a little more tricky, let me do a little more playing around over the next few days.

[ginga81]

I tested this version. It is very nice! I am exciting to add the rotation limit.

When I test this, your sample Train.XML was not work. I recieved advice from @s520 . He said that this sample is missing the tag. And he said that the current Train.XML need the Train.dat because of acceralation parameters. Thank you very much for S520.

[leezer3]

I've merged these into master. Haven't had time to try and have a go at rotation restrictions, wrong time of year :(

TrainEditor2 needs updating, but it's a little more complicated than just adding it; The format either supports a single cab per train, or defining individual interiors on a per-car basis with the panel.animated node.

[s520]

I think that it is necessary to decide the specification of train.xml before adding an item to TrainEditor2. Specifically, it is the definition of acceleration and motor sound. I personally want to remove the limit on the number of motor sound sections at this time.

[leezer3]

That's a very fair point.

The main reason I haven't got as far as adding motor sounds / acceleration to the train.xml (or writing a full draft specification) yet is because the current state of play isn't really ready for that.

To explain a little as to my thinking: BVE considers the train as a single 'unit'- The acceleration figures are divided equally between the motor cars in the train. Similarly, motor sounds are controlled on a train-wide basis, rather than a single car.

In essence, I think we need to work out a solution for allowing the acceleration and motor sounds to be fully defined on a per-car basis. I'm not sure either that simply extending the number of available sounds etc. is precisely the best way to go, as it only perpetuates the existing issues. For that to work though, we need to separate the way these are handled! In English, it's what we call the 'chicken and egg' problem- What comes first :) ?

[s520]

I agree.

The current program calculates a new speed for each individual car for each frame, but averages it. https://github.com/leezer3/OpenBVE/blob/3420e85baea5cc3676e1bf57345a7f1f22b034e6/source/OpenBVE/Simulation/TrainManager/Train/Train.cs#L446 It is necessary to change this averaging part to consider the interaction of each car. This is my perception, but is it correct?

[leezer3]

I would strongly suspect you're right, although I haven't really tested this at the minute.

To me at the minute, I think the next immediate step is to separate the Car class into two further distinct classes, each only containing the relevant properties-

• MotorCar
• TrailerCar

This branch is a higlyl unfinished start on that from this morning (going to work, will try and do some more later in the week): https://github.com/leezer3/OpenBVE/tree/MotorTrailer Double abstraction seems to be necessary, as API consumers don't need knowledge of objects etc, but it'd be a silly amount of duplication otherwise.

[s520]

I reviewed the current code again. It seems that the speed of each car has already been calculated considering the collision of the coupler. So I don't think the simulation needs to be changed. However, it is better to separate motor and trailer classes because it makes it easier to understand. I also start working.