Banate CAD Third Release

Is it Monday already!

Here is the third release of Banate CAD!

This week saw multiple improvements on multiple fronts.  I can’t actually remember which features showed up between the last week’s release and today’s release, but here’s an attempt.

Generalized Bump Maps – I made this earth and moon things, and then I generalized it so that any BiParametric based shape can utilize the technique.  That’s good because everything from spheres, to bezier surfaces are based on the BiParametric object.

import_stl_mesh – You can create a single instance of an imported mesh, and then use that single instance multiple times.  That’s a great way to save on resources when you’re adding multiples of the same geometry to the scene.

Blobs – Quite a lot of work on this module.  The main thing was getting the ‘beamsearch’ algorithm working correctly.  That allows for the “real-time” viewing of metaball based objects.  This was a lot of fun to get working.  It doesn’t work in all cases, but it works in the vast majority of cases that will be used in 3D solid modeling.

Some features on way the program itself works.  I’ve added support for reading some modules in from directories at runtime.  This allows me to separate some things that are ‘core’ and MUST be in the package from a number of other things that are purely optional.  It also allows me to support users adding things, in a sane way.  They can eventually go into a “Libraries” directory.

Also, this separation, and the addition of the BAppContext object allows for the creation of tools that have nothing to do with UI.  For example, in order to write a script that just imports a mesh, performs some operations on it, then exports, does not need all the UI code.

Oh yah, and before I forget, one of the biggest additions, or rather fleshing outs, was the animation system.  The AnimationTimer object has actually been in there for a while, and the Animation menu has as well.  It’s just nothing used it.  Now, if you create shapes, and implement the Update() function, your shape will be informed whenver the clock ticks, giving you an opportunity to change things based on time.  There are a few examples included in the example files.  It’s pretty straight forward.

The animation system is quite handy for doing things like playing with metaballs, seeing how things change as you vary parameters.  This will also come in handy when describing physical things that move.  For example, I could model my Up! printer, and then actually set it in motion.  But, that’s for another time.

There you have it.  Another weekly release!

Fast Metaball Surface Estimation

Using modeling techniques such as Constructive Solid Geometry (CSG), and others, a great number of 3D designs can be quickly and easily created.  Although I have found CSG to be a quite productive tool, I also find there are limitations when you want to produce shapes that can not be easily described by combinations of basic primitives such as cubes, cylinders, and spheres.

A long time ago, Jim Blinn created the “Blobby” technique of forming what appear to be more organic looking shapes.  This technique was created for computer graphic rendering, not for 3D modeling.  There was a later refinement of the technique which took on the name “Metaball”.  In both cases, the technique is a subclass of ‘isosurface’, whereby the surface of the object is described through mathematical combinations of various surface equations.

The easiest way to think about what these things are is to consider what happens with droplets of honey that get really close to each other.  Individually, each droplet might look like a perfect little circle sitting on a table.  Get them close enough, and their boundaries begin to merge, and they become some nice amorphous shape.  Metaballs are like that.  Balls individually will just be balls.  But, as soon as they start to get close to each other, they begin to form a unified blobby looking surface.

Although there is great flexibility in using metaballs for modeling, it can be fairly challenging to try and construct reasonable models in a short amount of time.  Once you have the set of balls that will be used to describe your object, it must be rendered, and meshed, so it can become a 3D solid.  Since metaballs are more typically used for onscreen graphics, rather than modeling for 3D printing, the renderers can take short cuts.  All a renderer needs to do is cast rays into the void, and see where it hits the surface that describes the shape.  Once it hits a point, it can be done, and  move onto the next point, without having to connect them in any meaningful way.

When constructing a 3D model, it is convenient to be able to create a mesh, preferably one that can be enclosed, so that we can generate solids which can be printed.

What I have been struggling with is how to efficiently construct that mesh, without having to do a brute force calculation of the entire space within the volume where the metaball lives.  What I was looking for was a way to cast beams into the metaball equation, and at the same time connect the points to form a nice triangle mesh.  So, first is the beam casting.

The metashape is described by an equation,  f(x,y,z).  The way the equation works, any value that is < 1, is ‘outside’ the surface.  Any value > 1 is ‘inside’ the surface.  Any value that == 1, is ‘on’ the surface.  So, what I’d like to do is search a space, and for each point in this space, figure out the value of the function.  Where the value is 1, I know I have hit the surface.

This is the very crux of the problem.  How do you efficiently choose x,y,z values such that you don’t waste a bunch of time running the calculation for points that are nowhere near the surface.

