On some tables the ball bounces of a rubber with so much backspin that it positively does an "about face:" starts to head in one direction, but then quickly and expectedly reverses course. Has anyone else seen this behavior?
This aspect / behaviour was raised earlier in this thread as well and although the rubber object may / does have some of it's own oddities, there is a reason / explanation for how the physics settings on a wall object also causes this and is in essence, due to improperly set friction for the most part.
Taking a wall (or even rubber object) used as a rubber collision (so high elasticity), when it's friction is inadequately set accordingly (too low and typically something .2 or lower but especially with settings that I still see on some tables of a .0xx for friction), what happens is the ball rolls (is spinning in direction of roll) into the object in question but without a proper friction setting, when the ball bounces off and changes it's trajectory according to the elasticity, yet it is still actually spinning in the direction of the initial path (pre-collision) as there was / is not enough friction to cause the ball roll direction to be reversed (for it to "bite"), and then shortly afterwards the rolling / spinning direction is still going the original / (now opposite rotation direction) to where the ball is now moving, then "kicks-in" and the ball looks like it's putting on stoppers as the old roll / spin direction and new trajectory balance out after a brief "fight" against each other. As these opposing elements occur, that is when one sees the extra odd ball "back spin" / slow down. But it's not actually / ultimately caused by the table friction being set to generally recommended levels, instead what is causing it and making people think it's the high table friction is actually the improperly low friction of the collided object as described above. The reason it can be incorrectly associate with higher table friction is that with improper object friction setting, a very low table friction can mask the effect as the table is simply too slick / like ice and no ball spin has any effect (can be observed using F11 and following the white dots). So lowering friction on the table to "fix" this issue is not addressing the main / real problem. What is the main problem is that all the nuances and details of per object based physics settings (mainly friction) are being somewhat overlooked vs. the easier and more general table settings. In still a reasonable amount of tables some of these objects look like they still have VP9 settings or simply the value chosen is much too low for the appropriate real life counter part - i.e. rubber not being set at .5 or higher.
I have still seen this general ball bounce back then bite effect sometimes in real life but from bounces off of slick surfaces like metals (can show and instance in a Lethal Weapon 3 video) and as such also should happen occasionally in VP but really from the same type of low friction surfaces like metals and hard / stationary plastics / targets and not from rubbers. Sometimes air balls in real life and rubber collisions that launch the ball off the table can affect this as well but for the most part, if the ball is not leaving the table from a rubber collision the spin is being reversed by the rubber's friction during the collision and not after as it bites down on the table as can still happen with a hard target or metal side hit.
Part of the big issue about the physics settings is quite simply that end users are more looking for quick and simple fixes for table "physics settings" and / or not understanding what really VPX physics tuning now entails regarding having to set every single object a ball hits totally appropriately / accordingly with most discussions and views mainly being too narrowly focused and totally hinged on the couple basic / general tables settings being mostly slope settings and friction (gravity should be always around .95-1 but even that on some tables is set way too low and has been totally left as is from VP9 leaving it at numbers starting with .6 or .7 and a long string of decimal places - a clear sign that it hasn't been set since VP9). I still see some current tables that have a previously typical old friction setting on collidable / relevant objects at .004 which is way to low and will be a problem (nothing on the table that the ball hits shout ever be lower than about .1 or .15 and that only for the slickest metals and rubbers should be at least about .5 or the phenomenon and visuals experienced and reported will occur. Again, turning the table into an ice rink to avoid some of this particular odd ball appearance / reaction is not the solution.
It is tedious and time consuming for sure to go around to each collidable object on the table and verify / set elasticity, friction, and scatter appropriately but it needs to be done and as long as it is not complete on some tables it will be continuing to confuse people and skew perception of VPX, which isn't fair to the developers and is more on the shoulders of the table authors / builders / modders. What I recommend and typically do is create collections for each type of object and some with a couple categories (rubber_pegs, rubber_posts, rubber_bands, metals_thin, metals_thick, woods, etc.) so that while building / modding a table I can select the groups of similar objects (and place new / copied objects of the same type in the defined collections) and tune / set / alter the physics as needed in a much more efficient way then leaving them ungrouped and requiring clicking on each individual object to make physics changes or verify their settings, which really seems related to why they are getting left behind on some tables. This grouping / collection maintaining is a bit tedious as well but is worth the initial effort and I can't stress enough that at the time of building, using collections for these types of things will save people time down the road and is of huge benefit for tuning later with these groups as well as helps keep the table organized in a few ways.
I hope this goes to assist authors / builders / modders and end users in understanding at least this one element / nuance and provides some food for thought on the larger aspect of complete physics tuning and understanding for VPX.
Edited by jimmyfingers, 07 January 2016 - 11:32 PM.
Top
are all trademarks of VPFORUMS.