Project two continues where our spinning triangle left off.
Spinning Cube Screenshot
Our first change is I’m using a text file, a ‘plg’ format that defines our model for this project. Remember, our engine only knows how to deal with triangles, to we divide each of the 6 faces in to 12 triangles. Reading in a file means writing a file parser routine. I’m bad at parsing, but this one works if you don’t throw it any curves, it will break fairly easy. Read through the enclosed cube1.plg text file. Ignore the defines at the top and study the rest, it should be straight forward for you. 
This example adds some Window KeyDown event code that lets you change the rotation angles used. As these angles change, try and visualize what will be the outcome before you press your key. I’ve also added some code to the Paint event to show what the rotation angles used are, a simple console like section.
I’ve also moved our initialization code in to its own Method along with the Paint event call.
Let’s look at what is different from the Spinning Triangle project (STp). In STp we created a triangle model from at he TCPolyFace4D class. In this Spinning Cube project (SCp), we are parsing the data from the text file in to a TCObject4D.
objCube = New TCObject4D
mController3D.Object4D.LoadOBJECT4D_PLG objCube, "cube1.plg", vScale, camPos, camRot
In the STp the main drawing code funneled data to our controller via the render list class, the SCp directs the data to our controller via the object4D class. Which interface is better? Probably neither one, we’re are just exploring here in these early examples. Perhaps as things get more complex one avenue will prove itself to be faster. We are not done exploring where and which classes process data.
In my earlier examples, not given here, I used a lot of modules. I like modules when I’m just seeing if functions are going to work OK. But, as things progress, modules just don’t seem correct, so classes spawn from my modules.
Let’s explore one of the functions in the DrawCube call.
mController3D.Object4D.TransformLocalOnly objCube, mRot
This is a call early in the 3D pipeline. This takes our cube object vertices and transforms them by our camera rotational matrix. Just prior to this call, this rotational matrix was created using our Euler angle variables x, y and z. This is what determines how much spin will be applied to our cube each frame (call of the timer). The cube appears to spin faster the greater the angles even though we are executing each frame at approximately the same time, it’s the amount of rotation that makes the cube spin faster or slower.
Next time, we’ll add a call where the back facing faces are not drawn.
