July 26, 2009

Octree in DirectX

Posted in Computer Graphics tagged , , , , , , , , , , , , , at 11:27 am by sagito

Hello everyone! Back to some news from the Conspiracy… 😉 This time I’m implementing a feature that is quite new for me. An octree! Ok… Wait… What’s an octree? Well, an octree is basically a technique for dividing the drawing space. You start with a huge cube which surrounds the entire scene. If there is something inside it, then you subdivide that cube in eight smaller and identical cubes. Then, for each of these cubes, we must check if there is something inside them, if there is we subdivide them again, and so on…

Ok, now… Why is this so useful? Lets consider rendering… It is not necessary to render everything that we don’t see (because its behind us for example). This seems quite logic to me. But, the DirectX backface culling and occlusion system should be capable of doing this, right? Yes and no! In a matter of fact it really does not render the objects that we can’t see… However, it sends them to the graphics pipeline, executes a draw and only checks if they are visible afterwards. Only at this moment it decides if it really sent to the screen or not. With an octree, we are actually able to avoid such a thing, because we just don’t sent the objects which belong to an octant that we cannot see to the pipeline, avoiding some unwanted overhead.

Another example is the picking! Why try to perform picking on something that we cannot select? It is a heavy operation and we want to be able to ignore such operations if they are unnecessary!

However, there is a small problem, at least, with my implementation. I can reach 6 iterations of depth in an admissible time… Seems that these are few iterations, and maybe they really are… But if we think it through, each subdivision creates 8 space divisions. So, for 6 iterations, that stands for 8^6 = 262144 divisions (maximum). After doing the maths, this seems quite acceptable now… 😛

So, standby for new updates, as they are coming fast! 😀

July 5, 2009

New Stuff!

Posted in Computer Graphics tagged , , , , , , , , , , , , , , , , , at 10:58 pm by sagito

I’m bringing you some news from the Conspiracy Engine! Since yesterday, I have been able to implement three new important things in the engine. The first is a TAL (Top Abstraction Layer) that manages the engine almost totally. This was implemented through several Adapters and a Facade pattern. It is working nicely now, and most of the code that was in the main.cpp could be hidden under this layer now, simplifying the whole thing. I will try to create a configuration (scene-graph like) file that will be loaded by this class and automagically presented. The whole engine is already prepared for that, it is just a matter of putting things together.

I have also implemented geometrical transformations. Due to the overall organization and architecture of the engine, this was much quicker than I expected and took only about fifteen minutes to complete.

Finally, I have managed to get the Picking-related stuff working. Picking is always a big headache because it envolves a lot of maths (matrix inversion between three vectorial spaces, conversions, etc), and also because it is a HUGE design problem! Why? Well, as some of you should know, Picking is the possibility of selecting an object in a 3D world through the click of the mouse. However, the mouse “lives” in 2D space while the scene is usually 3D. So, the mouse coordinates are caught up in the Input layer and must be propagated to the Object Rendering layer in order to check if some object was intersected by the ray generated by the mouse click. As you can imagine, crossing several layers many times and returning to the interface is a quite tough design job…

However, my approach tried to obtain not only quality in the design (without violating any abstraction encapsulation) and also performance. As I already need to go through every object while drawing, I figured that I could use the drawing cycles to perform picking. As every function returned void at the time, they now return the set of picked objects! This way, I shared as less code as possible (in a Aspect-Oriented Programming way) and still managed to obtain the most of the engine performance!

Now I shall work in the textures. There is not much work left, so that when I finish some last things, the game should be born! 😀 Promise that will keep you posted… 😉