Jump to content



Photo
- - - - -

New Ball Momentum Physics Routine (BMPR)


  • Please log in to reply
58 replies to this topic

#1 jimmyfingers

jimmyfingers

    Pinball Fan

  • VIP
  • 832 posts

  • Flag: Canada

  • Favorite Pinball: Comet



Posted 12 May 2012 - 05:53 AM

VP's physics are currently quite good in general and more so it seems when compared to the other available simulators. However, even with the multitude of options, which have been great for tweaking / testing / having fun with the hobby, there still seemed to be a noticeable lack of weightiness / momentum of the ball that just couldn't be tuned completely. I felt that this characteristic was most perceivable in the lacking lateral motion at reasonable friction levels as well as the quick turn around from a ball rolling up table then back towards the bottom - at least when the slope was at a reasonably high enough value to have a decent acceleration downward.

Higher gravity, with higher friction, and lower slope seemed to help keep some downward acceleration while improving some lateral travel but was best paired with some table editing to increase to some rubber and other object elasticity values. But it seemed, in my experience, that I was always going to sacrifice at least one element of upward table momentum or lateral distance at the cost of slow or somewhat floaty downward acceleration even when the ball was heading straight down and had a good distance to run (somewhat most noticeable in open expanses).

After spending a lot of time over the last year trying to find the optimal physics settings, based on watching tons of video of targeted tables and going to see several pinball machines in person, I was seeing some improvement but realized, and with all due respect, that there were just simply limits to what VP could simulate. But, because of the great customizability and scripting engine provided, as well as lot's of examples of brilliant coding from other author's, I decided to work on creating / evaluating a potential system / routine that would alter the ball speed in real-time to provide both a means to help the ball travel up table longer while simultaneously improving it's acceleration downward and travel from side to side. Effectively, it was to simulate an improved momentum and revolves around adjustments at the speeds at which the ball is slowing down (in the case of down table, speeding up).

So, it is with much satisfaction that I report that I have successfully created a Ball Momentum Physics Routine (BMPR) that enhances VP's physics and allows for subtle but noticeable improvement and uses internally documented individual adjustable parameters for enhancing ball speeds for up table, down table, and lateral. All are independent of each other so you literally can stretch out how much longer a ball hangs while travelling up while also increasing the speed at which it travels down once it is actually travelling down.

It requires the ball collision tracking routines that PinballKen and Steely created for ball collision sounds as it uses this for tracking each individual ball in order to apply the required functions and to work with multi-ball. I also got the idea of how to implement a tracking for multiple balls from rascal’s ball rolling sounds script – so some credit out to them otvclap.gif Further to the tracking I use the get angle function from PinballKen and Steely’s fantastic script to allow me to use trigonometry to apply an appropriate force factoring value that is essentially the sole of this system that allows this to work and look natural in it's appearance / processing. For example, using COS and SIN calculations, it applies less force from the lateral helper portion of the routine when the ball is more angled up or down table then sideways, and more force when actually headed sideways. Same goes for the down routine where it applies the force proportionate to the angle of attack relative to the desired enhanced direction (straight down). The other part of the force value used in the calculation is derived from the parameters provided and turned into a non-linear (rectangular hyperbolic actually) function so that the value increases as the ball slows which is another key to simulating momentum. In the case of the down table it dissipates in a curved fashion as it approaches the maximum speed to apply the effect.

The demo table is oriented as a full overhead view to better evaluate how the ball is rolling without any persepective (angle or FOV) aspects. Here is a video I’ve posted on youtube showing the table and the contrast between the BMPR system when active and disabled (normal mode) - NOTE: the jitter is from the capture and video processing aspect and not the table / routine:


Their is quite possibly too much to try and explain about the workings of routine but it is actually very easy to implement as long as the ball collision script has been successfully added to a table. You would just need to copy a timer, the routine code section code, and potentially modify the arrays / interval speed for the number of balls possible at once if the table in question could have more than 4 - the default that I've created it with and good for anything from 4 down to 1).

In the demo table I use a set of lights to help demonstrate when the routine is active / applying change to the ball in the direction indicated. I will likely release a sample of the code / table without the lights but I've found in the tables I've implemented it in that I prefer to have the lights present and visible while at least adding, testing, and changing parameters. I normally keep the light objects / base / coding for them and when finished I would just move it to the side and off the screen and, by doing so, have it ready on hand when / if I want to tweak some more, move back on the table, and be able to see again the real-time feedback and confirmation that things are working as expected.

