Bounding boxes and Inertial Tensor boxes for models Are there differences between OR and MSTS
#1
Posted 01 June 2011 - 03:43 AM
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
#2
Posted 01 June 2011 - 09:54 AM
B & O GUY, on 01 June 2011 - 03:43 AM, said:
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.)
#3
Posted 01 June 2011 - 10:28 AM
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-
#4
Posted 01 June 2011 - 11:00 AM
B & O GUY, on 01 June 2011 - 03:43 AM, said:
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.
#5
Posted 01 June 2011 - 11:37 AM
longiron, on 01 June 2011 - 11:00 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.
#6
Posted 01 June 2011 - 12:29 PM
Genma Saotome, on 01 June 2011 - 11:37 AM, said:
I'm supporting Dave on this issue. :sign_thanks:
:oldstry:
#7
Posted 01 June 2011 - 12:54 PM
So how is the coupler physics changed. I've never adjusted these before.
Allen
#8
Posted 01 June 2011 - 01:00 PM
thegrindre, on 01 June 2011 - 12:29 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.
#9
Posted 01 June 2011 - 01:13 PM
longiron, on 01 June 2011 - 01:00 PM, said:
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.
#10
Posted 01 June 2011 - 01:45 PM
longiron, on 01 June 2011 - 01:00 PM, said:
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.
#11
Posted 01 June 2011 - 02:32 PM
longiron, on 01 June 2011 - 01:00 PM, said:
Yeah, what Dave just said again. :pleasantry:
:oldstry:
#12
Posted 01 June 2011 - 02:53 PM
Genma Saotome, on 01 June 2011 - 01:45 PM, said:
Second, not all objects deserve to be bounced away from ...
Third, assuming a one-bounce-for-all is ....
Fourth, the suggestion was made about object classes ...
Fifth, it seems to me it's better to let the designer ...
Dave, you've done a great job on the "what", but haven't addressed the "why". My view on the "why" is that it's not a important feature to include, in any form, for the following reasons:
First, this issue really applies mainly to the #2 camera, and maybe the #6 camera. Does not having those cameras NOT respect solid object definitions detract from the game experience? My judgement is no. There isn't an issue with seeing into, through solid objects for a train sim, unlike a first person shooter game. There may even be advantages when spotting a cut of cars inside a large building to zoom inside to see the actual position of the cars. Nor do I believe this is a big issue as many users position the #2 camera above likely solid obstructions (bridges, etc) of their view of the train when just running.
Second, by allowing the camera to go wherever the player want it to be, Open Rails is providing a consistent experience and NOT imposing anyone else's idea (devs, route designer or modeller) of what should or should not viewed from the camera. Having the camera respect some kinds of objects and not others will only create questions and confusion as to what, how, the feature works or doesn't work.
Third, the community has not clamored for this feature. I interpret that as being satisfied with the behavior of the the cameras as they presently are and consistent with MSTS #2 camera behavior.
Just my 2 cents.
#13
Posted 01 June 2011 - 04:26 PM
WRT a camera-object bouncing bouncing feature, I agree it's not a good idea. My previous comments about not making it universal were made thinking it was not a good idea... and if the feature isn't ever added to OR, well, that is fine by me.
#14
Posted 02 June 2011 - 03:52 AM
Quote
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.
Chris
I believe the size of the shape file is the bounding box in the shape file. All items of the model object including couplers, mirrors, awnings and such are contained within the bounding box. And it's the adjustment of that box that allows the coupler's to join visually. But i'm not sure of the effects or reasons of the inertial tensor box other than it affects coupler function or no coupler function in some cases if improperly adjusted.
Allen
#15
Posted 02 June 2011 - 07:35 AM
I wanted to add that whatever method your using for coupling objects seems to work pretty well and has few problem's. So I hope you don't change that part of the programming.
As for the #2 camera view. I like the not bouncing off the train objects. It's kind of fun standing behind the Herb Kelsey and Tom Werb characatures in "Tom's Crew's" while looking out the engineers or firemans cab front windows. Or sitting in any seat you want in the passenger cars or caboose. It's a fun view that wasn't available in the old sim.
Allen