The novelty that occured to me was that if I assume the whole of the metaball structure is in the middle of a sphere of sufficent radius, I could run a later beam around the surface of that sphere, casting beams towards the metaball structure.  Essentially, what I would like to do is cast a beam towards the conter of the sphere.  From there, if I’m ‘inside’, then cast again, only go half way between our last point, and the point from which I started the last cast.  If I land ‘outside’, then do the same thing, but cast inward.

This amounts to a binary search of the surface, along a particular path from a location outside the surface, in towards the center.  It seems to be fairly  efficient in practice, primarily governed by the original search radius, the number of balls, and the number of rays you want to cast.  In addition, how tolerant you are in terms of getting close to ’1′ for the function will have an impact on both the quality and the time it takes.

So, now we have an efficient beam search routine.  How to drive it?  The easiest way is is to simply go around a sphere, progressively from the ‘south pole’ to the north, making a full circumnavigation at each latitude.  So, just imagine again, that laser beam (which we know is doing a binary search to find the surface intersection), and run it around the sphere.  Since there is coherence in how we navigate around the sphere, I can connect one point to the next, and easily triangulate between the points.  What you get in the end is not just a point cloud, but a direct calculation of all the interesting vertices, already formed into a nice mesh that can be a solid.

Here, you can clearly see the facets, and perhaps imagine the trace of the beams from bottom to top, and around the circumferance.  This will not work for all metaball networks.  It will not work in cases where there is a separation of the balls.  In that case, two networks need to be formed, or at least the two need to be healed where there is a hole between them.

Similarly, this technique will not work where the is some sort of concave part where the “laser beam” can not see at the surface.  Basically, if you imagine yourself flaying around the object, if you can not see some part of it from the outside, then it will not render correctly.  This can possibly be remedied by getting in closer in such situations, but that’s another exercise.

Creating your own metaball object is fairly straight forward:

local anifrac = 0.95

local balls = {{0,0,0,5}, {0, 1, 19.95*anifrac, 5}}
local isosurface = shape_metaball.new({
balls = balls,
radius = 50,
Threshold = 0.001,

USteps = 15,
WSteps = 15,
})

addshape(isosurface)

You can control a few things here.  First, is the ball network itself.  You can put in as many balls as you want.  Of course, the more balls, the slower the calculations.  It might require quite a few balls to make an interesting structure.  It’s just something to play around with.

Next is the radius.  This value determines the size of the enclosing search space.  It doesn’t have to be hugely accurate, but within an order of magnitude is nice.

The Threshold value determines how tight the calculation is.  0.001 is a good starting point.  This will give you a fairly tight surface.  If you go with a larger value, the calculations will be quicker, but your object will beging to look fairly coarse.  An even smaller value, 0.0001, would make for an even tighter fit to the surface, and thus a smoother object.

The last part has to do with how many facets you want to generate.  This completely depends on the size of your model.  Basically, it determines how many stops there are around the circumferance of the sphere.  USteps is how many longitudinal steps, and WSteps is how many latitudinal steps.

When modeling, it’s probably good to go with looser values, that way you can play around quickly.  As you get closer to wanting to generate your final model, you up all the numbers, and go get coffee.

In this final picture, I’ve set the Threshold to 0.00001, the USteps to 360, and the WSteps to 360.  That’s fairly fine detail, and the generated model will be quite large, but very smooth and accurate to the model.

The conslusion of this little exercise?  Metaballs are a very interesting and valuable tool for the 3D modeling of shapes that are not easily described by standard CSG operations.  Banate CAD has a metaball module that have the speed to render models in real-time, and the flexibility to allow you to dial in as much detail as you want.  This makes modeling with metaballs in Banate CAD a relatively painless prospect, which opens up the possibility of much more organic shapes for modeling.  The beamsearch algorithm makes it practical.

How much configuration?

Since Banate CAD exposes everything to the scripter, you are free to change pretty much anything at runtime.

Here, I have entered one line of code in my script to change the color scheme:

defaultviewer.colorscheme = colorschemes.Space

the ‘Space’ color scheme is defined in the colorschemes.lua file and looks like this:

colorschemes["Space"] = {
BACKGROUND_COLOR = {0, 0, 0, 1},
CROSSHAIR_COLOR = {0.5, 0.75, 0.75, 1},
WIREFRAME_COLOR = {1,1,1,1}
}

You can easily add your own color scheme to that file before you start Banate CAD, then it will be available to you later in your script.

Or, since it’s just a table that’s available at runtime, you could just as easily construct a scheme from within your script.  And start using it.

That’s just one of a number of things you can customize about the environment.  You can also change things like the lighting. If you wanted to add a light, you could do something like:

