[B & O GUY]

Does the bounding box and inertial tensor for rolling stock and locomotives in Open Rails work the same as it does in MSTS. I've noticed in camera view 2 that the bouncing off that used to occur in MSTS is not happening in OR.

Is the setup for bounding boxes and inertial tensor boxes the same as with MSTS as for coupling and coupled length. The reason I'm asking is that I don't see the sensitivities in the initial setup of new models as before with MSTS.

Allen

[James Ross]

B & O GUY, on 01 June 2011 - 03:43 AM, said:

I've noticed in camera view 2 that the bouncing off that used to occur in MSTS is not happening in OR.

I can't answer the more physics parts, but I know that the camera doesn't bounce off because we've not made it bounce off. That's just the current state of the cameras and we may start bouncing them off at some point or we may not. (I'm not entirely convinced it is a good feature.)

[johnfrum]

My vote is for the cameras NOT to bounce off the rolling stock -- or at the very least to allow for being able to switch that ability on and off.

I like being able to easily achieve a brakeman's viewpoint from atop a boxcar, for instance.

I've never understood the point of that camera bounce and I was very happy to see that Open Rails did away with it.

-JF-

[longiron]

B & O GUY, on 01 June 2011 - 03:43 AM, said:

Is the setup for bounding boxes and inertial tensor boxes the same as with MSTS as for coupling and coupled length. The reason I'm asking is that I don't see the sensitivities in the initial setup of new models as before with MSTS.
Allen

Allen,
Looking at the code, Open Rails only reads the SIZE dimensions of the Shape file. OR does not read the bounding box or inertial tensor values at the present time. Values are read from the coupler section to determine the length of the coupler. We will need the bounding box information when solid body collision physics is added to Open Rails.

[Genma Saotome]

longiron, on 01 June 2011 - 11:00 AM, said:

We will need the bounding box information when sold body collision physics is added to Open Rails.

I do hope that can be a user assignable control, ideally defaulted by object class (i.e., in the .sd file). Trees 'n stuff could be set to no-bounce while other stuff would be set to bounce. Basically, let the route designer, not the software, make the call as to what to do with each collision.

[thegrindre]

Genma Saotome, on 01 June 2011 - 11:37 AM, said:

I do hope that can be a user assignable control, ideally defaulted by object class (i.e., in the .sd file). Trees 'n stuff could be set to no-bounce while other stuff would be set to bounce. Basically, let the route designer, not the software, make the call as to what to do with each collision.

I'm supporting Dave on this issue. :sign_thanks:

:oldstry:

[B & O GUY]

Chuckle, chuckle. When I started this, this AM, I wasn't even thinking about collision physics. I had been playing around with the bounding box and inertial tensor box to achieve proper coupler and spacing for the 3 truck Shay and was able to adjust them easily in OR but without all the hassles of the normal scenario of coupler problems. I just wondered if things had been changed for the good.

So how is the coupler physics changed. I've never adjusted these before.

Allen

[longiron]

thegrindre, on 01 June 2011 - 12:29 PM, said:

I'm supporting Dave on this issue.

Can you explain why you need to have this set an the individual item level? Plus you are asking for the software to do an enormous amount of work to determine what the camera should do regarding each individual object for, IMHO, not a lot in return.

[James Ross]

longiron, on 01 June 2011 - 01:00 PM, said:

Can you explain why you need to have this set an the individual item level?

Setting it per-class of item, in the .sd file as mentioned, seems like the best place to set it - if we do allow it. Setting it per-instance would be pretty silly. E.g. I make a shape, decide how it should react to being hit by a train, set that in to the .sd file and every time anyone uses that shape it'll react the same.

[Genma Saotome]

longiron, on 01 June 2011 - 01:00 PM, said:

Can you explain why you need to have this set an the individual item level? Plus you are asking for the software to do an enormous amount of work to determine what the camera should do regarding each individual object for, IMHO, not a lot in return.

First, the bounding box is determined by the maximum range of polys in all three dimensions. That's not much of a problem when the model is s a small cube, such as a boxcar. It becomes increasingly problematic as the model grows in size and complexity -- consider a long, low building, with an annex running off at 90d and somewhere on the grounds is a tall smokestack. That bounding box is huge and the vast majority of it is open air.

Second, not all objects deserve to be bounced away from. There's nothing wrong w/ the camera passing thru a line of telephone wires or some trees.

Third, assuming a one-bounce-for-all is exactly the performance killing amount of work because in that mode everything would require a bounce and the bounce itself takes work. Being able to assign no-bounce to anything at all would probably reduce the amount of work in-game.

Fourth, the suggestion was made about object classes, not object instances. No change to world file content is needed.

Fifth, it seems to me it's better to let the designer and/or end user figure out what should get a bounce and what can be passed thru w/o consequence that it is to impose a one-rule-for -all solution.
================
Returning to the Inertial Tensor issue... as I recall, reducing the value by 0.2 or 0.3m was to deal with the fact the bounding box is determined by the maximum range of the model but that portion of a car that does not change it's length is the distance between the coupler springs, which will be less. Perhaps that accounts for why some MSTS models will creep into motion one by one as the train starts to move.