Ok, back !
I passed my exams \o/ \o/ \o/
So, today I re-installed my ubuntu to v11.04 and continued Make3D development !
I updated the entire source code with my Sudoku one. It was really simple, everything is extensible and modular =p
http://levak.free.fr/ftp/nspire/Make3D/I added a basic Transformation Screen overlay so that I can use it for any future transformations. For now I support the rotation transformation. It works exactly the same way as on Blender :
Pressing R gives the opportunity to rotate the selected objects in any directions (x, y, z)
Pressing R, then (or later) X, or, Y, or Z, lets us rotate along the X or Y or Z axis
Pressing R, then (or later) Shift+X or Shift+Y or Shift+Z, lets us lock X or Y or Z axis during rotation (thus it is a Y and Z or X and Z or X and Y rotation)
Pressing R, then a number (like 42) lets us rotate of a certain value. We can use (-) symbol
I'm working on the mouse handle for this concept.
For now, I'm working in degrees. Why ? only because I work with a trig table that I initialize only once at the beginning. I'm sure that for educational purpose it is a problem, because we have to use values like pi over 2, over 4, over 3 etc ... and there are not rational values. This is why, for now again, we can't enter values like 0.5 or so. The current architecture of Make3D lets me to use it in a different way.
Make3D renders a scene.
A scene is a basic list of several objects
Each objects has properties (like points, faces, color, origin, position, rotation, scale)
The render engine, every time, rotates the model along its origin, scales it, and grabs it then, rotates the entire resulting points list using the camera rotation. I'm sure you're thinking "he's mad ! he rotates 2 times the model !" >> I've no choice ! look :
When we rotate a model, we rotate it along one 3D point. It is, most of the time the {0, 0, 0} point. But, in fact it could also be the origin of the model !
Now, let's move the model, let's say {1, 0, 0}.
Now, let's rotate the model. Hum ? problem ? What is the rotation center point tho ? {0, 0, 0} ? or {1, 0, 0} ?
Here is the answer to the previous inb4 question :p
So, this way of mind let's me cheat with non integer values of rotation keeping the big optimization of a trig table !
Why ? Because I can store those values as a property, but, when I'm gonna render the model, I will approximate this value as an integer between 0 and 360 degrees. I think I will also take care about the document mode (radiant or degrees).