Thomas' Kamaelia SoC Blog

Eliminating the shared state between components

2006-07-24T02:17:00.000+02:00

I have made a draft of how I think the 3D components could interact in a more organised and clean way than it was before. It relies on displaylists and opengl picking.

Objects now do not draw themselves directly. Instead, they compile their contents into a displaylist which then gets sent to the displayservice. This way the displayservice is able to draw the objects all at once and without being dependent on the linearised scheduling of all the components. A nice side effect is that displaylists also make things faster. For dynamic objects a component could recompile its displaylist every frame. I'm not sure how well this will work though.

Being able to draw the objects at any time and as often as needed, also enabled the use of picking for event processing. It works by defining a point (mouse position) and drawing the scene in GL_SELECT mode. All the objects which were drawn near the specified point can then be determined. The line/OOB intersection with every object is not needed anymore.

The draft is in my Sketches folder in 3D/playground/. A working example is included in the file SimpleCube.py. It shows that it works but it could not be less spectacular (cubes again).

Restructure

2006-06-29T23:57:00.000+02:00

My co-mentor, Matt, gave me some interesting feedback about my work. It made me think about how I could restructure my current code, to make it more clean. It's not only about code formatting and commenting but especially about how the components interact.

There is also a number of issues that I might not be able to solve easily with the current approach. For example, currently all the objects draw themselves just when they get scheduled. This works fine at the moment but only because the execution is serialized by the Axon scheduler. How the intersection tests are done is also quite impractical.

I already have a few ideas how to improve the current structure. But this time I will try to come up with a well planned framework instead of just trying things. I will put my main focus on the restructure when I'm back from my holiday.

More widgets

2006-06-29T23:44:00.000+02:00

I have created two new widgets, a scroll bar and a progress bar. The bar can be dragged and a click on the arrows moves the bar by an specified amount (just the usual behaviour). The intersection test is somehow inaccurate for the right arrow, seems to be an issue with the ray/OBB test.

The widgets are both coloured like the buttons (a bit boring, I know ;) ). The example shows a scroll bar connected to a progress bar.

Recent progress

2006-06-29T20:30:00.000+02:00

Lack of time in the last days kept me from updating my blog. Here are my latest advances:

Pushbutton component
Linear interpolated paths
An image viewer example program

The first image shows the buttons in action. Might not look too impressive on a static image, but it is quite fun to use them (the turn 360° when pressed).

The second image shows the image viewer. The buttons can be used to browse through the images.

Pygame components on 3D planes

2006-06-18T22:30:00.000+02:00

After resolving the size issue with pygame components (now a seperate surface with power-of-2 dimensions is stored for each component), I managed to get pygame components to display on 3D planes. This is done by PygameWrapperPlane components. One of them has to be created for each pygame component. It sends a WRAPPERREQUEST to Display3D which returns the needed data to draw the corresponding surface and then it is just displayed like in TexPlanes.

The tricky part was to get input events to the pygame component. While I could easily determine the point of intersection in 3D of the plane the surface was drawn on, it was not so easy to get the corresponding 2D coordinates of the surface. After a while I realised that these coords could be determined by calculating the dot product between the point of intersection and the edge vectors of the plane. This is true because the dot product is equal to the cosine of the angle between two vectors. The results then get scaled to the surface size and sent to the pygame component.

To distinguish between movement and pygame component interaction, a movementMode flag now gets inserted in events sent to 3D objects. It is true when the CTRL-key is pressed.

The appended picture shows the current example which is included in PygameWrapperPlane. To test the mapping I have created a simple pygame drawing board component which is called MagnaDoodle (bottom left). The example also shows two Ticker components, a Button and a SimpleCube.

Correct dimensions of Pygame components

2006-06-11T19:51:00.000+02:00

I have modified Display3D to show pygame components in their requested dimesions. This is done by making the surface dimensions the next power of two but showing only the actual component area. But unfortunately, since the mouse collision tests are done inside the components (e.g. button) and against the surface size, this causes a problem.

Maybe it would be a better approach to use correct sized component surfaces and blit them onto a power-of-2 surface before it is used as texture.

Texturing & Pygame components

2006-06-10T16:23:00.000+02:00

I have created a new component being able to display textures on a plane in 3D. This was actually quite easy, after loading an image I simply draw a plane as usual and additionally specify texture coordinates for each vertex. I have not implemented intersection tests for planes yet but for now it is sufficient to use a thin bounding box. So the object can be moved as usual.

