Friction settings clamped too low


Continuing the discussion from Missing static friction:

Since it looks like static friction simulation is not being addressed I tried to work around it by making a script that upon collision start raises the dynamic friction of an entity to the maximum, reverts it to previous value upon collision end. That didn’t work, so I tried this manually (as I wrote in the bug report topic). I noticed that any values for friction about 0.9900 are capped. This bug is similar to other bugs with rotation positioning where the value is either quantized to or clamped at too coarse a resolution Friction should be able to go to 0.9999 because there are many cases where one wants a surface to stop anything moving with considerable sliding force.


Thanks, I’ll log that




BTW, I assumed the 0 to .1.0 range for friction was a normalized value: 0 means no friction, 10 means maximum friction as in the inverse force = the actuating force. It looks like this value is just being passed to bullet unnormalized.

Did I miss a PR that permitted higher values?


I filed a bug report based on your post, and ctrlaltdavid appears to have closed it out as fixed… I believe.

here’s the PR


I’ll respond @ github


@Balpien.Hammerer It sounds like a good idea to me to normalize the friction value. Note: If it is changed to be normalized then existing scripts using friction will need to be updated (seems like there’s only golfClub.js).


The reason I prefer normalized values is that the way it is currently done is baking in Bullet implementations as architecture. Should it come to pas that another or better physics engine is desired then it becomes so much harder to deal with institutionalized implementations.