Posts tagged with 'Coding'

Voxel Volumes

  • Posted on November 28, 2014 at 8:37 pm

One of the main feature additions of the latests version of Functy has been the ability to export as SVX files. Functy could already export in PLY and STL, but both of these are triangle based. They represent the 3D functions as surfaces defined by carefully aligned triangle meshes. Rendering objects using a graphics card also uses the same triangulation process, so exporting as PLY or STL is a very natural extension of the existing rendering.
The SVX format is different though. It stores the models as a voxel image (a voxel being a three dimensional pixel, for those who didn’t grow up through the 90s demo scene). As a result, SVX doesn’t just store the surface, but also the volume of a function.
Turning a triangulated surface into a voxelated volume isn’t necessarily straightforward, but Functy has the advantage of having all its objects originate as purely mathematical forms. In theory, this means voxel rendering them as volumes should be quite easily.
What I found in practice is that for Cartesian functions and spherical functions this is true: they can be turned into voxel volumes in a very natural way. Curve functions are a different story though. In the next few posts I’ll go through each of the processes separately, to give an idea about how the solutions for each of the three function types were coded.

Voxel posts

  1. Intro (this post)
  2. Cartesian Functions
  3. Spherical Functions
  4. Curve functions

The Art of Good Design?

  • Posted on May 24, 2012 at 1:42 am

Designing a really good library is a difficulty task. Since around August last year I’ve been writing a program called Knot, which I also recently open sourced. This makes extensive use of 3D Bezier tubes to render Celtic Knots, and having written the code for this, it seemed sensible to try to integrate it into Functy, to allow arbitrary tubes to be rendered using curved cylindrical coordinates. So, that made it a perfect candidate - or so I thought - for implementing as a library. This way, improvements from the Knot code could be easily merged into Functy and vice versa.

Designing the library turned out to be tricky, especially the task of managing and animating all of the curves. I figured that if I put the effort in to getting the library right, it would make the process of integrating into Functy that much easier.

I was wrong. After painstakingly implementing everything needed in the library, I tried to integrate it into Functy, only to realise that Functy already has all of the management and animation functionality needed. Given that I wrote the Functy code, you’d have thought I might have know this.

The consequence is that I’ve ended up dropping all of the curve library methods and cut and paste the relevant code straight in to Functy. If I hadn’t done this Functy would have ended up with two totally separate lists of functions, two separate animation steps and two separate update steps. It would have been a mess.

It’s taken longer to modify the curve code for Functy as a result, but the final structure is much better. Unfortunately it also means the library is now redundant. I’ll have to find some other use for it.

There’s a design moral to this story I’m sure, but I’m not exactly sure what it is. I’ve ended up with a nice clean library implementation that doesn’t work for what it was designed for, a new implementation that doesn’t use this library, and what seems like a lot of wasted time. It feels like somewhere something went a bit wrong. At least Functy can now render curves, so even if it was a circuitous route, maybe the journey wasn’t entirely wasted after all.

Spherical co-ordinates

  • Posted on June 8, 2009 at 9:00 pm
Function using spherical co-ordinates

Function using spherical co-ordinates

So far Functy has worked only using Cartesian co-ordinates, but I’m currently working on code for the next release to allow functions to be defined using spherical co-ordinates too.

Spherical function plotting is already working as you can see in the screenshot. It seems to produce some nice effects that are quite different from those you generally get using Cartesian functions.

The tricky part seems to be getting the code for both co-ordinate types integrated nicely together, and also sorting out a suitable user interface to allow them both to be added seamlessly.

The reason the code is turning out to be tricky is that I’m trying to develop using object oriented techniques, but using C rather than C++. I know it’s perfectly possible to do this (and do it well; although not necessarily by me!), and so far there hasn’t been much problem. However, I’m now in a situation where inheritance would seem to be the perfect technique to use. Most of the methods needed for the two co-ordinate systems are the same, so in C++ it would make sense to use some virtual interfaces to define them and inherit these from a generic function type. Unfortunately I’m not sure if this is going to work well in C.

It seems like a silly thing to get stuck on and it would be nice to get the spherical functionality into the next build. I’m hoping the best method will become clearer as things progress.