ダニエルの冒険

Yakumo is now listed as a service on the DNS-SD (a.k.a., Bonjour) homepage!

I have open sourced all of Yakumo’s source code under the Apache License v2.0 (ALv2).

Yesterday I went through a list of OSI-approved open source licenses, and found some a little too open (MIT and BSD) and others a little too restrictive (GPL). I found ALv2 to be just the right scope for what I want. Have a read through the licenses if you want to see the difference. It should be pretty clear how different they are from each other. One thing I like about ALv2 is that it enforces the distribution of a “NOTICE” file with the licensed work. Seems to be a fair, reliable and flexible method of attribution.

Apache.org also has a nice guide on how to apply ALv2 to your own project.

I replaced the background image for the blog. If you’re still seeing Tokyo, refresh the page.

I decided to change because, as much as I love seeing Tokyo here, it doesn’t make the text easy to read. It might just be because of the translucent background for the text, but I decided to go with a simple blue gradient. Everything I ever design ends up blue anyway, so might as well stick with the theme.

Here’s a link to the new background.

Much easier on the eyes, I hope.

A piece from today’s report writing.

You probably can’t see the full width of the images within the post, but if you click an image you should be able to see it fully.

To position the camera, a target and an origin are decided. The target is the position of centre of the player character. The origin is the camera’s current position. The origin is then scaled so that its distance from the target is 1.5m.

In order to prevent other objects from getting between the target and origin, obstructing the view, a linear cast (or “shape cast”) is performed. This is a feature of Havok Physics and to explain how it works, first I will explain how I attempted to solve this problem using a simple raycast.

Figure 2a shows an origin→target vector without any obstruction. By casting a ray from the target to the origin, obstructions can be found and the vector clipped to a point where the obstruction is no longer in the way. In figure 2b an obstruction has been found by a raycast, and the origin will be moved to the point marked with a red X.

Figure 2: Detecting collisions with camera vectors.

This works well, except in the case where there is a very small angle between a polygon close to the origin. This often happens if the player character moves along a wall, for example. In this case, it is possible for the wall’s presence to have been detected by the raycast, but some of the wall’s surface falls between the origin and the near clip plane. This is illustrated in figure 3. In this case, the origin has moved away from the wall (and the raycast therefore reports there is no obstruction). However, part of the polygon (i.e., the surface of the wall) is behind the near clip plane. More of the same polygon is beyond the near clip plane, inside the viewing frustrum’s volume. Therefore there will be a visual artefact in the form of being able to see through the part of the polygon behind the near clip plane. In figure 3, this area which will not be rendered is shaded in red. The origin is marked as an orange point, and the totally unobstructed raycast, coming from the target and ending at the origin is green.

Figure 3: A demonstration of how a simple raycast-based camera vector clipping can cause artefacts.

A raycast can be thought of as a shape cast where the shape is a single point. Linear casting allows you use any shape at all though, instead of just a point. For example, a cube can be “swept” through 3D space, and any collisions with objects will be reported. (Please note that though collisions are detected, they are not resolved and the simulation is not affected by the cast.)

If one makes a sphere, with a radius equal to the distance between the camera origin and the near clip plane, this proves to go a long way to resolving the artefact mentioned above. In figure 4, this sphere is linear casted in place of the raycast. The sphere will collide with the wall, and the new position of the origin can be calculated from the returned contact point like so:

contactPoint.position + ( contactPoint.normal * sphere.radius )

Figure 4: Using a shapecast to clip the camera’s vector.

Figure 4 shows the normal as a purple arrow. As a normal is a vector normalised to a length of 1, this means that the near clip distance must be about 3 or 4 metres. However, the normal’s length was shortened for simplicity of illustration: please note that the near clip distance is set to 0.01m in YakumoDemo, which means that the resulting sphere is 20cm in diameter.

Looks like someone else picked up on the idea I’ve been working on for my FYP and is making it into a commercial product.

I’ve finally found a way of getting rid of the extra mouse and keyboard on my desk: Synergy!

On Danny Choo’s blog I was reading about his desktop set-up. He has about three macs sitting in front of him, but only one mouse and one keyboard. He wrote that Teleport is the software he uses to do this.

A quick google led me to Synergy, which seems to do more-or-less the same thing, but across multiple platforms. It’s open-source, and really feels open-source (unfortunately), but does the job. On Windows I have the server set up with two “screens”: Honeybee and Nanashi. Honeybee is Vista PC and its “screen” is made of two monitors. The left side of the screen is set to trigger a transition to the right-hand side of the nanashi screen, which is my laptop. This means that when I move the mouse off the left side of the Windows display, the mouse appears on the right of the Mac display. Keyboard focus, of course, follows. Interestingly, the media keys on my keyboard don’t seem to be captured. This is a good thing because I want them to control iTunes on Windows even when I’m working on the Mac.

