July 31, 2009


Posted in Computer Graphics tagged , , , , , , , , , , , at 11:11 pm by sagito

Hi everyone! After some absence due to the lost of someone who was very close to me, I’m back to posting… This time to talk about a constraining system that I will attempt to implement within the Conspiracy Engine.

I have been having some problems with some DirectX functions, namely GenerateAdjacency and OptimizeInplace. These functions just crash unexplainably in some memory address that is not in my addressing space. Also, neither the DirectX debugger nor the PIX (tried it in despair), not even the Visual Studio 2008 debugger could do anything to show me the problem… So, I analyzed the assembly code, to find out that something inside the mesh is not properly set. However, I don’t have the means to find out what, so I just commented out the functions and moved on until I have the patience to deal with Microsoft’s brilliant lack of information.

So, I decided to implement a constraining system. Now, what the hell is that? Basically a system of something that constraints something to some other something. πŸ˜› Ideally, this will, for example, stick a camera to a travelling object! Imagine a car in a racing game. We want the camera to be able to follow the car along the track as it moves, otherwise the camera would just be left in the beginning of the track.

It is important to say that… I never, ever, whatsoever, tried anything even near such a thing… My basic idea so far is really making an object stick with other… You could say that this can be achieved using hierarchy. Yes it could! However, I think some more flexibility is desirable… For example, if I want to attach a gun to my vehicle, I would probably like to place it in the door or in the roof… I need something that allows me to control its position and the constraining system will hopefully give me that kind of offset.

I know that there is a huge number of possible constraints to be implemented. However, I will stick to this one at the moment, but I will create a solid enough structure that can be expanded to some other constraint types further on… For now on, I will be keeping you posted! πŸ˜‰


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 8, 2009

Sky is not the limit!

Posted in Computer Graphics tagged , , , , , , , , , , , at 9:40 pm by sagito

After a short break due to WordPress maintenaince, I’m back to post about the new stuff that I implemented in the Conspiracy Engine! It now features skybox support, collision detection and a very complete particle engine!

Implementing a skybox was pretty easy. For those of you that do not know what a skybox is… Well, it is pretty much that, a box that represents the sky. So, what about that, why can’t it be just a cube with some texture mapped like every other object? Because unlike other objects, the skybox must move with the viewer… I.e., the user cannot get out of the box as the skybox itself must move with the camera. Just like a person can’t reach the horizon! So, how can one implement a skybox? Pretty easy, you get the view matrix (through IDirect3DDevice9::GetTransform(D3DTS_VIEW, &view);), reset the last row to 0.0 except for the last value and set the new view matrix. After that, the world matrix must be set as an identity too in order to remove any unwanted transformation. Then we can render the skybox! After rendering, we put back the old view and world matrix.

