The original Lissajous is up on deviantArt and Shapeways; the alien egg is also on deviantArt and Shapeways.

]]>radius = (3*(0.5+(sin(cos(a)+(p*((3+cos((pi*0.3)-1.5))/4))*10)**2)+((6/6.6)*((2+sin(8*a))/3)**4)))*sin(p)+(4.3*(1-(sin(p)**2))),

colour (R, G, B) = (r/8, (3+sin((a)*8))/5, (3+cos(a*8))/5).

The print is actually rather small (just 6 cm diameter) and the ridges of the shape are really quite delicate. In spite of this, the 3D print has come out really very similar to the original design. I guess you might expect it to be pretty similar, given the way it was produced directly from the model! However, if you look really closely at the original you can see the strata through the object created by the printing process. What I’m really impressed with, though, is the colour produced. I’d expected this to be a bit washed out, but in practice it’s a pretty impressive match.

Below is a comparison of (from top to bottom) the Functy render, the 3D print and a render done using Blender Cycles. In case you’re interested and your browser supports APNGs, there’s also a peculiar animated version!

While it’s neat to be able to print static versions of these Lissajous figures, in the future I’m sure it’ll be possible to make the fully moving version as well. Now *that* would be really something!

The parametric curves in Functy are particularly suitable for generating nice Lissajous curves, and as usual, they can be output for 3D printing. The results of pumping them through a 3D printer, courtesy of Shapeways, can be seen in the photos below, along with a Blender Cycles render of one of the curves.

If you fancy getting really up-close-and-personal with them, you can order your own copies as unusual desk ornaments, from the Shapeways site.

P.S. This post was actually made using Ubuntu phone. The browser’s still a bit “experimental” so it’s been a bit tricky, but it does seem to work!

]]>For the moment then, the best way for us to understand the lost depth component is by shifting our perspective, or in other words, by moving things around.

However, there are other ways to approach this and in the past I’ve been incredibly impressed by the way blur can be used to improve the perception of depth. This can give a really nice effect of camera focus, where different parts of the image have different levels of blur applied depending on whether they’re in or out of focus.

Testing this on some of the network graphs that I’m currently working with has produced some really quite nice effects. Ironically, by making parts of the image less clear, the overall coherence and clarity of the image is improved substantially. Here are a couple of screenshots of a random network with focus blur applied, both from up close and from a further distance.

The effect is achieved by rendering the whole image to a texture framebuffer. A very simple fullscreen shader is then applied, which increases or decreases the level of blur for a given pixel depending on the z-buffer depth value at that point. It’s a really very simple technique, but in my opinion produces some quite effective result.

This is one of the reasons why shaders are so phenomenally powerful. The depth blur is a very short program, but it needs to be executed for every single pixel of the image. That’s a lot of pixels, and a lot of computing power is needed to do this. Applying a shader program in parallel across the whole image is hugely more efficient than getting the CPU to do it. This allows it to be applied in realtime for each rendered frame, without stretching resources, even on my relatively underpowered laptop.

Check out Lighthouse3d.com and open.gl for some nice tutorials about using framebuffers for applying full screen shaders.

]]>The screenshot below shows a network of 60 nodes, each one rendered as a spherical co-ordinate function, joined together using links rendered as curves. I just plucked some simple functions out of the air to see what the results would be like but am hoping to extend it with more interesting shapes as things progress.

The various parts of the network are a little hard to discern with a static image, but when I tried to capture a video the result was a mess of fuzzy artefacts (I think there must be something going wrong with my screen capture software), so I gave up on that.

The next step, after neatening up the code, is to arrange better animation of the nodes and links, with dynamic movement based on things like the forces between the nodes. I’m hoping this will produce some really nice effects, and if anything comes of it I’ll put a bit more effort into getting a successful video capture.

]]>I’ll try to figure out a solution, but it’ll probably involve having to find a different way to host Wordpress on Sourceforge. Very frustrating! Thank you to ARJ though, for helpfully explaining how to clear all of the comments from the Wordpress database! ]]>

The actual process of upgrading was surprisingly painless. One outcome though is that a lot of the links in the menu on this page have now moved to different URLs. In addition, there’s also a new SVN repository to use.

Nothing too dramatic, but hopefully the move to *new Sourceforge* will give things a bit of modernisation, while making things work more nicely, more seamlessly, and more attractively.

That was, until I realised Functy was quite capable of doing it already. Functy’s parametric curves are already perfectly suited to the rendering of parametric equations. This part might be obvious. Less obvious for me was that the colouring of a flat Cartesian surface is perfect for the rendering of the implicit form.

Above are a couple of screenshots showing the two types of function. These are both taken from the example in another paper by Sederberg, Anderson and Goldman about “Implicitization, Inversion, and Intersection of Planar Rational Cubic Curves” (available from ScienceDirect). The curve is a quartic monoid which can be expressed parametrically and implicitly as follows.

Implicitly:

(*x*^{4} - 2*x*^{3}*y* + 3*x*^{2}*y*^{2} - *xy*^{3} +*y*^{4}) + (2*x*^{3} - *x*^{2}*y* + *xy*^{2} + 3*y*^{3}) = 0

Parametrically:

*x* = - (3*t*^{3} + *t*^{2} - *t* + 2) / (*t*^{4} - *t*^{3} + 3*t*^{2} - 2*t* + 1)

*y* = - (3*t*^{4} + *t*^{3} - *t*^{2} + 2*t*) / (*t*^{4} - *t*^{3} + 3*t*^{2} - 2*t* + 1)

In the screenshots the red line is the parametric version of the curve for *t* in the interval (0, 1). The other colours on the surface represent the values of the implicit function. Note that the implicit function actually lies at the boundary of the yellow and blue areas. You can see this slightly better in the 3D version, where the height represents the value of the implicit function. The actual curve occurs only where this is zero - in other words where the surface cuts through the plane *z* = 0.

It was reassuring to see that the parametric curve matches the implicit version. It’s also interesting to note that the implicit version is rendered entirely using the shaders in a resolution-independent way. It’s possible to zoom in as much as you like without getting pixelisation. This is exciting for me since, although it’s not what I’m really trying to achieve (that would be *too* easy!), it hints at the possibility.