Mostly, what this routine and it's parameters have allowed for is to now be able increase the friction of a table to make the ball look heavier while, via the BMPR coding, maintaining good momentum / travel distance. In addition to the friction increase, it also has simultaneously allowed for decreasing slope for better lateral travel and more gradual up to down transitions without having a unrealistically sluggish downward acceleration.

In the test table use the "M" key to toggle the enabled state of the momentum routine, the "S" key to toggle an up and to the side kick for the lateral demonstration, and the "D" key to toggle the upper 2nd level drain for clearing the ball. You can also use your plunger launch key to kick additional balls out up to a configured maximum of 4. You may also need to nudge a little to the left or right if the balls have finished moving and are at rest on the upper platform.

The table is set at 1.675 gravity, 4 slope (min and max) with .2 Global Difficulty for some slight Scatter angle, and .0035 friction. The objects are at an elasticity of .75. In general, this routine and it's current parameters work best with around these settings as well as manipulating table objects for slightly higher elasticity (for example .6-.8 for rubbers). However, I have applied it to tables from all generations with great results and later generations tables would be more towards a 5 slope with some tweaking on the routines parameters. The key is keeping the friction higher and around the .0035 as well as the gravity at 1.675 or there about. In all the tables I've tested I've not once changed the gravity from this value. That being said I have changed the friction on some tables as low as .003 and as high as .00375. These will still be personal taste settings and simply the more friction the more BMPR effect you may have to add.

I have not noticed any real performance issues from implementing this script and it is extremely fluid to the point you would not know that anything is being “manually” manipulated regarding the ball speed. If you change the values to unrealistic levels it will still be pretty fluid but maybe just a bit crazy like the ball speed constantly increasing while going UP table.

There is more to discuss regarding how to use it for authors / modders but for now I’ll wrap up and can continue more in this thread with details as needed. The parameters have some documentation in the script itself but the gist of it is that there is a threshold in which the process kicks in for the particular direction (side to side, up, or down), a cut-off or max at which it no longer manipulates the ball speed and a level value that is used in calculations for the effect. Sticking generally around the “level” and threshold values in this demo would be a good base for the system from all the testing I’ve done. However, the deeper idea behind creating this demo table and the parameters the way I have is so that people can play around with them (for those who want to check out the scripting vs. just check out the effects with the toggle keys).

People are very welcome to use this code with the caveats that I mention in the remarks of the script. I'm going to contact a couple authors whose tables I've personally modded for this routine and the changes in the resulting physics to complement it. I hope I can release one of these as mostly, after all this, you really have to play a table with this routine to "feel" the difference.

Hope this BMPR system can add a little to the world of VP and helps others enjoy the tables at a different level for which I've been able to since creating it.

JF

Edited by jimmyfingers, 01 June 2012 - 02:00 AM.


#2 M33

M33

    Hobbyist

  • Members
  • PipPip
  • 19 posts

  • Flag: United States of America

  • Favorite Pinball: queen of hearts

  • PS3 Gamer Tag: Pinball_M33

Posted 12 May 2012 - 06:32 AM

Very interesting !
Thank you for posting

#3 rosve

rosve

    :)

  • VIP
  • 1,179 posts
  • Location:Always travelling around the world

  • Flag: Sweden

  • Favorite Pinball: Funhouse, Faces, Starship Troopers



Posted 12 May 2012 - 08:37 AM

Thanks JF,

This could make a major difference to the ball simulation, I always felt that a Moment Of Inertia setting was missing.
I'll try this on one of my EMs.



#4 Wahreez McDermot

Wahreez McDermot

    Enthusiast

  • Members
  • PipPipPip
  • 126 posts
  • Location:Sugar Land, TX

  • Flag: United States of America

  • Favorite Pinball: I can't pick just one!

Posted 12 May 2012 - 09:10 AM

Very cool. Looking forward to trying out a table with it implemented, original authors permitting of course!

#5 unclewilly

