I'm programming a throw of 5 dices in Actionscript 3 + AwayPhysics (BulletPhysics port).
I had a lot of fun tweaking frictions, masses etc. and in the end I found best results with more physics ticks per frame. Currently I use 10 ticks per frame (1/60 s) and it's OK, though I see a difference in plus for 20 ticks.
Even though it's only 5 cubes (dices) in a box (or a floor with 3 walls really) I can't simulate 20 ticks in a frame and keep FPS at 60 on a medium-aged PC. That's why I decided to precompute frames for animation, finishing it in around 1700 ticks in 2 seconds. The flash player is freezed for these 2 seconds, and I'm afraid that this result will be more of a 5 seconds or even more, if I'll simulate multi-threading and compute frames in background of some other heavy processes and CPU drawing (dices is only a part of this game).
Because I want both players to see dices roll in same way, I can't compute physics when having free resources, and build a buffer for at least one throw of each type (where type is number of dices thrown). I'm afraid players will see a "preparing dices........." message too often and for too long.
I think the only solution to this problem is replacing PhysicsEngine with something simpler, or creating own physicsEngine. Do You have any formulas for cube-cube and cube-wall collision detection, and for calculating how their angular and linear velocities should change after a collision occurs?
Edit: I'm assuming the only way to solve my problem is to make a cube-cube and cube-wall collision engine, however maybe there's another solution for my problem.
- As Arthur pointer out, there can be one animation - for me this is just a shortcut, I could as well show the final result without any dices rolling.
- However, I thought about making 100 precomputed dice throws, though a user won't avoid repetition here as well. Sometimes a dice sits on it's edge (or corner) for a while, and that gives player some excitement (will it fall on 5 and give me a full house?), but with limited number of animations a player would already know how the animation will end.
- Buffering solution would work, if players would see dices roll in different way (results would still be the same) - I'm considering this solution, however I'm still going to try to create a simple physics engine and see how it works.
- less ticks is a solution I don't consider, because at as few ticks to be able to simulate physics in real-time, the dices behave not better than if I treated them as balls in my physics engine...