Tilmitt saw the set-up and didn’t immediately realise that anything special was going on, since I already had the two Windows screens working together. After a few seconds the penny dropped with “Ah!! Different operating systems!!!” Just goes to show how well it works.. it’s just the way it should intuitively behave.

Last night I connected the Mac to the TV downstairs and never turned it off. This morning I noticed that the mouse was still going off the left side of the Windows PC, and sure enough it was moving into the Mac’s display downstairs. I put it back on the left side of the PC’s left monitor and the mental mapping was back in sync with the setup

Yesterday I talked about how I cut a lot of useless operations in my code. In fact, after all my work yesterday, the codebase is 160 lines shorter!

Last night I was thinking of a few places where things aren’t so snappy, and realised a point where I was overdoing multithreading. What I was doing is taking collision callbacks and putting them onto a job queue do be processed by my own worker threads. In fact, I’m also using Havok multithreading as it is and it’ll already queue up Havok-related operations to be processed by its own worker threads. Removing the useless “threaded” collision callback code meant I removed 4 files from the codebase and dropped another hundred lines or so. And it runs faster!

So in a few days of work, I’ve written -260 lines of code. And I just reminded myself of this old Apple story.

I feel pretty bad talking about “faster” and “snappier” without having my profiling set up yet. I’m on the Havok forums right now trying to get some help with getting timers set up. For some reason, my own Havok timers aren’t working, but Havok’s internal ones are. … But their code ought to be the same as mine so surely it’s an all or nothing thing.. hum.

I’m trying out a new template now. It’s Aeros 2.0 with my own background. To create the image, I took one of my shots of Tokyo, resized and chopped it 1680×1050 (sorry all you people with 1920px wide monitors! ), and saved to a JPEG of 100kb.

Motivations for the blurring:

• Lots of sharp lines that aren’t part of the layout/content overpower the design and make it difficult to focus on what’s important. (Yes, my writing is important.)
• Not sure how successful the effect is, but I like the idea that the city is in the background, but the reader’s vision is focussed on the content in the foreground.
• Blurring reduces JPEG compression artefacts.

As a side-note, my good friend Stefan has started a new blog, Death By Recursion. The name sums up the focus of the site: death metal and coding/security. Though there’s some speed metal I enjoy (Sex Machineguns and Dragonforce, thanks to Guitar Hero of course), I’ve never been able to put up with the death growl before getting tired of it after one track, but the security articles are really worth reading, even if you only have a passing interest: Stef has kindly written everything very accessibly (which I’m assuming has a lot to do with his Google AdSense get-rich-quick scheme).

Until now I had avoided globals in my code, which I think is a good idea in general, but when I realised how many times so many of my classes were being access through their singleton accessors, I decided enough is enough and a few regex find and replaces later my code is set up with globals instead.

I don’t know why I didn’t have the confidence to do it before, now that I look at it. I should be saving a hundred or two calls every frame, or maybe about 10,000 every second!

Goodbye, YkdGraphicsSubsystem::getSingletonPtr(), hello gGraphicsSubsystem!!

Yesterday I was having trouble with the iPod accelerometer’s response time on the PC. I found it laggy to the point that it wasn’t really usable, and then realised that since I got rid of any threading on the iPod side, the whole thing blocks while it receives the image to display on the screen (about 50kb per image).

I came up with a way of having one thread receive the image, then set a flag for the main thread to check periodically in its main loop (with an NSTimer), and then receive the next image once the flag was reset by the main thread (indicating it had been consumed and put on the screen).

Before I started hacking into that, it occurred to me that I was sending a UDP datagram to the iPod telling it that an image was on the way first, and then transmitting the image over a TCP stream. I realised how silly that was, swapped the ordering so the datagram came after the image data stream had been written to the TCP socket, and in its new role as indicating that an image had been sent (as opposed to indicating one was about to be sent), the lag disappeared! Turns out that once the data is ready to be retrieved right away, the blocking recv() call in the main thread isn’t anything to be worried about! Hurrah!

I’m just after getting back into Yakumo development and have stabilised the networking a little. It’s nice to come back to the codebase with fresh eyes: I spotted a couple of problems right away.

The last few days, apart from Rachel, Kevin, Olivia, and Satomi’s birthdays, have mainly involved studying databases for the midterm on Wednesday (11th), and trying to pull something together for the FYP draft report (due on the 12th).

Incidentally, if anyone knows anything about database normalisation, please let me know.