It’s similar with code. The moment you choose to release an algorithm, a technique, an idea, it’s no longer completely yours. It’s out there, free for everyone to do as they like. And chances are that in the end only a few people’ll know that that is the clever algorithm that Bruce came up with. Not because of malignant thievery, but because of Tumblr-like careless attribution.

Anyway, most of us don’t have to worry about this, I gladly share it all, because real innovation that’s truly worthy of attribution is rare. If someone’s uses hemesh, it’d be fun to be credited for the hard work that went into it. But I don’t need credit for the things that are created with it. Many other tools exist and in any case, it’s an implementation of an existing data structure. The thing is: anyone could’ve coded it…

There is however an idea, an algorithm out there that was shared by its creator Jonathan McCabe that is worthy of true attribution, that falls outside the realm of “anyone could’ve done it”. It’s been more than two years since I came across his multi-scale Turing patterns. They instantly intrigued me. And although I could recreate the gist of his images, I could never overcome the practical problems. In fact, the code proved hazardous to the elderly, infants and pregnant women. I thought my lack of numerical skill in tackling the huge equations I ran into was the problem. It was ponderously slow and I suspected Jonathan had a secret lair packed with supercomputers.

Turns out I was being silly. An almost incidental post on Flickr revealed that Jonathan has a paper on his cyclic symmetric multi-scale Turing patt.., what the hell, on his McCabeisms. And it’s full of DTC lines (A rarely needed acronym for “damn that’s clever”). Seems I wasn’t barking up the wrong tree, I was in the wrong forest, on the wrong continent, on the wrong planet… As if that wasn’t enough, Jason Rampe provides a blog post with useful pointers in implementing Jonathan’s idea. I say pointers, it’s actually more of a very elaborate pseudocode than a blog post. So the McCabeism is out there, ready to be implemented by anyone.

So I did, in Processing and thanks to Jason, it only took a few hours. This sketch is my small contribution to the free distribution of Jonathan’s very, very clever idea. It contains the basics as explained in the Softology blog post. I’ve added no explanations of my own. Jonathan’s paper and Jason’s post are very clear and definitely worth reading.

Feel free to use it in your own exploration of McCabeism. There’s plenty of room for experimentation. Capture it, dissect it, change it, mutate it, (now that’s a wildlife show I’d like to see) and above all attribute it to Jonathan McCabe…

A somewhat more serious post after the previous one (well, actually Matt Pearson’s previous post ). Sometimes you get wrapped up in writing a piece of code, getting it to work your only purpose. Inevitably you turn to existing code, ripping and tearing through it to get at its beating heart.

With the internet providing access to such an amount of information, it can be easy to forget where a particular solution came from. On the other hand, including complete generic libraries to benefit from a few classes in specific instances would quickly bloat any project. I tried to compile a list of code that was ravaged for the good of hemesh:

1. Javolution is included in the hemesh distribution. This high-performance library offers fast, reliable alternatives for many of JAVA’s basic classes. Without FastTable and FastMap, hemesh would be a lot slower.
2. libssrckdtree-j Generic k-d tree Java library: only a barebone skeleton remains of this truly generic k-d tree implementation, wblut.kdtree.WB_KDTree and wblut.kdtree.WB_KDNeighbor. It provides lightning-fast closest-point calculation and degenerate-vertex checking. Although k-d tree algorithms are well-described, implementing a fast one yourself is a less than trivial task.
3. Sean Luke's fast Mersenne Twister random number generator is my preferred RNG throughout hemesh. For (my) convenience it is exposed through wblut.math.WB_MTRandom, WB_RandomDisc and WB_RandomSpherical.
4. Marius Watz’ unlekkerLib provided the foundation for the wblut.hemesh.HE_Mesh.saveToSTL function.
5. The Fortune’s sweep algorithm for 2D Voronoi is often discussed but rarely implemented. wblut.geom.WB_Voronoi2D is a bare-bones adaptation of Zhenyu Pan's JAVA transcription of Shane O’Sullivan’s C implementation
6. John Lloyd’s QuickHull3D pack­age makes a reappearance as a convex hull generator for the wblut.hemesh.modifiers.HEM_Wireframe joints.

Not only code is scavenged without mercy, a whole range of reference material on algorithms is scoured:

1. The über-reference Paul Bourke. Invaluable for many geometric algorithms, especially in HEC_IsoSurface.
2. Christer Ericson's Real-time Collision Detection for many of the geometric datastructures and intersection algorithms in wblut.geom.
3. Code provided by Jon Squire served as the starting point for the basic platonic solid creators in wblut.hemesh.
4. Scloopy’s reference to a paper by Mandal and Esan proved just the thing I needed for wblut.hemesh.modifiers.HEM_Wireframe.
5. A thousand page tome has added its burden to my desk: Geometric Tools for Computer Graphics by Philip Schneider and David Eberly. Its contents are increasingly implemented in hemesh’s geometric backbone. If hemesh turns out to be stable, this book deserves the praise. If not, it’s me that messed up somewhere…
6. David Marec was so gracious to provide me with meticulously compiled vertex and connectitivity data for a whole host of polyhedra. Not only was the data flawless, it was also almost directly usable. A rare fortune indeed.

While hemesh grows into different areas, these lists will undoubtedly expand. I just hope the need for proper bookkeeping won’t spoil the fun of coding…