local newLight = BLight:new({
ID = gl.LIGHT2,
Diffuse = {0.5,1,0.75,1},
Position = {2,1,-1,0},
Enabled = true
})

table.insert(defaultsceneviewer.Lights, newLight)

Or something to that effect.  In this particular case, a bit of the underlying OpenGL is showing through (gl.LIGHT2), but that will get cleaned up as the lighting system goes more generic.  But, you could do it if you wanted to.  You could even change the default lighting system by going into SceneViewer.lua and just changing the lights to be whatever you want.

This is one of those things that hardcore tinkerers might be interested in, but someone like my mother would just leave well enough alone.

At the moment, I’m working on the Animation system.  That’s pretty cool because that picture above can actually move!  Yep, you got it, the little moon can be shown to orbit the earth.  Of course, if the moon were actually proportionally that big and close, our skin would probably be ripping off our bodies from the tidal forces, but it makes for a nice visualization nonetheless.

Animation can only be shown if you’re actually playing with the script though.  I could of course add a “Make Movie” feature, but that’s a bit of work to do cross platform.  I can certainly generate a bunch of .png images that can then be stitched together by another piece of software.

At any rate, Banate CAD is first and foremost a 3D modeling/printing piece of software.  That doesn’t mean it has to be boring though.  By adding visualizations and animations, I believe it will make the 3D design experience that much more approachable and interesting, and thus more people will do it because it looks like a video game.

Exposing the Core

Banate CAD strives to follow the design cliche “Make that which is simple, simple, make that which is hard possible”, or something to that effect.  To that end, Banate CAD is structured in nicely composable layers, or at least in my mind.  This can be seen in one area, the import of mesh files.

Here, I have used the simplest of import commands:

import_stl("bowl_12.stl")


translate({100, 0, 0})
import_stl("bowl_12.stl")


The import_stl() function will simply read in the .stl, and add the mesh to the scene automatically. In this case, the second import_stl() call will load the same .stl again, crating another instance of the mesh, and add that to the scene as well.

This is pretty straight forward, and works just fine. For limited numbers of meshes, the fact that you’re replicating meshes, doesn’t really have that much of an effect. Where this is a pain though is when you want to load multiple instances of the same mesh, perhaps 10s or hundreds of them.

Here for displaying 16 of the bowls, I’d actually like to load the bowl once, and simply use that same mesh to perform many operations. So, instead of using the import_stl(), I use the import_stl_mesh() function like the following:

function test_instancing(rows, columns)
local amesh = import_stl_mesh("bowl_12.stl")

for row = 1,rows do
for col = 1,columns do
color({row/rows, (row+col)/(rows+columns), col/columns, 1})
translate({col*100,row*100,0})
addmesh(amesh)
end
end
end

In particular, it is this call at the beginning of the function that does the magic.

local amesh = import_stl_mesh("bowl_12.stl")

Here, we are loading a single instance of the mesh. Then later, we can use the addmesh() function to actually add the mesh to the scene. From then on out, it will be displayed just like in the first case, but it won’t have to replicate the mesh to do it.

It really shines when you have a whole bunch of things:

In this case, with 100 instances of the bowl, it doesn’t take much longer to load/render than simply displaying a single bowl.

What does this have to do with layering? When you call ‘import_stl’, that code is essentially doing import_stl_mesh(); addmesh(). Rather than hiding that, it is made readily available to the user. The casual user who’s not concerned with hundreds of instances, or optimizations, can simply use the import_stl() call. For those who want to get into the nitty gritty, and deal with their own instances, they can use the import_stl_mesh() call. The other benefit of doing the version where you get back the mesh, is that you can then perform operations on the mesh itself if you so choose. Let’s say for example you have some sort of smoothing routines, or something that fixes vertex normals, or an exporter, or any manner of things, you can add them easily because you have the mesh in hand, and not just a graphic representation of it on the screen.

It might be possible to write code like this:


local amesh = import_stl_mesh("file.stl")
export_dxf("file.dxf")


Banate CAD does not currently have any DXF support, but when it does show up, you’ll be able to easily do this. And while you’re at it, since you can do: export_stl(amesh, "newfile.stl"), you could write code within your file to generate multiple .stl files, one per mesh in your scene if you feel like it. The default “Export STL” from the File menu simply iterates through all the meshes in the scene (simple) and exports them all. They access and layering in Banate CAD allows anyone to do the same from within your script.

So, the system is very flexible, and gives the scripter the exact same capabilities as the guy who wrote Banate CAD in the first place (me). So, if you want to stick with the simple, you can do that. If you want to go down to the metal, from within your scripts, you can do that as well.