Coding suggestion: r = sqrt(r1 * r2) -> r = r1_ * r2_

[tatt61880]

Cool thread, I like it when people abuse Phun wink

Here's a tip to you all: when determening the restitution (aka bounciness) of a collision, the following formula is used: r = sqrt(r1 * r2), where r1 and r2 are the restitutions of the two geometries. This means that if r1 and r2 are both negative, you get the same result as if they were both positive. If just one is negative, however, we get the square root of a negative number - this is an imaginary number, but it just get's represented as NaN - Not a Number. And anything done with a NaN will result in more NaN, ie bad values for everything from velocity to position. The same formula is used for caluclating friction.

Here's a question: should I allow for negative-positive interaction in the bext beta by changing the formula to r = sign(r1)*sign(r2)*sqrt(abs(r1*r2)) ? This would allow for collisions with negative restitution and/or friction.

Sorry for a quotation of ancient post above.

I guess the following formula is used, currently: r = sqrt(r1 * r2)
The formula has one sqrt and one product (*).

I suppose that next fomula will be faster: r = r1_ * r2_
where r1_ and r2_ equals sqrt(r1) and sqrt(r2), respectively.
The formula has one product and two sqrt, but sqrt can be calculated beforehand.
So the formula requires one product and zero sqrt with simulation.

i.e. I suggest that ... when we changed the restitution of geom, the sqrt(restitution) is calculated and stored into PC memory. And then the variable is used for when the geom collided.

Is this a good type of suggestion? or already been tried?
I hope my explanation is enough to tell my idea.

Regards,

Tatt

[Mystery]

I don't quite understand what this will be changing but it would be essential not to alter the restitution force with the new algorithms for compatibility sake with older scenes.

These are cool sorts of suggestions though.

[gradyfitz]

I don't quite understand what this will be changing but it would be essential not to alter the restitution force with the new algorithms for compatibility sake with older scenes.

These are cool sorts of suggestions though.

Not quite, the algorithm here would be calculated beforehand, like mass, and could be stored in memory for later use, this can save calculation time if rather than having to do a sqrt function, you only have to do a multiplication function, sqrt functions can be about 15 times (maybe more or less, I don't have the numbers right now, but around that mark) as costly in terms of calculation times, so eliminating this from an active calculation can reduce each calculation step, it may not seem very significant at a very small level, but as you increase the number of instances, you increase the number of times each calculation is made, if, rather than calculating it for each collision, you are able to pre-calculate the value, it may make a very significant difference on a large scale.

This seems like it should work ( √4 * √4 = √(4 * 4) ), it would likely improve the calculation speed because a variable is still being accessed in order to give a value and the initial calculation time wouldn't be too bad (though you would be doing twice the sqrt calculations to begin with, but this would likely not be much of an issue).

I suppose we will have to wait to find out, but this could be a good suggestion I think.