Hi!

By random decision I mean a situation where an object falls on an edge or a corner (45 degree rotation) and it’s meant to fall on one of it’s sides. How does the engine decide about how it will fall? Is it fixed in some way, like always on left side, or is it random like Math.random() or an optimized version of it, like >> vx += getTimer() % 2 ? .2 : -.2 <<, or it is randomized in other way not based on time, like using a custom random function taking object properties and an iterated value as a seed?

Let’s say I throw dices. After they are thrown, before I can check what faces are on top, I need to wait until they stop moving, and then wait a little more until they really, technically, stop moving, and that could be annoying for a player. So I could just cache the throw animations, and store arrays of dice positions and rotations, but that could use a lot of space… So I could just cache initial dices positions and vectors and their results, but if the collisions won’t always go the same way (for the exact same starting parameters) then a player will see dices showing different result then my GUI.

I hope I made it clear. Should I maybe write this question on some Bulletphysics forum? Any link to it would be appreciated.

Not a clue on the decisions thing.

Done the dice thing and yeah noticed the time for the dice to fully settle (was checking when the rigidbody was alseep) took some time.. Another way round that was to check its velocity, angular/linear and when its below a certain value you know it cant roll to the next face.

JohnBrookes - 16 June 2012 04:15 PM

Not a clue on the decisions thing.

Done the dice thing and yeah noticed the time for the dice to fully settle (was checking when the rigidbody was alseep) took some time.. Another way round that was to check its velocity, angular/linear and when its below a certain value you know it cant roll to the next face.

As for quickly checking for the end, indeed I could do something like this, though I’m still interested in the nature of repetitiveness. Everytime I throw a dice, it lands in same place, I think I’ll make some automated tests to check like a 1000 throws.

I asked the question on Bullet Physics forum, if I get an answer, I’ll write about it here as well.

My simple tests and an answer on Bullet Physics forum say it is deterministic, that is, for one starting configuration (objects, their positions, rotations and speeds) there is only one ending result.

Hello Etherlord,

I don’t think its deterministic , even in the original Bullet it’s not, aldo they are working on a new version that will support this ‘better’.

But if you have test that proof it’s deterministic in flash I would love to see that.

If it’s really important to prevent like cheating I would suggest that you either run the physics on the server or have it calculated on the server and use Away3D just as a ‘client’ (like showing per-calculated animated throws).

Good luck.

As I said, these tests were simple, so they rather proof that I’m lucky to get same results, not that it will always be the case. That’s why I bothered you guys in the first place, as I couldn’t be sure.

So thanks for your answer, it will save me some time. Cheating is not a problem, I would never trust a client’s output, the thing was, that server could send the client only starting positions, not whole animations. If it’s not deterministic, then client and server could desynchronize. If they desynchronize on hacker’s pc, no problem, the hacker gets an error, but if it happens on normal guys computer, then he might be quite surprised and upset that he sees one dices result, and the interface shows another.

The question is, why it’s not deterministic. If it uses Math.random() (its equivalent for C), then it’s obvious, but if it only takes objects configurations as a seed to randomize, then if you wouldn’t change light, camera and materials, the results would be deterministic.

But in the end, if pr0 guys aren’t sure, I’ll rather be on the safe side and assume it is _not_ deterministic. Thanks again.