Not so simple after all

Sometimes one gets excited too quickly. One of my main ideas was that all objects, including the camera and the light, and of course the 3D objects themselves, are treated as an object in the 3D space. Even though the camera may be something abstract and consists only of values, it was my goal to move the object like any other object.

To be honest, I'm not entirely satisfied with the solution yet. An object in my engine consists of several C structures meant to describe the object. One of these structures I call Mesh, and I've implemented the functions for moving the mesh into the C structure.

In the code snippet, this might be clearer. Through this function, one can then rotate the mesh. I want to demonstrate how to use the functions with an example test program. Looking at the functions, you can see what my goal was. The camera in this scene is moved using the same functions as you would move a 3D object. In my opinion, this simplifies the usage of the 3D engine. But why am I still not satisfied? I'm considering whether it would make more sense to have a class called Object3D that provides the capabilities to move an object in 3D space, and then the camera, the 3D object, and the light would be their own classes inheriting their movement properties from Object3D.

Abb. 7 – Ergebnis des Beispielprogramms (Pfeile nur symbolisch und sollen die Bewegungsrichtung zeigen)

Now with objects

In my initial solution approach, I stored the objects needed for data management as structures (struct), and the object manager handled these structure constructions. However, I found that in terms of organization and readability, it made more sense to change these structures into classes. Fundamentally, nothing changes in terms of management through the object manager class, but the classes now have their own methods. This, I believe, makes maintenance and upkeep easier. A simple example program illustrates this better.

They say a picture is worth a thousand words. One could also say that a program code says more than a thousand words. To test the engine, I naturally developed a test program, which I'd like to briefly introduce here and discuss the individual commands.

In this section, we demonstrate how to create a brush. Subsequently, three meshes belonging to this brush are created, as well as a surface, which will later store the vertex data for a cube, and a surface for the vertex data of a pyramid. Please disregard the function calls, as the engine is still under development. Upon closer inspection, it's noticeable that a surface originating from the cube is passed to two meshes. This is acceptable, as it avoids having the same data duplicated in memory. The mesh can access the memory area where the vertices for the cube are stored.

The illustration below might help you better visualize how the objects are now interconnected.

Once everything is ready, the objects can be positioned and rotated, as shown in this code snippet. Again, please pay no attention to the function calls.

Now, within a loop, the objects can be rotated or moved, for example. Another note: The method 'TurnEntity' adds the angle to the current rotation each time it's called, whereas 'RotateEntity' sets a defined angle.

Because for the engine, all objects in 3D space are treated equally, regardless of whether it's light or the camera, it's also possible to interact with any of these objects with a simple function call. For instance, the pyramid can be made the camera. After calling this function, the viewer sees the world from the perspective of the pyramid along the positive Z-axis.

Fig. 10 - Camera viewing the scene

Fig. 11 - The pyramid now serves as the camera and looks along its local positive Z-axis into the scene.