Implementing the blob tree

Evan Wilde | 2015

Blobs are a form of implicit surface defined by a point a filter field falloff function, and an iso to define where the surface exists. A "well behaved" field function will have a value of 1 at radius 0, and at some max radius, will have a value of 0.

Jim Blinn origianlly used Blobs, or "Blobby Molecules" to model electron density fields.

Since then they have evolved to handle other more complex geometries, including the concept of skeletal shapes, which allow the definition of the blob to come from the definition of a skeleton. This is useful for creating more primitive objects, such as a line or a torus.

• Axis-aligned Bounding Box Bounding Volume Hierarchies
• Multiple Primitive types
  • Sphere
  • Torus
  • Line
• Multiple Field Falloff Functions
  • Linear Function
  • Geoff Function (Soft Objects)
  • Metaball Function
• Four operations
  • Blend
  • Difference
  • Intersect
  • Union
• Three transformations
  • Translate
  • Rotate
  • Scale
• Curvature Calculations
• Normal Calculations

• make
• g++
• glm
• doxygen
• cppunit (optional, for unit testing purposes)

make library

It will result in a directory release/ containing libImplicit.a, html/, and inc/.
libImplicit.a is the static library to link to.
inc/ contains the header files.
html/ contains the html documentation.

The makefile contains multiple ways of compiling the library for testing. When compiling as a library, it will not compile main.cpp, which allows you to implement tests without having them show up in the library itself.

make debug will compile the program for debugging purposes with flags -Wall, -g, and -DDEBUG set

make test will compile tests in test/ as well as setting flags -Wall, -DTEST. It will link again cppunit and dl

make release will compile with optimization flag -O3 set

make docs will create a directory docs/html/ containing the documentation for the implicit system.

• The master branch is for working, apparently stable, code.
• The dev branch is for ideas being developed. This code will probably work.
• Assume all branches off of dev to be experimental and don't work.

We will begin using the standard version scheme of major.minor.bug

• major number will be updated any time
• minor number will be incremented any time there is a public api-breaking change
• bug number will be incremented with immediate bug fixes

The bug number will most likely remain zero, as most development will occur in the dev branch. Changes to the dev branch will not be counted toward the bug number, and will only be incremented if an immediate bug needs to be attended to directly in the master branch.