Links - 2010 Aug 19

Octree animation

Update: this figure shows the numbering of vertices(red), edges(green), and faces(blue). The arrows show the direction of the X-(red), Y-(green), and Z-axes(blue).


Here the sides of the cube are not generated with Marching-Cubes, they are just extracted directly from the octree. Nodes are subdivided whenever the signed distance-field of the cutter indicates that the surface is contained within the node, i.e. the distance-field evaluates to both positive and negative at the eight fourvertices of a node. This apparently leads to transient holes in the surface when the cutter is just about to enter a coarse node which hasn't been subdivided very far yet. It should be possible to adjust the subdivision criterion so that the octree 'anticipates' the cutter slightly and subdivides ahead of the actual cutter surface.

Monster torque servos

Gone is the HiTec light-blue box, and replaced with a clear one. These servos, which HiTec calls "monster torque" 🙂 are designed for either 6.0V or a LiPo pack at 7.4V. They are about 10% bigger than the standard 20x40 mm footprint, and produce 36 kg*cm (6.0V) or 44 kg*cm (7.4V) of torque. To be tried as a winch servo in the prototype PIKANTO.

Cutsim progress

The speed of the new cutting-simulation code makes it possible to run it at a higher resolution than before. That makes the surfaces look smooth and nice. Alas, some problems still remain with holes in the fabric of reality mystically appearing and disappearing .

There is an edge-flipping paper by Kobbelt et al. from 2001 which improves the jagged/aliased look of sharp edges.

Update: Kobbelt provides a LGPLv2 licensed sample-implementation of the algorithm here: http://www-i8.informatik.rwth-aachen.de/index.php?id=17

Helsinki City Marathon

Been there, done that, have the medal, have the T-shirt!

It was hot and it was humid. I also had a strange ache in both my knees and my ankles which towards the end made each step forward painful. I was doing OKish through 30km and a bit further, but after that the walks at the drinking stations became longer, and I walked the uphills towards the end. Finished in 4h 42min. The breakup into 20k/10k/5k times shows how I got more tired towards the end:

The first 20k took 2h1min and the second 2h 23min.

The first 10k took 59min, 2nd 62min, 3rd 67min, and 4th 76min.

5k times: 29min, 30min, 30min, 31min, 33min, 34min, 36min, 40min

Temp(left) and humidity(right) data from FMI for around 15-19 o'clock shows T=23-25 C and RH=70-80% at least.

In colder weather, with a bit more training, and without the knee-ache, the next goal must be to break 4h!

Update: the finishing times are distributed like this:

This histogram was produced by scraping the results website with one python script and the plotting the results with another.

Download the scripts hcm_scrape.tar (works on Ubuntu 10.04LTS) hcm_scrape.tar

A whole series of histograms are on picasa: http://picasaweb.google.com/anders.e.e.wallin/HCM2010Statistics#

OpenCAMLib machining simulation, v.2

This is my second attempt at a machining simulation where a moving milling tool cuts away voxels from the stock material. To save space an octree data structure is used to store the voxels, and to produce a nice looking surface you store the signed distance to the exact surface in each vertex of the octree. You then use marching-cubes to extract triangles for a distance=0 isosurface in order to draw the stock.

Unlike my first attempt, this works well enough to warrant further experiments (on the to-do list are: differently shaped tools, colouring triangles based on which tool cut the voxel, lathe operations, material removal-rate, etc.). It should be straightforward to hook this up to the EMC2 G-code interpreter so that any G-code, not just densely sampled CL-points from OCL, can be simulated. You could also flip the sign of all the numbers, and simulate an additive process, like 3D printing (reprap / makerbot).

This approach to machining simulation is described in a 2005 paper by Yau, Tsou, and Tong.

Links - 2010 Aug 12

Octree with Marching Cubes

Update 3: this leads slowly towards a better and faster cutting simulation. Here's an example with Tux:

Update2: this looks slightly better now (a ball translated in a few steps towards the right). Image and c++ code by fellow OCLer Jiang from China.

Update: in a cutting simulation the stock is updated by removing voxels which fall inside the cutter. Here I'm trying it with a spherical shape positioned at (0,0), and then moved slightly along the X-axis. The white dots are corners of octree nodes, and the cyan triangles are produced by marching cubes. It works quite well, but on the border between the two cutter instances the distance-field is somehow wrong, and marching-cubes doesn't come up with the right triangles, leaving gaps instead.

Earlier I was building an octree volume-representation of a shape using a simple bool isInside(Point p) predicate function to determine which cubes are in and which are out. If instead a distance-function double distance(Point p) which is negative inside the volume, zero exactly on the surface, and positive outside, is used, then the Marching Cubes algorithm (this is a better explanation, someone should make the wikipedia page as good!) can be used to triangulate the octree. This leads to much more visually pleasing results at reasonable maximum tree-depths.

The same Hong-Tzong Yau of Taiwan who wrote a very reasonable drop-cutter paper in 2004 has more recently come out with a 2009 paper on cutting simulation using an octree and Marching Cubes.