For collision detection, DirectX already provides some very useful functions that automatically calculate the bounding box and sphere for a given object! After that, I just took some optimization measures and converted the bounding box to an axis-aligned oriented bounding box (see http://www.toymaker.info/Games/html/collisions.html for more info). Then, the objects are tested for collision… If a collision happened, it is propagated through a chain of responsability to some entity that handles the event or discard if no one does…

Finally, the particle system was based on a tutorial from CodeSampler (http://www.codesampler.com/dx9src/dx9src_7.htm). The system described in this tutorial is awsome and very complete! Also, the code is very well structured and commented, so it was pretty easy to implement this too.

To end this (already long) post, here is an image of the engine with the skybox and the textured cube:


July 7, 2009


Posted in Uncategorized tagged , , , , , , , , , , , , at 12:06 am by sagito

After a long, long day of work, I’m proud to announce that the Conspiracy Engine now feature textures (finally)! Well, textures do not use to be such a pain, why did it took so long this time? The answer is quite simple… When exporting the object data, 3D Studio Max exports the (X,Y,Z) vertex data and the (U, V, W) texture coordinate data. However, I was surprised to see that I had 8 vertices in my object and 12 sets of texture coordinates… Well, this made sense, because a vertex shared between edges may hava different texture coordinates along each face!

The problem is that 3DS does not keep any kind of relation between one vertex and its texture coordinates. So, we must first ask the face which vertices and which texture coordinates it uses and only then attempt to relate both these kinds of vertices. I could have done this the easy way by just ignoring repetitions of vertices and letting DirectX handle the optimizations. Of course that I chose not to…

So, I had to create two auxiliar data structures to aid me: An Hash Table (with customizable rehashing) and a Pair. With the Hash Table I was now able to set keys for each vertex individually, thereby removing repeated indices and vertices with ease! The Pair was just a helper utility that I used to handle some data more easily. However, I think that these structures will prove worthy in the future, as they did now! πŸ˜€

Well, here is the actual result from all this work:


Tomorrow I will be working with collisions, although that should be a pretty simple matter to handle… πŸ˜‰ As promised, I will be keeping you posted!

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… πŸ˜‰

Conspiracy Engine First Render!

Posted in Computer Graphics tagged , , , , , , , , , , , , , , at 12:23 am by sagito

And finally, here it is! The Conspiracy Engine first rendered screenshot! Well, it consists of a single teapot lit by diffuse and ambient lighting using Gouraud shading, some text on the screen, one camera (so far), and two lights (one ambient and a point light). It is not something amazing, but this is only the first nice render screen of this engine! And what is most impressive is that this is not a standard DirectX teapot, but a 3DS Max exported teapot, which was loaded using my 3DS Exporter and Importer, presented below. I changed the code a bit to support materials and textures and also to optimize it a bit… Please note that the normals are still not being saved directly, so the lighting can look a bit awkward…

Here is the screenshot of my new engine:

Conspiracy First ShotConspiracy First Shot

Feel free to comment! πŸ˜€

June 30, 2009

X File Format Dying?

Posted in Computer Graphics tagged , , , , , , , , , , , , , , at 12:13 am by sagito

As some of you should know, .X files were the Microsoft “standard” format for three-dimensional model and animation within DirectX. These consisted of binary or ASCII files with some a kind of scene graph describing a specific scene. Although they were not very complete, this format along with the helper functions such as D3DXLoadMeshFromX were always a major help while developing simple games or applications using DirectX.

Of course that almost every major company developed their own formats, and in that perspective, the .X file format was quite useless… But what about the small developers? Or the people who are learning DirectX? Will they have to start learning parsing techniques in order to read some other file format? Or will they have to learn some scripting language like MaxScript to export their own models?

As a matter of fact, as far as I know, Microsoft never said anything official about this matter. However, everyone who uses the DirectX SDK may have noticed that since November 2007, support for writing files in the .x file format has just disappeared. Also, what happened to the DirectX Mesh Tool? It was replaced by the DirectX Viewer which is buggy, slow and to be honest, quite useless…

Without .X file format, what can small developers use? Well, for one side we have the .FBX file format. As the .X file format it has a binary and an ASCII mode, so that could be an option… But there is so many useless code inside that I doubt I couldn’t get a working parser for this format in less than one week… Also, the binary mode is a proprietary (undocumented) format from Autodesk…

If this is really Microsoft’s decision, then I’m terribly sorry… Really… If this is just a matter of giving less importance to the small developers… I’m even more sorry… As I mentioned before, I will try to develop an exporter for 3D Studio Max on my own… If it gets anywhere near good, I will post it here… At least, I hope that can help someone!

June 29, 2009

It lives!

Posted in Computer Graphics tagged , , , , , , , , , , , , , at 11:55 pm by sagito

The Conspiracy engine is already rendering stuff! πŸ˜€ Yesterday I managed to get a teapot (the CG Hello World thing) on the screen! Also, I have implemented input with DirectInput. To be quite honest, I was quite afraid of doing so because the DirectInput’s usual approach requires polling. Although I could wire it up to the WndProc and receive events through there, this is quite painful and not documented… However, the performance of DirectInput is nevertheless stunning at the moment!

Also, the Memory Management Layer (MML) has proved itself very useful as everything is being released as it should, obtaining a great memory performance too. Now I’m developing an importer of 3D files, exported directly from 3D Studio Max. However, I did not want to rely on Microsoft’s .X file because this format is now marked as deprecated and as far as I know, there is no substitute so far… So, I’m trying to build my very own MaxScript exporter for 3DS Max! So far it only exports geometry data, but I will try to make it export materials, textures and so on very soon! Also, I would like to make it export skeletal animations, but that does not seem easy at this moment…

For those of you who are interested or cannot find any example of how to do this, here is my (rather naive yet) Β approach (the code is poorly structured, I didn’t had the time to organize it yet, I’m sorry):

–Start by selecting every darn thing
select $*

out_name = ((GetDir #export) + “/test.cmf”)
out_file = createfile out_name

–For every one of them
for obj in $ where superclassof obj == geometryclass do
–Convert every single one of them to poly
p = convertToPoly(obj)

–Get the number of faces
format “Name: %\n” p.name to:out_file
polyop.setFaceSelection p #all
faces = polyop.getFaceSelection p

format “Faces: %\n” faces.count to:out_file

–For every face
for i = 1 to faces.count do
–Why is this boolean?
if (faces[i]) then
faceVerts = polyop.getFaceVerts p i

if (faceVerts.count == 4) then
v1 = polyop.getVert p faceVerts[1]
v2 = polyop.getVert p faceVerts[2]
v3 = polyop.getVert p faceVerts[3]
v4 = polyop.getVert p faceVerts[4]

format “% % % %\n” v1 v2 v3 v4 to:out_file
outstr = (v1 as string) + ” ” + (v2 as string) + ” ” + (v3 as string) + ” ” + (v4 as string)
print outstr

More news will be coming very soon πŸ˜‰

June 27, 2009

Conspiracy Engine is born!

Posted in Computer Graphics tagged , , , , , , , , , , , , at 12:41 am by sagito

Hi again! My new engine is already moving… And in quite different directions at the same time! I have implemented a window manager which basically is responsible for creating a window and saving its internal state and a video driver which fires up DirectX and provides basic window painting features – i.e.: paints the window background with a chosen colour! That is very simple indeed, but from my experience with DirectX is a nice way to see if everything is working fine…

However, I’m also evolving it in some different components as I have already built an Observer Pattern Architecture. So basically, any object can now be an observer of any other object which declares itself as a subject! Events are then handled by a Mediator which notifies every one it should. How does this work? Pretty simple, the Mediator registers every subject and every observer which wants to listen from that particular subject. Then, when the subject has some new information, it informs the Mediator, which informs every observer interested in that subject! I believe that this will be a great way of passing events and notifying entities. Also, the Observer, Subject and even the Mediator classes can be easily extended in order to create or provide further specifications for this information flow.

Besides this, I have also implemented an utility class, which follows the Singleton pattern, and a custom exception handler which has already proven to be one of the greatest additions to the engine. Finally, in order to have a better memory management, every class inherits from an IObject interface, which forces its children to implement a drop method. This method is used for clearing everything from memory before leaving the program. This way, the engine becomes much more organized and clean I hope!

I will be having more news, very soon, I hope you are liking! πŸ˜€

June 25, 2009

New graphical engine!

Posted in Computer Graphics tagged , , , , at 9:28 pm by sagito

Yep, it is now official… I’m working on a brand new game engine! Why another, after the Enoch saga? Because Enoch lacked lots of features, like a visual editor… I mean, it was just a bunch of code, that althoguh very functional… Was quite useless for anyone who didn’t wan’t to understand lots of code…

So, learning from my mistakes (and I mean a whole lot of them), I’m now back to business! And at this point, I’m committed to get something that really works, and this time, for once… It will become a game… Or I will at least give my best to ensure that it will! πŸ˜€

I will be posting some engine related stuff here, so keep visiting! πŸ˜› And now I should have some more time as I twisted an ankle and I cannot really move, so be expecting quick updates… πŸ˜‰