Interestingly (or annoyingly, depending on how you look at it) the equation for determining sphere friction doesn't work for boxes. Where a sphere's friction ranges from 1x mass=0% friction, 10000x mass=100%, friction, for a box I've found 0.001xmass = 0% friction, 10x mass=100% friction. Also the gamma seems different, and a 0.75 value fits more comfortably than the 0.5 for the sphere going by my very rough observations.
Here's a function for determining and setting a boxes friction.
Strangely in testing it worked the same for all masses ranging from 0.001 to 1000, except for mass=100 where the box stopped slightly short! (??) Odd. Maybe this is one of those arbitary DirectX rounding changes in effect.
VIP3R : The addition to the include file makes sense. It's not a time critical function. Is there any convenient way to switch between two implementations, one with optional friction responses and one with static, short of providing two different .dlls? Otherwise it might be worth keeping a trimmed .dll without the extra functionality if it'll add a performance hit when most people don't need it.
Here's a function for determining and setting a boxes friction.
Function SetBoxFriction(geom.ODE_Geom, mass, friction#) ; geom.ODE_Object : ODE geometry object ; mass : Object's mass ; friction : Oject's friction as percentage gamma=0.75 ; Change for different relationship between percentage and friction friction=friction/100 friction=friction^gamma friction=friction*4 friction=4-friction e#=Log10(SPHERE_MASS*10) e=e-friction dGeomContactSetMu(geom,1*(10^e)) End Function
Strangely in testing it worked the same for all masses ranging from 0.001 to 1000, except for mass=100 where the box stopped slightly short! (??) Odd. Maybe this is one of those arbitary DirectX rounding changes in effect.
VIP3R : The addition to the include file makes sense. It's not a time critical function. Is there any convenient way to switch between two implementations, one with optional friction responses and one with static, short of providing two different .dlls? Otherwise it might be worth keeping a trimmed .dll without the extra functionality if it'll add a performance hit when most people don't need it.