Raytracing: second shot

Alright, this is propably the last shot I’m taking on raytracing. I implemented some pretty neat features. First of all: reflection:

The left picture shows the image without reflection, the right one with reflection enabled. Actually reflection is pretty easy to implement. All we need to do is recursivly trace the reflected rays.

The second feature is also pretty neat: anti-aliasing. Actually that also is not too difficiult to implement. I implemented the most simple way of doing anti-aliasing which is supersampling. The following picture shows the difference between un-aliased and aliased rendering:

To get a better impression on what anti-aliasing does, the following three pictures show the same image with no antialising, 2 times, 4 times and 16 times anti-aliasing:

Of course the changes are in the SVN. The username, as well as the password, is guest

Raytracing: my first shot

After revisiting the Google talk about splines and fractals I had the idea to do this in three-dimensional space by using quaternions instead of complex numbers. It turned out that it wasn’t utterly difficult to render a simple three-dimensional Sierpinski gasket (or Menger-Sponge) using PovRay. At least installing PovRay on my Mac took more time than writting the script.
While fuzzing around with PovRay a crazy idea came to my mind: why not write my own ray tracer. Of course that would only be the simplest possible as I only wanted to get a rough understanding on how this stuff works. After doing a bit of research it turned out that it shouldn’t be a too difficult task. Hey, this is one of the excercises in every “Computer graphics basics” lecture.
Three hours later I had a rough shot, but somehow my maths for calculating the rays was wrong. The day after, a friend of mine and myself went to a maths professor at my University and asked him if he could have a quick look at the formulas. His explanations were (as always) very insightful and simply brilliant. With the ideas he gave us we went on to get the missing bits done. And 4 more hours later we had a working ray tracer. (The sierpinski gasket was not rendered by my ray tracer, but I can’t figure out how to exclude images from the WordPress gallery).
Of course after 7 hours of work the ray tracer is far from being perfect. There are a few neat features missing (which might follow) such as shadows, reflection and radiosity (which would really be a big task). Also the maths concerning the projection plane are not totaly right. We should rather introduce a coordinate system transformation to get this done than hacking things together as it is right now. All in all it was a lot of fun to write that thing. If you want to have a look at the source code, check it out here (username: guest, password: guest).

Simulating fluid dripping on a chain

This is some little afternoon project I did today. It’s basically a chain moved by a rotating cylinder. The simulation really respects friction, forces and is pretty close to reality except that the “fluid” is not really fluid but are really really small particles. Everything’s written in Java using JBox2D and Processing (by utilising the testbed, actually modifying the chain example). What’s cool is that basically every parameter can be set. Those parameters are:

  • chain ball radius The radius of an element within the chain. This influences the speed of which a ball becomes fully colored.
  • amount of chain balls The amount of balls on the chain (this can be set to close or wide, which may cause the simulation to be unrealistic
  • bearing radius The size of the bearings
  • bearing distance The distance of both bearings. Together with amount of chain balls this modifies the distance between the balls
  • motor speed The speed of the motor. Basically one could also modify the motors tourge, but it’s set to 10kNm per default so that it doesn’t matter
  • injected particles per second
  • particle size This radius directly changes the speed in which the chain balls become “colored”. Actually the percentage (ranged from 0..1) is calculated using the following equation

        \[\frac{2}{4\pi\cdot r^2} \cdot \vert P_{recv}\vert \cdot \mbox{size}(p)\]



    is the radius of this chain ball,


    is the set of received particles for this chain ball and


    is the particle radius

  • particle velocity The norm of the velocity the injector produces. The velocity is then

        \[v\cdot \begin{pmatrix}0\\-1\end{pmatrix}\]

This was a nice little project and I’m looking forward to play around with this stuff a little more (once I’ve finished playing around with my graph theory studies). Below is a video of the simulation with the following values set:

Parameter Value
chain ball radius 0.5 cm
amount of chain balls 50
bearing radius 5.5 cm
bearing distance 20 cm
motor speed 1.5 cm/s
injected particles per second 50 particles/s
particle size 0.01 cm
particle velocity 1 cm/s

FastSilver is the new QuickSilver for Eclipse

Being inspiered by QuickSilver (totaly awesome software, basically a Mac without it is pretty much useless), I wrote a small plugin for Eclipse providing similiar functionality. For those who don’t know QuickSilver, it allows you to start applications or trigger commands using nothing but your keyboard. So why would I want this within my Eclipse, you may ask. Simply to save the time it would take you to grab your mouse and use the menu. FastSilver basically takes all the commands available within Eclipse and makes them available using one single keystroke which is Cmd-6 per default. This binding can be changed in the settings.

Again the code is available thru SVN, or if you’re solely interested in the binaries, here is the update site. For both (Update Site and SVN) the username and password are guest. Screenshots and eye-candy will follow as soon as my WordPress installation works fine again.
Update: my upload works again, so here are the screenshots. The first one shows FastSilver in action:


The second one below shows the preferences dialog where you can change the keybindings to trigger FastSilver:

Today Eclipse RAP blew me away

Ok, I know the killer argument for Eclipse RAP is that using this framework one can achieve up to like 95% code reuse (yep, 95%). These days I’m developing an Eclipse RAP based application, which I tried to convert to an Eclipse RCP based one. All in all it took me 7 minutes to do so. I mean, hello, 7 minutes … that’s like no time. Transforming a full blown web application into a rich client in a glimpse of a second is just awsome.
Alright, I already hear the naysayers: “That surely wasn’t a pretty sophisticated application”. And indeed it wasn’t, BUT the steps necessary to do this transformation were pretty straight forward:

  1. Checkout the application plugins from SCM
  2. Resolve unresolved dependencies (basically remove the RAP dependencies and add those of plain Eclipse)
  3. Change the SessionSingleton to a “normal” singleton
  4. Replace the EntryPoint with a default RCP application implementation

That’s basically it. All in all this was a pretty amazing experience which let’s me almost forgett the minor hassles I had with RAP (like text boxes doing what they want when being in a higher latency network – see #242379).

XML JavaDoc doclet

My father was interested in a JavaDoc doclet which simply pumps out the available information about the classes, their methods, etc. into an XML file. So here is a 15 minutes quick&dirty hack version doing exactly that. Click here to see the code.

Just pump this little thing in your classpath and run JavaDoc with this doclet. The code is free for whatever you want to do with it. But bear in mind that it uses deprecated interfaces and has no real exception handling.

Fork me on GitHub