unclewilly

    sofa king.....

  • VIP
  • 5,170 posts
  • Location:Baltimore, Maryland

  • Flag: United States of America

  • Favorite Pinball: tz, tom, big hurt, who dunnit



Posted 12 May 2012 - 10:40 AM

wow that looks really nice. will give it a go in one of my tables.
thanks jimmyf

"it will all be ok in the end, if it's not ok, it's not the end"
 
Monster Bash VP10 WIP https://dl.dropboxus... (vpx)WIP15.vpx

uw2.gif


#6 johnparker007

johnparker007

    Enthusiast

  • Members
  • PipPipPip
  • 81 posts
  • Location:Sheffield, UK

  • Flag: United Kingdom

  • Favorite Pinball: Getaway II

Posted 12 May 2012 - 11:06 AM

Nice work! The ball definitely looks more realistic during the first half, when it hangs at the peak of its y arc smile.gif

Should this physics enhancement code perhaps be merged into the actual VP codebase (v9.12b / v9.13)...maybe with an option that defaults to off/zero, so that it doesn't affect existing tables (but they can be updated for it, along with the other adjustments that would be needed to get all the ramps shots etc working properly again) but can be seamlessly added to any new tables?

Edited by johnparker007, 12 May 2012 - 11:08 AM.


#7 rascal

rascal

    two-faced as they come

  • VIP
  • 1,374 posts
  • Location:Indiana USA

  • Flag: United States of America

  • Favorite Pinball: Bally Eight Ball



Posted 12 May 2012 - 12:32 PM

Nice work, jimmyfingers! dblthumb.gif
Trigonomewhatry? I never made it past Algebra.

All this calculating, how bad does it affect the frame rate in a full blown light fest table?

Maybe it should be implimented into the VP source project along with ball collision. Can you program in C++?

Posted Image


#8 TheMcD

TheMcD

    Pinball Wizard

  • VPF Staff
  • 2,461 posts
  • Location:Bavaria

  • Flag: Germany

  • Favorite Pinball: Frankenstein, Safecracker, Big Hurt, Four Horsemen, Tommy, X-Files

Contributor

Posted 12 May 2012 - 12:36 PM

Yeah, this definitely sounds like something that would be better off coded directly into VP instead of being added on a per-table basis.

VPF's resident pinball music fanatic.

The McD's Pinball Music Emporium: YouTube /// MediaFire (old tracks) /// Mega (new tracks)


#9 kruge99

kruge99

    Pinball Wizard

  • VPF Staff
  • 3,901 posts
  • Location:Markham, Ont.

  • Flag: Canada

  • Favorite Pinball: Black Knight, High Speed and Pin*Bot



Posted 12 May 2012 - 12:51 PM

Thanks Jimmy, I'm very interested in testing this!

I'm not much of a programmer, but would I simply copy and paste your script into the table script, create the necessary timers, and it will "just work" as long as the multi-ball doesn't have more than 4 balls in play simultaneously?
ie: I'd be interested to see how this affects Sinbad.


Best Regards,
Todd.

[proud owner of a Williams Solar Fire]

- It's called "The American Dream" because you have to be asleep to believe it.
George Carlin
- Truly great madness cannot be achieved without significant intelligence.
Henrik Tikkanen
- "Reality check, Michelle, Talk about composure, Total lack of. He's a man-- About-- 12 Feet Tall--"
Carrie Kelly
Posted Image

#10 rob046

rob046

    Often Emulated, Never Duplicated

  • Members
  • PipPipPipPipPip
  • 2,023 posts
  • Location:Central PA

  • Flag: United States of America

  • Favorite Pinball: 8 Ball Deluxe, ToM, & Funhouse



Posted 12 May 2012 - 12:56 PM

I'm not good at following the science & numbers behind all this stuff, but I'm very good at just knowing the feel of pinball & when something is off a little I notice it. Honestly I can't make too much of this demo, I'd really have to try it out on an angled desktop table to be able to see how it feels compared to real pinball.
But if this is something that can help & can somehow be integrated into VP, then that is pretty awesome. While I do think VP's physics these days, if tweaked well enough, can be quite accurate, there is obviously always room for improvement in some areas.

#11 Lynny

