халявный и мертвый.

Я делал в принципе, как вам советовали постами выше, 3d с 10 апи плеера, и физ двиг жигЛиб, но задача другая была, надо было, что-бы они падали, как бы случайно, но выпадало, то что надо нам...
http://murmadillo.tut.su/m/CubeGoBottom.swf

А есть гарантии, что физ. движок отработает качественное случайное выпадение граней? Мне почему-то с самого начала задача виделась такой:

1. рандомайзер генерирует три грани — результат броска.
2. анимация строится на основании этого результата — финального положения костей.

Или это лишнее в таких играх?

Добавлено через 12 минут
К тому же, как меня правильно поправляют, пункт 1 вообще не на клиенте "решается" — его сервер выдает. Следовательно от рекурсивного построения анимации или pre-rendered (pre-calculated) заготовок не уйти. Последнее, к слову, претендует на лучшее решение.

Да здесь вообще одной анимации хватит по сути, значение грани то видно уже впринципе только при остановке костей, просто вывести результат рандомайза в самом конце, и все.

Ну это с натяжкой =) неаккуратненько как-то.
Я бы вообще делал все-таки не pre-prendered, а pre-calculated 3d с предварительной прорисовкой текстуры в нужном положении.

pre-calculated 3d наверное получше, и тоже одной анимации хватит, в общем уже от автора зависит)

Одна — скучновато =) да и запомнить несколько анимаций не так затратно.

ну да, и рандомно их юзать

Можите ли вы поделиться исходным кодом?

Напоминаю о просьбе )