Log In
Register Now!
Help
Let's say we need to decide between some kind of fake and something close to the real world. As Bill said in other thread - there are two sorts of ORTS users at least. One sort of them likes the train moving in 3D world and the other sort wanna see the simulator as real as possible. If we do a fake - what will the fake would be like, on what basis? To do it correctly, we need to cover all of possible cases, many cases comming from many railways in the World. And believe me, it is pretty hard to do it, both cases.
Future Rolling Stock Features
Rate Topic:
#21
- Engineer
-
- Group: Status: Contributing Member
- Posts: 571
- Joined: 08-December 10
- Gender:Male
- Location:Slovakia
-
Country:
Posted 26 November 2011 - 03:31 PM
#22 Inactive_Turbo Bill_*
Posted 26 November 2011 - 11:26 PM
Matej, the whole rocking thing and locomotive and car bounce is actually already there in every route. Let me explain. Harmonic roll or car wobbling or whatever is a speed related event. This is more true on jointed rail then welded rail but the two go quite hand in hand. At specified speeds the Harmonic side to side rocking is most noticable in taller cars then flatcars. The degree of rocking is a direct relation to how high the weight is above the railhead. MSTS has that information in every eng. and wag. file and this is in the dimensions portion in the respective wag files and well last time I looked deisel locomotives where not that different in height. Now remember that we have two types of motion we are trying to create here. One the rocking side to side. This is most visible in empty railcars and the speed that creates the most rocking are 12-15mph, 18mph and 23mph. The car bodies are the only visible part we have to worry about as I said springs are too hard to notice unless you are pacing the train and in the case of empties there is absolutely not enough spring movement to even worth the time to consider code much less new graphics so screw that don't need it, never will and if someone b*tches about it, tough, we got much bigger things to work on and waste heartbeats over. Also the degree of wobble is again height related. So the taller the car, the more visable the rock. Top heavy empties rock about 1-2ft off from straight up center. Gondola's being half that height rock about a foot each way of center and flat cars actually don't rock at all, or they may sashay about 6inches each way from center on poorly maintained jointed track. You can trust me on this as I've run thousands of miles on this latter light rail 10 to 25mph junk. Also car rocking also occurs only in two states. Coasting and any slack condition other than stretched under load and litterly never under excelleration. The higher the physical pulling forces on the drawbar the less they wobble. Same with locomotives. They rock a lot and this is due to a rather high center of gravity and the fact that the springs are specifically designed to be at half compressed state as the locomotive weight never changes. Now in reference to loaded cars and diesels rocking this occurs at 12-15mph and 23mph only. The rocking motion is about half the speed on an empty and is very gentle to the point of being graceful in appearance. So there you have it with harmonic roll, it is speed related. That should be easy to code. The total distance of wobble is height related, that info is in every wag file, and loaded versus empty determines speed of rocking. There is one other parameter we could include her and that is length and the shorter the car the faster and more pronounced the rocking, again we have that info. The body is the only animated shape on the model as the wheels and the truck side-frames are stationary and follow the rail which is actually quite smooth. Also the rocking speed and side to side rocking is totally random as there really is no choreographing needed in the animation part of the game engine. Simple, all the info is available without adding parameters to existing MSTS eng and wag files.
Good!
Now we will discuss what happens above 23mph. The side to side rocking basically stops and is too negligable to worry about at speed, so forget about it, not worth the sweat and time to code. Now the locomotive/s and loaded car bodies move vertically and "bounce" or rather "Gallop" as one hogger once described it to me. The higher the speed, the bigger the bounce. The light empties bounce is barely visible, a mere fraction of a locomotive or loaded car and the only way you see it is when you lock back along your train from the cab and on a curve that coincides with the engineer's side. Again here the bounce or gallop is power related with a stretched slack configuration effectively minimizing the gallop in engines and cars based on in-train forces applied by the locomotives. Also when in stretched braking with train air the random galloping diminishes and under heavy dynamic braking in a bunched slack configuration all just like the rocking motion at lower speeds. Identical coding, identical graduating and decreasing values based on how much motion energy is being applied to the train. Exact same for braking strecthed with train air or accelerating and slowing down with dynamic brakes. Cruising at speed with just enough power to maintain that established speed is when this bounce is most proficient. So, again, we have a randomized galloping that occurs in all locomotives and loads with the same degree of escalation of the bounce vertical distance based on speed and I will stress this motion is not height specific, it is weight or mass specific (another value that is in every wag and eng file). It is length specific with shorter locomotives and loaded cars being faster and more jostely in there bouncing with long locomotives and railcars gracefully bouncing up and down, up and down, up and down. Again, as in rocking, the only animated shape object in the model is the car body itself. Remember the sides of the trucks follow the wheels. Ya some will say the wheels move up and down, but again I say screw it, not worth the time and computing efforts. There are a ton of other places that computing power can be utilized for much more important features.
There is one very specific choreographed vertical bounce event that is location specific and as you look back at your train you can actually quite clearly see this aggravated bounce move back along your train at precisely the same speed as the train is going. That is dips in the track structure itself and it can be quite violent. It's not at all uncommon to actually bottom out the locomotive to the point where the snow plow slams down on the railhead as the locomotive hits bottom hard and climbs out of the depression, the higher the speed the more pronounced the bounce. Ok, how are we going to put these depression points into every single route, we're talking thousands of locations where someone will have to place "trigger" points along the mainline!!!!!!!!!!! Well, fear not as every route developer has already placed all these trigger points in every single route out there in precisely the exact correct location to the inch and didn't even know they were doing it!!!!! And judging from the new RW3 they just randomized the whole thing where we will be prototypicaly correct!! This choreographed timed and speed specific bounce that starts at the headend and travels back along occurs in 3 primary location points along every mainline whether on jointed or welded rail. On both sides of every single grade crossing. both ends of every single bridge or trestle and over the mid-point of every single switch regardless of size or type. Who knew???!! The triggers are there already and the only randomizing factor I would worry about is to have varying degrees of harshness from railcrossing to railcrossing, trestle/bridge to trestle/bridge and switch to switch. The only key varying detail is a randomized degree of bounce from location to location is that it must remain constant in severity as the whole train travels across that point and that's it. Crossings and trstle/bridges are usually the same on either side. Now I know the first argument is going to be, "what about out there between switches, bridges and roadcrossings?" If someone wants to code up a trigger and program to randomly insert that trigger and the end-user wants to install these random location triggers into a route go on ahead but these random spots are really not all that common, iif one soft spot is there it's probably already a slow order requiring a reduction in speed which is pretty much always below 25mph and as stated there is very little to no vertical movement below that speed. Again I wouldn't waste any time on it. That's the way it is in the real world. The fact that we have these motions in a sim that had no car movements at all and is now prototypical in nature than the new RW3 is a huge leap in MSTS based technology. Now why are these locations there in the first place? In the case of trestle and bridges only very few have ballast support track structure and if there's a depression in the middle of a trestle big enough to feel or cause a big bounce, I'd stick my head between my legs and kiss my butt good-bye! Road crossing are built with very solid and specific road beds and the best ties and the heaviest rail available and over time a soft spot will gradually occur on each side where the track structure traverse from loose ballast base to the solid base of the crossing itself,same w/bridges and trestles. In the case of switch locations as the train hammers over the center frog of the switch, it hammers it down into the ballast base and over time gradually worsens to the point where the switch needs to be retamped usually by hand or when a track sturcture support traveling MOW crew pass over and retamp that switch as these crews and their machines creep along the mainline in scheduled and choreographed track maintanance operations. Again, no two crossings,bridges or switches are the same and I don't think this insurmountable for our great group of code-writers.
Quote: Hmmmmmmmmm, How many people would really apreciate this sort of accuracy in the mathematical modelling and to REALLY do a good job one would need to model the imperfections in the track and this would be beyond what would be reasonable to expect someone to do, the OR developers or route developers. Also how much impact is all this calculating going to have on a typical system, OR aleardy requirening a good fast system on a route that has both dense scenery and traffic, eg the SOB. The more mathematical modelling is put onto the system the slower it will end up performing. It being little good to have a very accurate simulator only capable of doing slower than 50 FPS. Much as I hate to say it the solution may be to put user controled random movements in the rolling stock to keep those that require it happy. The other place we need to address in employing these animations is when the player is in the cab. This is where the cream is on the cake. We get that cab animated to match the outside animations along the train and we've got this thing nailed.
A point for all to keep in mind is the more difficult it will be to produce a route or rolling stock due to say accuarcy requirements for both the graphics and the "phsyics" the less number of people will be able/capable/willing to do the task. This is already to some extent a serious problem in the "physics" particularly power, traction and braking in MSTS rolling stock a signifcant proportion of the locos released being poor to very poor. End Quote.
As pointed out above, it should not require a lot of code. The information is all there in the wag files and the core sim always knows if the train is under power, slack-stretched braked with train air or slack-bunched w/dynamic brakes employed. Also the speed variable is always known and where applicable, the motions will assert themselves and clearly stated known prototypical speeds. The rest of the need info is already there in the original format MSTS eng and wag files and where need the motion event triggers are already there in the routes themselves and are specific and the interactive items are the same no matter how old the route.
One thing we could do is include this as an option for the end-user to turn off or on?
And the statement that these animations are minimal in importance and too insignificant to bother to implement is pure 'hodgepodge'! There is nothing that gets the engine crew's hearts and juices going than screaming down that mainline with 120 cars, 4 big units in run8 and getting the ride of your life as you go. To me it was like getting paid to go ride an exciting amusement park ride. MSTS has always seem slower than the real thing and that's because it's too sterile perfectly flat in it's present state.
BORING, if you've ever ridden the real deal at speed.
Good!
Now we will discuss what happens above 23mph. The side to side rocking basically stops and is too negligable to worry about at speed, so forget about it, not worth the sweat and time to code. Now the locomotive/s and loaded car bodies move vertically and "bounce" or rather "Gallop" as one hogger once described it to me. The higher the speed, the bigger the bounce. The light empties bounce is barely visible, a mere fraction of a locomotive or loaded car and the only way you see it is when you lock back along your train from the cab and on a curve that coincides with the engineer's side. Again here the bounce or gallop is power related with a stretched slack configuration effectively minimizing the gallop in engines and cars based on in-train forces applied by the locomotives. Also when in stretched braking with train air the random galloping diminishes and under heavy dynamic braking in a bunched slack configuration all just like the rocking motion at lower speeds. Identical coding, identical graduating and decreasing values based on how much motion energy is being applied to the train. Exact same for braking strecthed with train air or accelerating and slowing down with dynamic brakes. Cruising at speed with just enough power to maintain that established speed is when this bounce is most proficient. So, again, we have a randomized galloping that occurs in all locomotives and loads with the same degree of escalation of the bounce vertical distance based on speed and I will stress this motion is not height specific, it is weight or mass specific (another value that is in every wag and eng file). It is length specific with shorter locomotives and loaded cars being faster and more jostely in there bouncing with long locomotives and railcars gracefully bouncing up and down, up and down, up and down. Again, as in rocking, the only animated shape object in the model is the car body itself. Remember the sides of the trucks follow the wheels. Ya some will say the wheels move up and down, but again I say screw it, not worth the time and computing efforts. There are a ton of other places that computing power can be utilized for much more important features.
There is one very specific choreographed vertical bounce event that is location specific and as you look back at your train you can actually quite clearly see this aggravated bounce move back along your train at precisely the same speed as the train is going. That is dips in the track structure itself and it can be quite violent. It's not at all uncommon to actually bottom out the locomotive to the point where the snow plow slams down on the railhead as the locomotive hits bottom hard and climbs out of the depression, the higher the speed the more pronounced the bounce. Ok, how are we going to put these depression points into every single route, we're talking thousands of locations where someone will have to place "trigger" points along the mainline!!!!!!!!!!! Well, fear not as every route developer has already placed all these trigger points in every single route out there in precisely the exact correct location to the inch and didn't even know they were doing it!!!!! And judging from the new RW3 they just randomized the whole thing where we will be prototypicaly correct!! This choreographed timed and speed specific bounce that starts at the headend and travels back along occurs in 3 primary location points along every mainline whether on jointed or welded rail. On both sides of every single grade crossing. both ends of every single bridge or trestle and over the mid-point of every single switch regardless of size or type. Who knew???!! The triggers are there already and the only randomizing factor I would worry about is to have varying degrees of harshness from railcrossing to railcrossing, trestle/bridge to trestle/bridge and switch to switch. The only key varying detail is a randomized degree of bounce from location to location is that it must remain constant in severity as the whole train travels across that point and that's it. Crossings and trstle/bridges are usually the same on either side. Now I know the first argument is going to be, "what about out there between switches, bridges and roadcrossings?" If someone wants to code up a trigger and program to randomly insert that trigger and the end-user wants to install these random location triggers into a route go on ahead but these random spots are really not all that common, iif one soft spot is there it's probably already a slow order requiring a reduction in speed which is pretty much always below 25mph and as stated there is very little to no vertical movement below that speed. Again I wouldn't waste any time on it. That's the way it is in the real world. The fact that we have these motions in a sim that had no car movements at all and is now prototypical in nature than the new RW3 is a huge leap in MSTS based technology. Now why are these locations there in the first place? In the case of trestle and bridges only very few have ballast support track structure and if there's a depression in the middle of a trestle big enough to feel or cause a big bounce, I'd stick my head between my legs and kiss my butt good-bye! Road crossing are built with very solid and specific road beds and the best ties and the heaviest rail available and over time a soft spot will gradually occur on each side where the track structure traverse from loose ballast base to the solid base of the crossing itself,same w/bridges and trestles. In the case of switch locations as the train hammers over the center frog of the switch, it hammers it down into the ballast base and over time gradually worsens to the point where the switch needs to be retamped usually by hand or when a track sturcture support traveling MOW crew pass over and retamp that switch as these crews and their machines creep along the mainline in scheduled and choreographed track maintanance operations. Again, no two crossings,bridges or switches are the same and I don't think this insurmountable for our great group of code-writers.
Quote: Hmmmmmmmmm, How many people would really apreciate this sort of accuracy in the mathematical modelling and to REALLY do a good job one would need to model the imperfections in the track and this would be beyond what would be reasonable to expect someone to do, the OR developers or route developers. Also how much impact is all this calculating going to have on a typical system, OR aleardy requirening a good fast system on a route that has both dense scenery and traffic, eg the SOB. The more mathematical modelling is put onto the system the slower it will end up performing. It being little good to have a very accurate simulator only capable of doing slower than 50 FPS. Much as I hate to say it the solution may be to put user controled random movements in the rolling stock to keep those that require it happy. The other place we need to address in employing these animations is when the player is in the cab. This is where the cream is on the cake. We get that cab animated to match the outside animations along the train and we've got this thing nailed.
A point for all to keep in mind is the more difficult it will be to produce a route or rolling stock due to say accuarcy requirements for both the graphics and the "phsyics" the less number of people will be able/capable/willing to do the task. This is already to some extent a serious problem in the "physics" particularly power, traction and braking in MSTS rolling stock a signifcant proportion of the locos released being poor to very poor. End Quote.
As pointed out above, it should not require a lot of code. The information is all there in the wag files and the core sim always knows if the train is under power, slack-stretched braked with train air or slack-bunched w/dynamic brakes employed. Also the speed variable is always known and where applicable, the motions will assert themselves and clearly stated known prototypical speeds. The rest of the need info is already there in the original format MSTS eng and wag files and where need the motion event triggers are already there in the routes themselves and are specific and the interactive items are the same no matter how old the route.
One thing we could do is include this as an option for the end-user to turn off or on?
And the statement that these animations are minimal in importance and too insignificant to bother to implement is pure 'hodgepodge'! There is nothing that gets the engine crew's hearts and juices going than screaming down that mainline with 120 cars, 4 big units in run8 and getting the ride of your life as you go. To me it was like getting paid to go ride an exciting amusement park ride. MSTS has always seem slower than the real thing and that's because it's too sterile perfectly flat in it's present state.
BORING, if you've ever ridden the real deal at speed.
#23
- Open Rails Developer
-
- Group: Status: Elite Member
- Posts: 3,179
- Joined: 25-July 08
- Gender:Male
- Location:Manasquan, NJ
- Simulator:Open Rails, MSTS editors
-
Country:
Posted 27 November 2011 - 05:49 AM
Bill,
Rather than introduce a bunch of artifical movement into the cars, the core issue is there's no variation in MSTS track from flat, straight and level
When Open Rails has it's own World Editor, our idea is to introduce new paramters into the procedural track system. These parameters enable track that's super elevated and other track that's designed not straight and level. One possible use for this is to be able to lay track that's not straight and level - reproducing old, worn track that's been poorly maintained. Another use would be to allow subtle random variations in the side to side elevation of the rails relative to flat and variation in left / right of the track to straight. Therefore, when the cars follow un even track work, then you will get the side to side rocking motion and movement of cars as the naturally traverse uneven track work. No extra physics to simulate, it's the track that controls the cars, just like in real life, not some simulated movement.
What do you think of that solution?
Rather than introduce a bunch of artifical movement into the cars, the core issue is there's no variation in MSTS track from flat, straight and level
When Open Rails has it's own World Editor, our idea is to introduce new paramters into the procedural track system. These parameters enable track that's super elevated and other track that's designed not straight and level. One possible use for this is to be able to lay track that's not straight and level - reproducing old, worn track that's been poorly maintained. Another use would be to allow subtle random variations in the side to side elevation of the rails relative to flat and variation in left / right of the track to straight. Therefore, when the cars follow un even track work, then you will get the side to side rocking motion and movement of cars as the naturally traverse uneven track work. No extra physics to simulate, it's the track that controls the cars, just like in real life, not some simulated movement.
What do you think of that solution?
#24 Inactive_Turbo Bill_*
Posted 27 November 2011 - 01:30 PM
Track being straight, curved, or being ascending/descending grade have no discernable effect on the animations.
I wrote this post late last night and as I stated in another thread my fingers can no longer keep up with my brain. Perhaps some clarification here, The rocking occurs at all speeds is totally random, I never noticed where these things rocked specifically as I went along the line.....I knew they just did, but especially under 25mph. They still rock above 25mph but usually we're talking the odd sashay and it only rocked at couple to maybe 4 times at most. The rocking at speed is not really from track irregularities but rather the very specific amount of side to side clearance in the rail spacing or gauge (see my other post on the adhesion thread along w/the upload). The speed of the rocking motion is train speed related. When crawling along, the rocking and bounce is always there but it is vvvveeeerrrrryyyyyy slow. At 24mph it is very fast. Don't worry about OR specific track editors and stuff like that in regards to rough track points etc. Yes, they are out there in real life and if OR wants to add that later on down the line, so be it. But it is by no means needed here. In regards to the dips that cause the bounce at the crossings, bridges and switches by and large they not visible to the naked eye when there is no train due to the rail's built in desire to remain in a straight state and the vertical web of the rail keeps it flat and level. The dip only shows up when the weight of the train itself is rolling over it. And I just thought of something each and every car and locomotive will rock once at the midpoint of every switch and the rock will always be to the inside rail's location. Again we have the info in the global folder and the code would be written to recognize whether we are going over a left-hand or right-hand switch. The dips are always there so at these specified locations all the locomotives dip at all speeds. At slow speeds they bounce once at every location at high speeds they will bounce two to three times due to no shock absorbers on the railcars and woefully insufficient and powerful enough ones on the locomotives themselves.
To be truthful there is a dip in the rail that travels along with the train directly under each truck and if you want to be specific a second deeper dip under each individual axle and again the more weight being applied to the rail, the deeper the track structure dips. And it's not just the rail that dips under these loads, it's the ties too. When you pace a moving train these depressions seem to be alive and perfectly follow the wheels/trucks as they travel along the line. If you watch it in one stationary point, all you see is a jack-hammering motion as if the train is trying to hammer the track bed. The big dips at the specific locations I mentioned are more pronounced due to the fact as the train exits the very solid grade crossing and trestles onto the softer regular ballasted area, it litterally "drops offs" the firm solid foundation of the crossing and trestles. The dips in switches are due to the solid rail frogs that are stronger and more rigid and have that gap in them where the main track rail converges with the siding meet midpoint in the switch. Again we don't have to be pinpoint accurate, just code the motion to occur at the midpoint of the each and every switch. In between these locations we can just have random bouncing but again we would need to tie it to the lead engine as when the engine bounces at that location is should follow the train over that specific spot in the line.
So, what physical motions of the carbody do we need to create and how do we tie the code to for the various influences of that motion?
ROCKING code:
-randomly triggered event with the only specific route triggered event being the inside rail mid-point of every switch with the actual rock of the carbody toward the inside of the switch based on left or right hand switches
-deviation of the outward distance of the rocking cycle based on total mass of car. The lighter the car the faster the rocking cycle
-rocking cycle outward distance increases with height of car. The higher the car the further the outward cycle distance increases from centerpoint of the rocking cycle. Bulkhead flatcars are the considered the same as regular flatcars
-occurs at all speeds with single rocking cycles at slow speeds and repeated rockings at high speeds.
-rocking cycle severity gradually increases as train speeds approach the 3 specific speeds (13mph, 18mph and 23mph)
-the center or mid-point of the rocking is always in the center of the car, if you cant to add real detail it gravitates to the side of the car/engine that is on the outside of a curve. The faster the train speed the more this center point gravitates to the outer side of the curve starting at dead center at slow speeds and gravitating to the outside of the curve as sideways G-forces increase with speed.
-the degree of the curve accentuates the degree of shift in the centerpoint of the rocking cycle with the tighter curves having greater affect on how far the centerpoint moves to the outside of the curve than long graceful curves.
-need to code the rocking for the inside cabview looking out the windows. The cab itself stay stationary the world outside moves. If you want to get really specific the engineer's camera moves and the cab rocks around the player as that locomotives rocking is transferred to his body thru the seat but it rock slowly at slow speeds and increases in scope as the speed increases and occurs at a micro-second delay and matches the visible rocking of the outside world as viewed from the stable cab seat.
BOUNCE code:
-bounce needs to be coded to recognize this vertical motion occurs from a stationary point in the track structure and travels back along train starting at the lead locomotive as it passes over stationary spot on track.
- the bounce cycle always is vertical and starts with an upward cycle at the entrance to crossings/trestles/bridges and starts with a downward cycle for normal at rest height of model when exiting off all crossings/threstles/bridges and at the midpoint of every switch and at the start of all randomly triggered bounce occurances
-rather than modify each route with special OR specific editor just code the occurrence to be randomly triggered but never occurs directly on grade crossings and bridges/trestles
-also a location triggered event occurs at the point where the train enters and exits all grade crossings and trestle/bridges and at the midpoint of every switch. the code can be written to recognize all road crossings, bridges/trestles and switches locations in existing routes as placed by the route builders. No special OR specific location placement editor or code needed.
-at slow speeds all triggered bounces whether random or location specific are single vertical motion cycles and only the carbody part of the model is animated. The visible bounce of all cars occur at the exact same spot along the line location when the event is triggered whether randomly triggered or route triggered by location of crossings, trestles/bridges and switch placements by original route builder.
-visually you cannot see the track irregularities due to how the rail is shaped when originally rolled and it's natural, at rest and unoccupied, tendency is to want to stay dead flat when no train is on it. The only visible clue of a specific dip along the line is a brown dirt spot on the side of the rail from submerged water being hydraulically brought to the surface with enough force to splash the muddied water up against the side of the rail and onto the ties from the weight of the train pushing down on the rail and ties as each wheel traverses that point.
- at speeds above 35mph a rythmic bouncing begins to occur and replace the random triggered single bounce and increase in size and vertical distance of the carbody as train speed increases and also time length of each vertical cycle slows as speed increases and only location triggered events temporarily accentuates the actual vertical distance traveled by the vertical motion cycle with an upward accentuated travel of the bounce9bginning or bounce cycle from at rest state) as you enter a grade crossing and treste/bridge and downward as you exit all crossings.trestles/bridges.
-code to randomly trigger the severity of the bounce location in both randomly triggered locations and route triggered locations.severity of bounce event at all severity levels must remain constant as the train passes over the triggered location.
-weight effects the size of bounce cycles with light or empty cars having much shorter vertical bounce cycle distance than loaded cars and heavy locomotives. Code could be written to read the mass weight in the eng and wag file of each specific vehicle in the train.
Please feel free to ask questions
I wrote this post late last night and as I stated in another thread my fingers can no longer keep up with my brain. Perhaps some clarification here, The rocking occurs at all speeds is totally random, I never noticed where these things rocked specifically as I went along the line.....I knew they just did, but especially under 25mph. They still rock above 25mph but usually we're talking the odd sashay and it only rocked at couple to maybe 4 times at most. The rocking at speed is not really from track irregularities but rather the very specific amount of side to side clearance in the rail spacing or gauge (see my other post on the adhesion thread along w/the upload). The speed of the rocking motion is train speed related. When crawling along, the rocking and bounce is always there but it is vvvveeeerrrrryyyyyy slow. At 24mph it is very fast. Don't worry about OR specific track editors and stuff like that in regards to rough track points etc. Yes, they are out there in real life and if OR wants to add that later on down the line, so be it. But it is by no means needed here. In regards to the dips that cause the bounce at the crossings, bridges and switches by and large they not visible to the naked eye when there is no train due to the rail's built in desire to remain in a straight state and the vertical web of the rail keeps it flat and level. The dip only shows up when the weight of the train itself is rolling over it. And I just thought of something each and every car and locomotive will rock once at the midpoint of every switch and the rock will always be to the inside rail's location. Again we have the info in the global folder and the code would be written to recognize whether we are going over a left-hand or right-hand switch. The dips are always there so at these specified locations all the locomotives dip at all speeds. At slow speeds they bounce once at every location at high speeds they will bounce two to three times due to no shock absorbers on the railcars and woefully insufficient and powerful enough ones on the locomotives themselves.
To be truthful there is a dip in the rail that travels along with the train directly under each truck and if you want to be specific a second deeper dip under each individual axle and again the more weight being applied to the rail, the deeper the track structure dips. And it's not just the rail that dips under these loads, it's the ties too. When you pace a moving train these depressions seem to be alive and perfectly follow the wheels/trucks as they travel along the line. If you watch it in one stationary point, all you see is a jack-hammering motion as if the train is trying to hammer the track bed. The big dips at the specific locations I mentioned are more pronounced due to the fact as the train exits the very solid grade crossing and trestles onto the softer regular ballasted area, it litterally "drops offs" the firm solid foundation of the crossing and trestles. The dips in switches are due to the solid rail frogs that are stronger and more rigid and have that gap in them where the main track rail converges with the siding meet midpoint in the switch. Again we don't have to be pinpoint accurate, just code the motion to occur at the midpoint of the each and every switch. In between these locations we can just have random bouncing but again we would need to tie it to the lead engine as when the engine bounces at that location is should follow the train over that specific spot in the line.
So, what physical motions of the carbody do we need to create and how do we tie the code to for the various influences of that motion?
ROCKING code:
-randomly triggered event with the only specific route triggered event being the inside rail mid-point of every switch with the actual rock of the carbody toward the inside of the switch based on left or right hand switches
-deviation of the outward distance of the rocking cycle based on total mass of car. The lighter the car the faster the rocking cycle
-rocking cycle outward distance increases with height of car. The higher the car the further the outward cycle distance increases from centerpoint of the rocking cycle. Bulkhead flatcars are the considered the same as regular flatcars
-occurs at all speeds with single rocking cycles at slow speeds and repeated rockings at high speeds.
-rocking cycle severity gradually increases as train speeds approach the 3 specific speeds (13mph, 18mph and 23mph)
-the center or mid-point of the rocking is always in the center of the car, if you cant to add real detail it gravitates to the side of the car/engine that is on the outside of a curve. The faster the train speed the more this center point gravitates to the outer side of the curve starting at dead center at slow speeds and gravitating to the outside of the curve as sideways G-forces increase with speed.
-the degree of the curve accentuates the degree of shift in the centerpoint of the rocking cycle with the tighter curves having greater affect on how far the centerpoint moves to the outside of the curve than long graceful curves.
-need to code the rocking for the inside cabview looking out the windows. The cab itself stay stationary the world outside moves. If you want to get really specific the engineer's camera moves and the cab rocks around the player as that locomotives rocking is transferred to his body thru the seat but it rock slowly at slow speeds and increases in scope as the speed increases and occurs at a micro-second delay and matches the visible rocking of the outside world as viewed from the stable cab seat.
BOUNCE code:
-bounce needs to be coded to recognize this vertical motion occurs from a stationary point in the track structure and travels back along train starting at the lead locomotive as it passes over stationary spot on track.
- the bounce cycle always is vertical and starts with an upward cycle at the entrance to crossings/trestles/bridges and starts with a downward cycle for normal at rest height of model when exiting off all crossings/threstles/bridges and at the midpoint of every switch and at the start of all randomly triggered bounce occurances
-rather than modify each route with special OR specific editor just code the occurrence to be randomly triggered but never occurs directly on grade crossings and bridges/trestles
-also a location triggered event occurs at the point where the train enters and exits all grade crossings and trestle/bridges and at the midpoint of every switch. the code can be written to recognize all road crossings, bridges/trestles and switches locations in existing routes as placed by the route builders. No special OR specific location placement editor or code needed.
-at slow speeds all triggered bounces whether random or location specific are single vertical motion cycles and only the carbody part of the model is animated. The visible bounce of all cars occur at the exact same spot along the line location when the event is triggered whether randomly triggered or route triggered by location of crossings, trestles/bridges and switch placements by original route builder.
-visually you cannot see the track irregularities due to how the rail is shaped when originally rolled and it's natural, at rest and unoccupied, tendency is to want to stay dead flat when no train is on it. The only visible clue of a specific dip along the line is a brown dirt spot on the side of the rail from submerged water being hydraulically brought to the surface with enough force to splash the muddied water up against the side of the rail and onto the ties from the weight of the train pushing down on the rail and ties as each wheel traverses that point.
- at speeds above 35mph a rythmic bouncing begins to occur and replace the random triggered single bounce and increase in size and vertical distance of the carbody as train speed increases and also time length of each vertical cycle slows as speed increases and only location triggered events temporarily accentuates the actual vertical distance traveled by the vertical motion cycle with an upward accentuated travel of the bounce9bginning or bounce cycle from at rest state) as you enter a grade crossing and treste/bridge and downward as you exit all crossings.trestles/bridges.
-code to randomly trigger the severity of the bounce location in both randomly triggered locations and route triggered locations.severity of bounce event at all severity levels must remain constant as the train passes over the triggered location.
-weight effects the size of bounce cycles with light or empty cars having much shorter vertical bounce cycle distance than loaded cars and heavy locomotives. Code could be written to read the mass weight in the eng and wag file of each specific vehicle in the train.
Please feel free to ask questions
#25
- Owner Emeritus and Admin
-
- Group: ET Admin
- Posts: 15,359
- Joined: 11-January 04
- Gender:Male
- Location:United States
- Simulator:Open Rails
-
Country:
Posted 27 November 2011 - 02:03 PM
Bill, you say taller cars rock further than shorter cars... could that be reworded to "cars rock the same number of degrees off vertical but look as if the rocking is different because the length of the motion arc is longer on tall cars than it is on short cars"?
Question: Does the motion of one car have any effect on the two cars it is coupled to?
As the train speed approaches one of the speeds you mentioned you said rocking speeds increase... what about the length of the rocking arc -- does that also change w/ speed?
WRT curves: are you saying the car rocks further when rocking towards the outside rail, faster, both? And in return movement towards the inside rail, shorter, slower, or both?
Question: Does the motion of one car have any effect on the two cars it is coupled to?
As the train speed approaches one of the speeds you mentioned you said rocking speeds increase... what about the length of the rocking arc -- does that also change w/ speed?
WRT curves: are you saying the car rocks further when rocking towards the outside rail, faster, both? And in return movement towards the inside rail, shorter, slower, or both?
#26 Inactive_Turbo Bill_*
Posted 27 November 2011 - 05:54 PM
Quote
Bill, you say taller cars rock further than shorter cars... could that be reworded to "cars rock the same number of degrees off vertical but look as if the rocking is different because the length of the motion arc is longer on tall cars than it is on short cars"?
Yes!!! I just couldn't figure out how to say that in Layman's terms and this includes ALL instances in regards to rocking. Thank you!!!
Quote
Question: Does the motion of one car have any effect on the two cars it is coupled to?
No, there is enough play in the coupler system to prevent this....unless the car is tipping over on it's side!!!
Quote
As the train speed approaches one of the speeds you mentioned you said rocking speeds increase... what about the length of the rocking arc -- does that also change w/ speed?
Actually I was speaking in reference to increases in ark. Sorry if I didn't word that right. The actual speed of the rocking cycles is speed dependent with the arcs staying the same at all speeds and only increasing in arc distance as the speeds I mentioned are approached by the train.
Quote
WRT curves: are you saying the car rocks further when rocking towards the outside rail, faster, both? And in return movement towards the inside rail, shorter, slower, or both?
In this instance we are only referring to center point of the arc- at the top of the car- cycles itself. On straight track regardless of elevation change the centerpoint of the arc is in the middle. On curves the centerpoint gravitates or moves toward the outside of the curve (centrifugal force is what we're talking about here). The degree that the centerpoint itself moves is based on both speed and the radius of the curve itself. Now remember I said that we can code random rocking above 25 mph, we should also code this random rocking to reflect speed and degree of the curve on other than straight track. The tighter the curve, the more the random random rocking occurs. Likewise the faster the train speed, the more often this random rocking occurs. Just remember at speeds above 25mph the steady rocking at lower speeds transitions to this random rocking events. Also the max number of times the rocking arc cycles at these higher speeds can be random in the amount of arc cycles of between 1 -4 cycles. This is more than enough in regards to coding and modelling of these animations. What is happening here at these speeds is a phenomenon known in the industry as truck "hunting". Remember where I mentioned about track gauge, railhead curvature and wheelface taper either here or in another thread. Well, in a perfect world with exacting track curvature and perfect brand new wheels with brand newly lathed perfect wheelfaces and brand new unused heavy rail weight rails, there would be no rocking at all at speed on straight track or curved track. The wheels would keep themselves perfectly tracked and no truck hunting would occur and wheel flanges would last forever. We don't live in a perfect world and probably the closest you would get to perfect track is on the 200+ mph rail lines in the world. Trust me, North America has very few lines, if any, that fall into this category.
#27
- Chairman, Board of Directors
-
- Group: ET Admin
- Posts: 13,927
- Joined: 21-February 06
- Gender:Male
- Location:Way, way, way, South
- Simulator:MSTS & OR
-
Country:
Posted 28 November 2011 - 01:07 AM
...and speaking of wagons rockin' and rollin' here's the classic utoob clip, tornado vs train, score tornado 1: train zero. I love the way the oil tank car approaches at speed, sparking well.....it's also in HD, just select 720p.
Cheers Bazza
Cheers Bazza
#28 Inactive_Turbo Bill_*
Posted 28 November 2011 - 10:10 AM
With regards to the effect of wind on a train, it really takes a tornado to cause a car or series of cars to flip. When your driving down the highway behind an empty semi-truck on a windy day that trailer really sways. When that truck is loaded the wind seems to have very little effect.
Here's some comparisons:
-empty railroad freight car averages between 30 and 40 tons
-loaded semi-truck is about 40 tons max
-loaded typical rail car is about 125-150 tons and if I read correctly the FRA was thinking of upping max allowed rail car weight to 180 tons
Conclusion:
Under normal wind conditions, you don't even feel it affect your train due to the inertia or kinetic energy of the heavy loads
When does wind affect your train?
The only time I noticed wind affecting my train and it was so noticeable that I thought something was wrong with my power. I was taking a long transfer train from Eugene, Or to Albany, Or on straight tangent track descending water grade condition. I had a headwind of about 25mph w/gusts up to 40mph. The train I was running had 3 SD70m's that were brand new at the time and about 115 railcars with about 25 loaded woodchip cars and 15-20 loaded steel gons of scrap metal with the rest of the train comprised of empty bulkhead and centerbeam flatcars. Under normal quiet wind conditions I'm cruising @ 50mph in run 1-2. On that day I was in full run 8 and could only muster 35mph going downhill!!! I was confused to say the least and started looking for something that would affect my train to that degree. Air pressure on the rear? 85psi, nope no brakes are set and good brake pipe continuity. Big block of handbrakes? Nope, no visible smoke from any trucks in the train. And then it hit me all those bulkhead walls were huge sails grabbing that wind so basically I was dragging the equivalent of well over 50 huge open parachutes? So that explains the 45mph speed restriction on open-top empty gondolas and bulkhead and center-beam empty flats.
In my personal MSTS fleet of cars I always double the frontal area of empty gons and bulkhead/centerbeam flats using F2calc to make sure any air induced drag on my train containing these cars is as close to prototypical. Something for our physics team to consider. A year ago I posted this observation and what I do to add it to my trains physics. When updating your fleet to RW based physics w/RouteRiter, all wag files are automatically changed to reflect this in their friction regions. My question is, "are we going to have OR automatically insert the correct values in MSTS equipment or is it going to model the physics based on values present in the MSTS wag file? The reason being not all end-users are going to have my physics in their respective fleets.
Based on how responsive or rather how my train responds to automatic train brake reductions in loaded and empty trains of 50 cars. When correct RW figures are inserted in the appropriate brake regions in wag files, the sim is way off on it's calculations of these RW based entries and sets the friction retarding force way too high. I looked all over my external hard-drive for my copy of J-L Chauvin's brake region documents including the RW computed maxbrakeforce values for various weights of railcars but could not find it. I'm sure someone on the team has it. Based on actual in sim performance with adjusted maxbrakeforce values to get the braking charecteristics to "actually" mimic how trains really should act to different brake pipe reductions and stopping distances and retarding performance on steep descending grades, my maxbrakeforce values for a loaded and empty covered hopper are:
Loaded 127 Ton ALNS cylinder grain hopper:
Comment ( 130t railcar Max Pro Composition Brake Shoe values by Bill Prieger. Additional
braking parameters contributed by Jean-Louis Chauvin. )
BrakeEquipmentType( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )
BrakeSystemType( "Air_single_pipe" )
MaxBrakeForce( 26.4kN )
MaxHandbrakeForce( 28.8kN )
NumberOfHandbrakeLeverSteps( 100 )
EmergencyBrakeResMaxPressure( 90 )
TripleValveRatio( 2.5 )
MaxReleaseRate( 1.86 )
MaxApplicationRate( 0.9 )
MaxAuxilaryChargingRate( 1.684 )
EmergencyResCapacity( 2.604 )
EmergencyResChargingRate( 1.684 )
BrakeCylinderPressureForMaxBrakeBrakeForce( 50 )
Empty 27 ton version of the same car:
Comment ( 27.5t railcar Max Pro Composition Brake Shoe values by Bill Prieger. Additional
braking parameters contributed by Jean-Louis Chauvin. )
BrakeEquipmentType( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )
BrakeSystemType( "Air_single_pipe" )
MaxBrakeForce( 10.6kN )
MaxHandbrakeForce( 57.2kN )
NumberOfHandbrakeLeverSteps( 100 )
EmergencyBrakeResMaxPressure( 90 )
TripleValveRatio( 2.5 )
MaxReleaseRate( 1.86 )
MaxApplicationRate( 0.9 )
MaxAuxilaryChargingRate( 1.684 )
EmergencyResCapacity( 2.604 )
EmergencyResChargingRate( 1.684 )
BrakeCylinderPressureForMaxBrakeBrakeForce( 50 )
Here's some comparisons:
-empty railroad freight car averages between 30 and 40 tons
-loaded semi-truck is about 40 tons max
-loaded typical rail car is about 125-150 tons and if I read correctly the FRA was thinking of upping max allowed rail car weight to 180 tons
Conclusion:
Under normal wind conditions, you don't even feel it affect your train due to the inertia or kinetic energy of the heavy loads
When does wind affect your train?
The only time I noticed wind affecting my train and it was so noticeable that I thought something was wrong with my power. I was taking a long transfer train from Eugene, Or to Albany, Or on straight tangent track descending water grade condition. I had a headwind of about 25mph w/gusts up to 40mph. The train I was running had 3 SD70m's that were brand new at the time and about 115 railcars with about 25 loaded woodchip cars and 15-20 loaded steel gons of scrap metal with the rest of the train comprised of empty bulkhead and centerbeam flatcars. Under normal quiet wind conditions I'm cruising @ 50mph in run 1-2. On that day I was in full run 8 and could only muster 35mph going downhill!!! I was confused to say the least and started looking for something that would affect my train to that degree. Air pressure on the rear? 85psi, nope no brakes are set and good brake pipe continuity. Big block of handbrakes? Nope, no visible smoke from any trucks in the train. And then it hit me all those bulkhead walls were huge sails grabbing that wind so basically I was dragging the equivalent of well over 50 huge open parachutes? So that explains the 45mph speed restriction on open-top empty gondolas and bulkhead and center-beam empty flats.
In my personal MSTS fleet of cars I always double the frontal area of empty gons and bulkhead/centerbeam flats using F2calc to make sure any air induced drag on my train containing these cars is as close to prototypical. Something for our physics team to consider. A year ago I posted this observation and what I do to add it to my trains physics. When updating your fleet to RW based physics w/RouteRiter, all wag files are automatically changed to reflect this in their friction regions. My question is, "are we going to have OR automatically insert the correct values in MSTS equipment or is it going to model the physics based on values present in the MSTS wag file? The reason being not all end-users are going to have my physics in their respective fleets.
Based on how responsive or rather how my train responds to automatic train brake reductions in loaded and empty trains of 50 cars. When correct RW figures are inserted in the appropriate brake regions in wag files, the sim is way off on it's calculations of these RW based entries and sets the friction retarding force way too high. I looked all over my external hard-drive for my copy of J-L Chauvin's brake region documents including the RW computed maxbrakeforce values for various weights of railcars but could not find it. I'm sure someone on the team has it. Based on actual in sim performance with adjusted maxbrakeforce values to get the braking charecteristics to "actually" mimic how trains really should act to different brake pipe reductions and stopping distances and retarding performance on steep descending grades, my maxbrakeforce values for a loaded and empty covered hopper are:
Loaded 127 Ton ALNS cylinder grain hopper:
Comment ( 130t railcar Max Pro Composition Brake Shoe values by Bill Prieger. Additional
braking parameters contributed by Jean-Louis Chauvin. )
BrakeEquipmentType( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )
BrakeSystemType( "Air_single_pipe" )
MaxBrakeForce( 26.4kN )
MaxHandbrakeForce( 28.8kN )
NumberOfHandbrakeLeverSteps( 100 )
EmergencyBrakeResMaxPressure( 90 )
TripleValveRatio( 2.5 )
MaxReleaseRate( 1.86 )
MaxApplicationRate( 0.9 )
MaxAuxilaryChargingRate( 1.684 )
EmergencyResCapacity( 2.604 )
EmergencyResChargingRate( 1.684 )
BrakeCylinderPressureForMaxBrakeBrakeForce( 50 )
Empty 27 ton version of the same car:
Comment ( 27.5t railcar Max Pro Composition Brake Shoe values by Bill Prieger. Additional
braking parameters contributed by Jean-Louis Chauvin. )
BrakeEquipmentType( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )
BrakeSystemType( "Air_single_pipe" )
MaxBrakeForce( 10.6kN )
MaxHandbrakeForce( 57.2kN )
NumberOfHandbrakeLeverSteps( 100 )
EmergencyBrakeResMaxPressure( 90 )
TripleValveRatio( 2.5 )
MaxReleaseRate( 1.86 )
MaxApplicationRate( 0.9 )
MaxAuxilaryChargingRate( 1.684 )
EmergencyResCapacity( 2.604 )
EmergencyResChargingRate( 1.684 )
BrakeCylinderPressureForMaxBrakeBrakeForce( 50 )
#29
- Superintendant
-
- Group: Status: Inactive
- Posts: 1,476
- Joined: 12-April 10
- Gender:Male
- Location:Back in the sticks of Virginia
- Simulator:MSTS/ ORTS
-
Country:
Posted 03 December 2011 - 03:27 AM
Hey, I don't know about the other two kinds of geared steam, but the Climax has springs in the trucks as well. Would the same physics be put into the climax?
#30 Inactive_Turbo Bill_*
Posted 04 December 2011 - 03:05 PM
Quote: Hey, I don't know about the other two kinds of geared steam, but the Climax has springs in the trucks as well. Would the same physics be put into the climax?
Yes, of course it would. In computing engine arcing in regards to rocking we would have to consider that locomotives are a constant weight with springs that are half-compressed all the time so the rocking would be the same regardless of what the locomotive is pulling in regards to loads or empties.
And Dave, yes, I know that many of these oscillations are track specific, but we don't have any OR generated routes but we have a ton of MSTS routes. For these, the rocking, bounce and forward backward motions would have to generated based on how I vision the sim doing it and still be eons ahead of the competition and those physical motions appearing to be controlled by the track. In many instances the present track structures the OR needs to compute the locations of where these motions should is already in the existing track structure. The slack motions are there or rather will be there because of the intense discussions in other OR threads used by the developers. The only real track induced motions is in regards to rocking and here we may have to punt until OR specific routes show up and this could take years to happen. I'm suggesting a system that could work here, now, in OR and still give a very prototypical representation in the area of car dynamics. The present track may not be wuper-elevated by that doesn't mean our trains can't lean as the progress thru the curves. The dips may not be modeled in the track but again I stated in real life you don't see these dips til a train actually goes over them and even a 2" dip which is hardly noticable at all has a profound effect on how far those engines and cars bounce when they go over them. When I was running a long freight drag at 50mph I didn't see a dip coming and warn my conductor to hang on. We couldn't see any of them heading our way but our training taught us to always be prepared for some jostling as we went down the line.
Hopes this helps understand my logoc and reasoning on how we implement these important 3D features into OR.
Yes, of course it would. In computing engine arcing in regards to rocking we would have to consider that locomotives are a constant weight with springs that are half-compressed all the time so the rocking would be the same regardless of what the locomotive is pulling in regards to loads or empties.
And Dave, yes, I know that many of these oscillations are track specific, but we don't have any OR generated routes but we have a ton of MSTS routes. For these, the rocking, bounce and forward backward motions would have to generated based on how I vision the sim doing it and still be eons ahead of the competition and those physical motions appearing to be controlled by the track. In many instances the present track structures the OR needs to compute the locations of where these motions should is already in the existing track structure. The slack motions are there or rather will be there because of the intense discussions in other OR threads used by the developers. The only real track induced motions is in regards to rocking and here we may have to punt until OR specific routes show up and this could take years to happen. I'm suggesting a system that could work here, now, in OR and still give a very prototypical representation in the area of car dynamics. The present track may not be wuper-elevated by that doesn't mean our trains can't lean as the progress thru the curves. The dips may not be modeled in the track but again I stated in real life you don't see these dips til a train actually goes over them and even a 2" dip which is hardly noticable at all has a profound effect on how far those engines and cars bounce when they go over them. When I was running a long freight drag at 50mph I didn't see a dip coming and warn my conductor to hang on. We couldn't see any of them heading our way but our training taught us to always be prepared for some jostling as we went down the line.
Hopes this helps understand my logoc and reasoning on how we implement these important 3D features into OR.