Hello!
Yeah, well following the code might not be the easiest, I am learning Lua while doing this. kikito's assessment is correct on the main objectives of the individual files.
I chose the name "star" in order to avoid "object" as it is way too loaded in a software context. I call it a star because in the simulation part dice are treated as a set of points connected rigidly to a center, like a hedgehog or the rays shining from a star. "hedgehog" would sound kinda silly, wouldn't it? There are no faces or anything else complicated in the physics part.
There are severe limitations in this "engine", in the simulation, in the lighting model and also in the rendering. I think that this scenario (a few dice in a box, maybe up to 1000 polygons total plus a single light source) is all that Lua+Löve can handle with this approach.
Physics:
The engine handles a set of stars, ie. dice, as explained above. There is some collision handling going on with the walls of a box around the scene. To ease on collision detection, walls are just infinite, immovable planes, and dice bounce off them. Die-die collision is working at my desktop, but it treats dice as solid balls bouncing off each other with some friction. There is no sensible way to do collision detection on polyhedra or do proper edge-edge or resting contacts. It's just way too calculation intensive.
Lighting:
It is a per-polygon lighting model, as any more advanced per-pixel calculations are prohibitively expensive and there is no way to do pixel manipulation in Löve anyways. It is quite a toll on performance, i think half of the time is spent on calculating incidence angles and such. Also shadows are somewhat of a cheat here, you can see that shadows are not cast on another die; only onto the background, drawn as semitransparent polygons.
Rendering:
The only tricky part in rendering is the love.graphics.transform function: it rotates and shears an image until it fits onto any parallelogram. If we had access to the transformation matrix proper, these tricks would not be necessary. What it cannot do is perspective projection: you cannot use big textures. Perspectivic "shortening" can not be done in a single texture, as the perspectivic projection of a rectangle in general is not a parallelogram, but an irregular quadrilateral. If you look at the background closely, you can see that the rectangles are not aligned properly. If you use bigger rectangles, this effect is very noticeable. So it is good for mostly transparent textures, like a number, but not good for "full" textures.
For the physics part I've used
http://www.cs.cmu.edu/~baraff/sigcourse/ as the main reference, you might want to look at it. Maths, lighting and rendering is my own stuff, wikipedia and other random sources helped. The source code is maintained at
http://bitbucket.org/way/dice3d, take a look at some improvements. I am doing some wild experiments though so do not expect anything to be in a working condition
.
I think that doing 3D rendering+physics in Löve is probably not the way to go, this is more of a learning project than some engine that can be reused later. There are some optimizations I can see here and will do later, but in general you should not base your 3d engine on this. However, it is much fun.
way
