quadnodes til collisiondetection

For at gøre det hurtigere, når det skal beregnes hvilke faces, der berøres af en collision, har vi valgt at bruge quadnodes datastrukturen, således at vi kun behøver at traversere en del af alle facenes for at finde frem til dem der påvirkes.
Det gøres ved at checke boundingboxen omkring nodesne, og kun vælge dem som påvirkes.

Det første problem var at få facesettet ud fra en quadnode, således at de kunne tilgåes senere. Det tog noget tid, indtil jeg fandt ud af at det var fordi at faces blev slettet efter at de var blevet givet med som parameter i QuadTreeBuilderen.

Så prøvede jeg at give quadnoden med som argument til boxen, men pga. cyclic references, gav det igen problemer. Så der blev taget en beslutning og quadnoden gives nu med rigidbox som argument i en overloadet constructor. Og der er lavet en accessormethode således at man kan trække quadnoden ud igen.

Week 5 - hybridbuilder

We got the hybridbuilder to work. Some different implementations was tried, including a one were we gave a set of faces in as parameter in the constructor, but that didn't work well. The problem was when we tried to apply the visitor pattern - it couldn't differenciate between the first traverse, when converted the geometry nodes to quadnodes, and the second traverse, when finding the leafs in the quadnode tree (also geometrynodes), and transforming those into BSPnodes.
The solution was to give the hybridbuilder a quadnode as parameter, and the letting the visitorpattern find the geometrynodes and converting them to BSPnodes.

The result, a quadnode, was given to the physics module as a parameter, and that seems to work.

Week 4 -QuadNode

I now looks like the QuadNode works.
We removed the method splitInFour and instead implemented it in the constructor. This seems to have done the difference. Again - this problem must be related to our limited knowledge of C++.

Week 4 - BSP tree structure

Another assignment this week was to implement BSP tree structure. We started by reading material on what BSP trees are and what they can be used for.

At first we tried to implement the choose-dividing-polygon algorithm presented in:

• http://www.devmaster.net/articles/bsp-trees/

Unfortunately we ran into an infinitive loop. Our simple solution was to create a "new" algorithm that only optimized for equal sizes of front and back sets. That is, we ignore how many splits our algorithm creates - this could give some serious performance issues, but at this point we have chosen to ignore this fact and we will fix it if it becomes a problem.

We also had to test our BSP tree implementation, for this we used the guide presented in:

• http://www.aula.au.dk/courses/CGDF07/document/BSP-test.html?cidReq=CGDF07

We had some issues understanding how the drawing should work, but after some hours of trail and error we finally figured out how to properly draw back-to-front.

Another issue we still have is that textures aren't drawn fro BSP nodes (even if we use VisitGeometryNode(...) inside VisitBSPNode). We will ask for help tomorrow at the workshop.

Week 4 - QuadNode and frustum

One of the assignments for this week, was to implement the quadnodes. We had alot of problems with this, and at this point (late tuesday evening) it still doesn't work completely. As far as our testing goes, the splitting of the faces works fine, but at the moment we get af segmentation fault in the VisitSubNodes() method. I'm not sure why, and I have been staring at it for 2 hours now.
The splitting of the faces, is done according to the guide on the webpage, and should be ok.
We have implemented the frustum, and it seems to work, as far as we can test it. When we use debugging function, it looks ok, according to some of the other groups we've talked to.
Because of the seg. fault we are not able to display pictures at this time. If we do not get it to work during the night, this phase has to be regarded as a failure.
I have nothing positive to say right now.

Week 3 - DirectX

How easy is it to transform the Openengine framework from OpenGL to DirectX?
It demands that all the OpenGL-specific pieces of code be replaced by the equivalent for DirectX, this means that all the variables starting with the GL_ prefix should be replaced. Also, the use of glsl-shaders would also not be possible when using DirectX, it should be replaced by cg or something.

Week 3 - Headheadaches

Things that gave headaches this week was Darcs and getting a computer that supported shaders.

We had 3 different Darcs repositories (one for every week), and we wanted to merge these repositories into one. Now this may sound easy, but it turned out to be really complicated since we had a lot of conflicts in our patches. We spent around 4 hours trying to get everything up and running. It was quite frustrating.

Our final solution was to take a clean openengine pull and manually copy in our code. This worked :) Darcs seems to be really bad at merging code together - it's almost lethal to edit in same files/functions.

We all use laptops for development and only one of the laptops has support for shaders. Stibitz was quite full of people, so we were forced to find some other Daimi computers that had support for shaders. At last we found them, but they were Windows machines... Getting OpenEngine up and running on Windows wasn't that smooth, we spent around 2 hours setting everything up.

Anyway, we have Darcs up and running and we have found some computers that are configured for game development... Now we can fully focus on game development :D