512
I wrote a dice rolling script with 3d rendering, collisions and friction in bash because why not [edit: code available now]
(files.catbox.moe)
Daddy needs a new pair of RAM!
edit: the fps are way better in smaller terminal windows with lower character count but then it's hard to make out the dice. D:
edit2: code here (expires in 2 weeks)
the final resolution stage was a huge headache and as you can see, one I didn't fully solve. Basically when the dice finally settle, particularly those with more sides, lots and lots of micro collisions happen in close sequence, each one having to apply friction and bounce back. As velocities come close to be rounded to 0, the bounce back effect and force of gravity no longer provide movement, but the final angle of the bottom face may not be fully settled on the floor. So basically if i don't ignore all these tiny collisions I get the frame rate drop you see and if I do, I can arrive at not fully settled states which can become ambiguous result-wise in, say, the 20-sided die.
Can you predict the resolution when it is close enough to settled? Worst case maybe have an algorithm that estimates the probability of each face ending up on top, and if one face is overwhelmingly more probably, choose it. Otherwise let it settle using your physics engine
I can easily check for when motion stops, but checking for when any particular face is both parallel to the floor and at the same level can be computationally expensive, particularly in the dice with more sides. What you're suggesting is likely a good idea, but I wouldn't know how to get probabilities without doing what I just mentioned. I'm sure there's an optimization i can do with this that I can't think of rn.
Cross products! If you take the cross product of two edges of a face, you get a perpendicular vector for that face. It shouldn’t be too bad to do 20 of those per frame to find if a face is level with the ground (cross product points straight up and/or down depending on how you’re doing them)… now I don’t know about the velocity/acceleration numbers (including rotation)…
maybe just "if velocity < 0.01, find which side is closest to the floor, and if its within 1mm of the floor, take the opposite side (the one facing up) as the answer"
The only edge case I can think of is if it gets close to balancing on an edge, and then finally tips over to one side or the other. But in that case I don't think the face closest to the floor would be within 1mm of the floor, so it should still work.
that's how it's implemented, mostly, but sometimes dice "stop" while they're still tilted and standing on a corner (and then roll back down, possibly going back more than 1 face) so there's also that.
Ok well there's probably a dozen different ways to tackle this issue but I'll let you explore them since that's part of the fun (and I'm lazy lol)
why not save the state of the di(ce) in the settling phase and choose (or allow user assignable) value for how many consecutive identicle states before freezing the di(ce) and reporting the result?
my only concern would be a "spinning" di but short of colliding with other dice, that seems technically solved
that's one of the aspects of the current implementation
Since you're rolling on a plane, can't you simplify the collisions to only check the corners? I think that should be all that's needed. There shouldn't be a time where the edges or faces are below the lowest corner on a plane, so they can be skipped I believe.
i need to check the corner collisions but when the die start settling and an entire edge comes close to the floor, gravity keeps pulling back on several of them making them bounce back just a tiny bit, not reaching the velocity that gets rounded to zero.
I fixed that on the current version doe!