Lynny

    Enthusiast

  • Platinum Supporter
  • 130 posts

  • Flag: United States of America

  • Favorite Pinball: Target Alpha, Evel Knievel, Creature From The Black Lagoon, 8 Ball Deluxe

Posted 12 May 2012 - 04:17 PM

I can't wait to see how this feels, too. I'm curious, will the table angle, inclination, etc...affect your physics calculations? Math isn't my strong suite either.. smile.gif

I'd like to see it added directly into VP, make rollout much simpler for those of us that have loads of tables already setup...


Peace,
Lynny

Peace,
Lynny

#12 Arcade4

Arcade4

    Pinball Fan

  • Members
  • PipPipPipPip
  • 1,686 posts
  • Location:Beaumont, TX.

  • Flag: United States of America

  • Favorite Pinball: AC/DC

Posted 12 May 2012 - 05:14 PM

What a great idea.
However it gets implemented, I can't wait to try a table with it.


#13 jimmyfingers

jimmyfingers

    Pinball Fan

  • VIP
  • 832 posts

  • Flag: Canada

  • Favorite Pinball: Comet



Posted 12 May 2012 - 06:16 PM

QUOTE (rascal @ May 12 2012, 08:32 AM) <{POST_SNAPBACK}>
Nice work, jimmyfingers! dblthumb.gif
Trigonomewhatry? I never made it past Algebra.

All this calculating, how bad does it affect the frame rate in a full blown light fest table?

Maybe it should be implimented into the VP source project along with ball collision. Can you program in C++?

I haven't seen it make any difference at all yet on any of the tables I've added it to. I've added it to my Scared Stiff GI8 Mod which is pretty demanding and haven't noticed any change. Scared Stiff multi-ball of some sort is pretty frequent and I don't recall it looking any different and am a stickler when it comes to getting things as fluid as possible. I did initially pay very close attention to any performance aspect when assessing the feasibility but it became almost moot as I noticed virtually nothing. I think VP seems to handle scripting in this fashion pretty good as it has no real tie-ins to graphics calls (it seems very content to be doing all these calculation dozens of times per second as long as it's not dropping walls or fading alpha ramps smile.gif

You can try a performance assessment on the demo with the FPS, just hit the plunger key to get 4 balls going and watch the FPS with the momentum enabled and disabled - it's not going to change in any substantial way. The lighting and multi-ball demands of any table appear to remain independent factors on performance, whether this routine is enabled or not. On my test system I got around 1000 FPS on the demo table with 4 balls going and really can't see it change once I enable the momentum routine.

By the way, unfortunately, I don't know C++ and the scripting even required me to draw back on my much earlier in life computer science education (I'm a techy for a living but not a programmer). As far as adding it to the core, it still completely requires the Ball collision script to work so it would dependant on that which has obligations for how kickers and such on the table destroy and create balls which is unique to each table. If the day comes where ball tracking / IDs can be done natively with VP / VPM then both these routines could probably be added or at least modifed to work with it. Some of the other authors / developers may have more insight into the feasibility of the Ball Collision element and how it pertains to potential incorporation into the source code.
QUOTE (kruge99 @ May 12 2012, 08:51 AM) <{POST_SNAPBACK}>
Thanks Jimmy, I'm very interested in testing this!

I'm not much of a programmer, but would I simply copy and paste your script into the table script, create the necessary timers, and it will "just work" as long as the multi-ball doesn't have more than 4 balls in play simultaneously?
ie: I'd be interested to see how this affects Sinbad.


Best Regards,
Todd.

If a table already has the ball collision script added and working with the number of pinballs in that script set at 4 or more, then yes, just add the code segment, the timer, and the collection of lights (with their base wall underneath). You will want to change the main physics settings of the table once you do to be around 4-5 slope, with 1.675 gravity, and .0035 fricition and go from there. I also increased the rubber elasticity (and some other objects) on all the tables I added it to for some nice realistic slow bounces and on one or two occasions I had to make a small collection of triggers to help a ramp out in a fluid way due to higher friction.