The next obvious step for me was to handle pygame components. I wanted to be able to use them without any need for modification, so I modified Display3D to be compatible with PygameDisplay. The method overridePygameDisplay() is used to replace the PygameDisplay singleton by an instance of Display3D. This way components request surfaces using PygameDisplay without knowing that they are actually interacting with Display3D.

Since I used surfaces as source for the textures anyway, I just had to set up a texture for each pygame component and draw it on a plane. The 2D coordinates get converted to 3D coordinates on the far Plane. To have the pygame comps on top of everything, depth testing is deactivated before drawing them. For mouse handling, I just copied code from Pygamedisplay.

An annoying limitation in OpenGL is that texture dimensions need to be a power of two. Otherwise texturing is really slow. I currently solve this by simply magnifying the dimensions of the created textures to the next power of 2.

The example picture shows a rotating TexPlane showing the kamaelia cat, a moving cube, 3 buttons as well as a Ticker. The example only works with newer pygame component which send REDRAW messages.

Intersection tests

2006-06-04T10:46:00.000+02:00

I was able to realise intersection tests with my 3D objects. I needed this for mouse interaction, because oviously it is needed to know if the mouse position matches the objects projection. This is not as easy as in 2D because it is actually not known where the object is displayed on the screen (due to the perspective view). Therefore a ray representing your mouse position has to be intersected with the object, currently represented by a bounding box.

First, I needed to get the parameters of the ray. I knew that the origin would be on (0,0,0) because this is the position of the viewer. Getting the direction was somehow more complicated. I figured out that the ray should be pointing at the projection of your mouseclick on the far plane. To shorten a long story, here is the code used for the inital calculations:

self.nearPlaneDist = 1.0
self.farPlaneDist = 100.0
self.perspectiveAngle = 45.0
self.aspectRatio = float(self.width)/float(self.height)
global pi
self.farPlaneHeight = self.farPlaneDist*2.0/tan(pi/2.0-self.perspectiveAngle*pi/360.0)
self.farPlaneWidth = self.farPlaneHeight*self.aspectRatio

and the actual ray is calculated this way:

# project mouse click position on far plane
xclick = float(event.pos[0]-self.width/2)*self.farPlaneWidth/float(self.width)
yclick = float(-event.pos[1]+self.height/2)*self.farPlaneHeight/float(self.height)
for obj in self.objects:
zhit = obj.intersectRay(Vector(0,0,0), Vector(xclick, yclick, -self.farPlaneDist).norm())

Having the ray, I needed to realise the intersection. For this I found an algorithm in "Real Time Rendering" (T. Möller, E. Haines) which I implemented as method in Object3D. It has 2 parameters (origin o, direction d) to specify the ray, its return value is 0 if no intersection was detected or the distance of the origin to the nearest point of intersection. This is handy if more than one objects are intersected, to find out which one was the nearest.

The output of the current test program looks just like the image shown in the last blog entry but now the cubes change their rotation direction if you click them. Additionally the distance of the intersection gets printed on the console, like this:

HIT! ( 19.4144860387 )
HIT! ( 14.6633880786 )
HIT! ( 10.6484258135 )
HIT! ( 21.4056345149 )
HIT! ( 16.9268217722 )

The test program is viewed by running Object3D.

Basic framework

2006-06-01T11:36:00.000+02:00

I have created a basic framework for 3D display. Currently it contains 2 classes:

Display3D provides a display service similar to PygameDisplay in 2D. At the current stage all it does is to initialize OpenGL. It will later be responsible of processing input, managing display lists, etc.

Object3D is a basic 3D component. It will be a basis for future components. It knows about its orientation and draws itself after setting the correct modelview matrix.

I have created an example program to show multiple 3D objects next to each other (cubes again :) ).

Getting familiar with OpenGL again

2006-05-26T15:51:00.000+02:00

I have coded a small 3D "Hello World", it shows a rotating cube using OpenGL. Really straightforward. The next thing will be the same using togra.

Mini-Axon

2006-05-25T20:32:00.000+02:00

I have just completed my own Mini-Axon. It is really impressing how this powerful system can be implemented so easily. Great tutorial, btw.

The Opening

2006-05-25T18:33:00.000+02:00

Here I will host the project log of my Summer of Code 2006 Kamaelia project. It is titled "3d widget framework" and will mainly be about exploring the use of 3d graphics for Kamelia. I plan to implement several components as well as a few example programs to collect experience about what is useful/interesting. I am quite sure this will be a lot of fun!

Cheers, Thomas