I smiled when I saw your reference to Sinbad as I actually have a modified version of this one as it is a great table and I wanted to compare a real life video sequence that showed lot's of lateral ball movement in one segment to your table with this routine added - I got it very close and I think it plays even more realistically now. We can PM as I have two of your tables that i did with the routine for personal use and they both feel great I think (they were both fantastic to start with and is why I could justify spending the time on them with this routine during the development stage). I can forward you the Sinbad if you want to see what I've done (it's not fully tweaked yet but about 80%) and even the other one.
QUOTE (Lynny @ May 12 2012, 12:17 PM) <{POST_SNAPBACK}>
I can't wait to see how this feels, too. I'm curious, will the table angle, inclination, etc...affect your physics calculations? Math isn't my strong suite either.. smile.gif

I'd like to see it added directly into VP, make rollout much simpler for those of us that have loads of tables already setup...


Peace,
Lynny

The table angle and other view settings makes no difference in the BMPR calculations nor do they for any aspect of VPs physics in any other table / situation to my knowledge. They may "look" different because of the perspective but things don't change at a physics level. You can assess / confirm on the demo table by observing the VelY columns with it in it's overhead view then watching them with a 45 angle / 45 FOV change and you will see no change in the statistics / values.

Edited by jimmyfingers, 12 May 2012 - 06:36 PM.


#14 TedB

TedB

    Pinball Fan

  • Charter Member
  • 715 posts

  • Flag: Netherlands

  • Favorite Pinball: those with non virtual steel balls

Posted 12 May 2012 - 09:25 PM

Interesting. Looking forward to play the first FS updated table on my cabinet.

#15 unclewilly

unclewilly

    sofa king.....

  • VIP
  • 5,170 posts
  • Location:Baltimore, Maryland

  • Flag: United States of America

  • Favorite Pinball: tz, tom, big hurt, who dunnit



Posted 13 May 2012 - 12:29 AM

hey jimmyf.
when you added this to scared stiff did you find that it through off the flipper settings

"it will all be ok in the end, if it's not ok, it's not the end"
 
Monster Bash VP10 WIP https://dl.dropboxus... (vpx)WIP15.vpx

uw2.gif


#16 jimmyfingers

jimmyfingers

    Pinball Fan

  • VIP
  • 832 posts

  • Flag: Canada

  • Favorite Pinball: Comet



Posted 13 May 2012 - 01:08 AM

QUOTE (unclewilly @ May 12 2012, 08:29 PM) <{POST_SNAPBACK}>
hey jimmyf.
when you added this to scared stiff did you find that it through off the flipper settings

Actually, yes but I was working on a flipper routine as well for better straight table shots without overkill on the oblique correction. I had to push forward that flipper routine to help compensate for what I noticed that it had changed regarding the flippers. It actually changed Scared Stiff's flippers more noticeably then on any other table that I added it too.

Since then and on the last few tables, I have found that Kruge99's flipper's from High Speed seem to be at some perfect balance of being able to shoot fast rolling balls through the lane still straight up the table without too much oblique correction or over-correction on slower balls, and still being able to hit the side targets, they aren't overkill for strength, and they generally work well. I have copied them exactly as is to a couple other tables that I have implemented the BMPR script and used them instead.

I've been playing a lot with flippers as well and have another routine for a weaker shot with a quick flip using timers (without delay) so the aspects on flippers for tables has been obscured because every table I've been modding, I've also been re-working the flippers. But in short, some adjustments to flipper settings is quite possible with and because of the other changes that I mention above plus some of the extra lateral helper's effect on obliqueness.

PM me with the table you're working on and I could test some stuff or if you want I could forward you the changes to Scared Stiff if you were actually testing on that one but I'm assuming the former.

Edited by jimmyfingers, 13 May 2012 - 01:10 AM.


#17 jpsalas

jpsalas

    Grand Schtroumpf

  • VIP
  • 7,300 posts
  • Location:I'm Spanish, but I live in Oslo (Norway)

  • Flag: Norway

  • Favorite Pinball: I like both new and old, but I guess I prefer modern tables with some rules and goals to achieve.



Posted 13 May 2012 - 03:44 AM

I think the idea to find a way to get better physics in VP is nice. But you can get a similar effect by reducing the ball/table friction, the Contact Friction. As standard VP has this value at 0.0025 and many people said it is was too small and it should be increased to 0.0035 or 0.004. But I actually always thought that the ball has actually very little or no friction at all. It all depends if the playfield is clean or not smile.gif To get that ball movement on at table I could simply reduce that friction to 0.001 and you get back that bounciness and side movement.

If you want to check my latest uploads then click on the image below:

 

vp.jpg

 

Next table? A tribute table to Stern's Foo Fighters


#18 jimmyfingers

jimmyfingers

    Pinball Fan

  • VIP
  • 832 posts

  • Flag: Canada

  • Favorite Pinball: Comet



Posted 13 May 2012 - 05:04 AM

QUOTE (jpsalas @ May 12 2012, 11:44 PM) <{POST_SNAPBACK}>
I think the idea to find a way to get better physics in VP is nice. But you can get a similar effect by reducing the ball/table friction, the Contact Friction. As standard VP has this value at 0.0025 and many people said it is was too small and it should be increased to 0.0035 or 0.004. But I actually always thought that the ball has actually very little or no friction at all. It all depends if the playfield is clean or not smile.gif To get that ball movement on at table I could simply reduce that friction to 0.001 and you get back that bounciness and side movement.

I'm honoured to have some of the big names on this forum and in this hobby assessing and commenting about this topic / routine. I respect you and your work tremendously and understand what you are saying JP about extending ball range and bounciness in general with dropping friction to lower levels and even experimented with these settings when I first started trying to reproduce the effect of real table ball physics shortly after getting into VP. But the low friction of .001 or .0015 just didn't feel right.

If nothing else, there are two major differences to simply lowering the friction vs. using my BMPR system: 1) Just lowering the friction caused the ball to not look as weighty and seemingly slide / shoot around the table like on ice vs. a metal ball on a hard surface. 2) The major element / aspect of the routine is that it is not adding speed / enabling speed throughout the entire life span of a velocity vector - it is only applying the augmentation when the ball speed passes a defined threshold, then as it decays it adds it at an increasing magnitude (an inverse and non-linear relationship) which models a heavy object at slow speeds still trudging along and thus having momentum vs. just more speed from start to finish.

An example I can think of is that a plastic ball might role fast and role to a particular distance on a surface, but a heavier metal ball could roll slower and still make it the same distance that the plastic one did. I think my routine, with some changes to the table physics, facilitates making the ball act more like a heavy metal ball whereas lowering friction just makes it seem like a faster plastic one.


#19 rosve

rosve

    :)

  • VIP
  • 1,179 posts
  • Location:Always travelling around the world

  • Flag: Sweden

  • Favorite Pinball: Funhouse, Faces, Starship Troopers



Posted 13 May 2012 - 09:18 AM

I've been testing this on one of my tables, it took some time to understand how to use the parameters but I think I got the hang of it now.

It probably depends on witch table you are working on but I feel that the default parametes are adding too much sideways momentum. On a well tuned EM table the Momentum code doesn't really improve the behaviour at all. It probably makes more of a difference on the newer and faster SS tables.

Here is a little video I made of two (real) balls with different mass rolling down the glass of my pincab. I needed to see how much the mass would change the ball trajectory to be able to tune the physics on my table. I have made many different trials like this when working on the tuning for my EM tables smile.gif.
Rolling Balls

#20 unclewilly

unclewilly

    sofa king.....

  • VIP
  • 5,170 posts
  • Location:Baltimore, Maryland

  • Flag: United States of America

  • Favorite Pinball: tz, tom, big hurt, who dunnit



Posted 13 May 2012 - 11:38 AM

2 questions jimmy.
1. what range of elasticity are you using for the rubbers. i usually set mine round abouts at .7 i think. id have to check my starter table to be sure.

2. what im most concerned about is the amount if any stutter is added to the table. my tables seem to be notorious for causing people to have ball stutter. this would be my main concern with applying the engine to my tables.

i dont have anything new enough to try to apply this to right now and im a little short on time at the moment.
do you think you could add this routine to my freddy nightmare on elm street table and send it my way. this table seems to cause the most issues for people and i think it may be a good test of if the engine causes stutter

i appreciate you doing this. anything that makes the ball movement more realistic is a plus to vp.

also curious as to how this effects the nudging.

should have some time to play with it some tonight

thanks jimmy, your work is much appreciated

"it will all be ok in the end, if it's not ok, it's not the end"
 
Monster Bash VP10 WIP https://dl.dropboxus... (vpx)WIP15.vpx

uw2.gif