Bitphoria Screenshots

 I just felt compelled to post some new screenshots. Not much has changed as I've been working on underlying stuffs and writing the scripting manual, but it sure looks purdy.

Check back soon for more updates. I'm in the midst of designing the master server situation so players can start and find one-anothers' games easily without any port-forwarding nonsense. I'm also hammering out the Bitphoria Scripting Manual as a guide and reference for people who want to make their own games out of Bitphoria and share them with the world via the ingame server-browser. Players do not have to download anything externally to play custom Bitphoria games. It's a thing of beauty.

2D Rectangle Overlap Algorithms

 While working (not so) diligently on the re-write of Holocraft I encountered a situation where the need for an age-old algorithm arose. The algorithm itself, and/or its implementation, has had many minds over the course of time to boil it down to a few bare-necessity lines of code.

Example of the problem and some possible conditions.
From: http://www.owenpellegrin.com/articles/vb-net/simple-collision-detection/

 Determining whether or not two rectangles overlap or intersect has been one of those problems that has found application in many a project. It's rather simple to implement, and most novice programmers take pride in discovering a solution to the problem, even including the case where the algorithm is extended into the 3rd dimension in the form of 'axis-aligned bounding-boxes', or 'AABBs'.

3D axis-aligned bounding boxes intersecting.
From: http://www.miguelcasillas.com/?p=30

 There have been many games which utilize either a 2D or 3D variant of this algorithm to determine if two objects in a game world are colliding with one-another. The original Quake game is an example of a game where entities had their collision volume defined by way of an axis-aligned bounding box. This caused players to axially slide off other objects as if they were a flat cubical shape. Personally, I prefer using a cylindrical or capsule collision volume for players and NPCs, because this gives a smoother collision resolution where the player just sort of slips and slides around other players and objects. Most modern games utilize this sort of collision volume for players nowadays for low-fidelity intersection tests, and sometimes as a pre-test to avoid the cost of doing more intricate intersection tests in the case of hitscan weapons and the like.

 At any rate, during my outset to re-write Holocraft it became clear that it was imperative that there be a way to detect where groove optics are overlapping, or otherwise intersecting one-another due to the fact that many of my trial-holograms thus far have been muddied in areas where the density of intersecting groove optics is too many. Too many intersections and too much overlap of grooves can completely annihilate the clarity of their reflectivity. The solution is to prevent the machining process from scribing over the same areas, allowing the fore-front optics of the hologram to take precedence over the background optics, optimizing the overall clarity of the hologram as a whole.

A screenshot of the new Holocraft showing the geometry and optics of a moderately detailed specular hologram. As you can see it is very easy to create many overlapping and intersecting optics (the curved colored lines) which will reflect light to depict the white dots along the edges of the model's geometry. Blue optics will appear nearest, red the furthest, and green will appear with mid-range depth.

 Now, per Matt Brand's whitepaper on Specular Holography, groove optics are hyperbolas that are calculated from the assumed incident light ray altitude angle that will be illuminating the hologram. I have chosen to calculate from the the hyperbola a cubic Bezier curve, which is defined by a starting and ending point, and two control points which dictate the curvature of the line that traverses the space between the endpoints. This curve then serves as the internal representation of the base shape from which all optics for the hologram are then derived, based on the 3D position of the point that is chosen from the source hologram geometry's vertices, edges, or surfaces that will be depicted by this reflective optic.

 These optic curves are segmentized by an occlusion-culling pass, which designates which spans of the curve should reflect light based on whether or not the hologram geometry should be 'blocking' their visibility, on a per-degree of viewing angle (or 'azimuth') basis.

 Once these segments of visibility are determined I then need to determine which ones are intersecting or otherwise overlapping one-another too closely to cause degradation in the final hologram. One way is to brute force compare the distance of every single point of each optic segment against every single point of every other optic segment to determine if the segment needs to be clipped or split/culled, etc..

 To speed this process up I have resorted to the use of a simple bounding rectangle overlap comparison. Effectively, this is a 2D axis-aligned bounding box intersection/overlap test. This is what I call an 'early out', where the core loop that is performing these comparisons and tests can quickly and cheaply pre-determine that there is no possible way for two given optic segments to be intersecting (because they are, for example, on opposite sides of the specular hologram).

 If there *is* an overlap detected between the two rectangles bounding two optic segments, then Holocraft proceeds with a more detailed comparison of the two segments, effectively comparing each point on each segment with each point on the segment in question. This is a simplified explanation of the actual process which determines overlap/intersection, as the actual algorithm uses a heuristic method to dynamically adjust the increment at which it 'steps' along each segment to the next point to compare with all the points of another segment to perform a distance check. This helps to accelerate the process, which is albeit fast enough without the heuristic method being as Holocraft only performs intersection detection when the user is saving the holographic output, currently as either an SVG vector image file or directly to CNC g-code.

 Now, the whole point of this blog post is to share the method by which I devised a rectangle intersection test that serves more utility for Holocraft's purposes. It would seem that with my growing years as a programmer I have been growing a rabid aversion to doing things the tried-and-true way, with a sort of desperation to find a novel way to go about doing things that people have already been doing another way for decades.

 A part of the heuristic method by which Holocraft accelerates optic intersection/overlap detection relies on knowing the rectangle of overlap itself in which two given segments are possibly intersecting. Knowing that their bounding rectangles is overlapping as a mere boolean piece of information is not sufficient for it would require that *every* point on each segment is compared against *every* other point on the opposing segment. To minimize this only the points on each segment that are within the overlapping area of the rectangles is considered.

Here's a copy-pasta of what Holocraft does:

//
typedef struct
{
 float x, y;
} vec2;
//

// 2d rectangle
typedef struct
{
 vec2 min, max;
} rect2d;
//

#define MAX(a, b)  ((a) > (b) ? (a) : (b))
#define MIN(a, b)  ((a) < (b) ? (a) : (b))

// returns zero if no overlap, otherwise returns
// area of overlap and optionally the rectangle of overlap via '*o'
float intersect_rects(rect2d a, rect2d b, rect2d *o)
{
 rect2d c;
 float dx, dy;

 // find horizontal overlap
 c.min.x = MAX(a.min.x, b.min.x);
 c.max.x = MIN(a.max.x, b.max.x);

 // not overlapping horizontally...
 if((dx = c.max.x - c.min.x) < 0)
  return 0;

 // find vertical overlap
 c.min.y = MAX(a.min.y, b.min.y);
 c.max.y = MIN(a.max.y, b.max.y);

 // not overlapping vertically...
 if((dy = c.max.y - c.min.y) < 0)
  return 0;

 // caller requires rectangle of overlap ?
 if(o)
  *o = c;

 // return area..
 return dx * dy;
}
//

 This is with the goal of quickly calculating the rectangle of overlap itself, while putting priority over the horizontal check over the vertical check (perhaps in Holocraft's case this should be reversed?) and will bail out if the horizontal overlap fails before bothering with the vertical overlap check.

 This is in contrast to most of the functions you will find on the internet, which perform a few simple greater-than/less-than checks against the min/max of the bounding rectangles/volumes and provide no other useful information.

 In the past, for game physics, I would just make everything a sphere and perform a simple pythagorean distance check against the combined radii of the two entities in question. I almost opted to use circles as early-out bounding volumes for optical segments until I actually sketched on paper how much extra space a circle would typically have over a simple bounding rectangle.

 Incidentally, the rectangle boundary calculated for each segment is derived from the convex hull of each curve, which is defined by both the endpoints of the curve and the control points that define the shape of the curve itself. It is said that the entirety of a cubic Bezier curve is contained within this area, and if there was a fast way to perform intersections against these convex hulls then that is what I would do, but there really isn't. This would require a series of line intersection tests and be quite a bit more complicated than it is worth.

Demonstrating the confinement of a cubic Bezier curve to its convex-hull, as defined by its endpoints and control points.
From: http://www.scratchapixel.com/lessons/advanced-rendering/bezier-curve-rendering-utah-teapot

 One of the advantages of using cubic Bezier curves as an intermediate representation is that outputting a vector image via the SVG file format allows for cubic Bezier curves to be defined as-is, without converting or transforming to any other form.

 This is in contrast with outputting CNC g-code, in which machine toolpaths can only be defined as either linear or circular motions, requiring an intermediate step in Holocraft which deduces a series of circular arcs chained together to form an optic curve. This is done within a user-supplied tolerance value, to give some degree of control over how large/complex the final CNC g-code output is, and the degree to which the machined grooves are faithful to the calculated optic hyperbola.

NewbieTime is Live

 I made a game for my children called NewbieTime. It's an idea I had a few years back but didn't get around to working on until last summer in the middle of Bitphoria development. I had everything pretty much finished and polished and ready to release and somehow decided to move on to other things instead. Well, I stumbled across it and decided it was time that it saw the light of day and now it's live for download/sale at deftware.itch.io.



 Check it out and let me know what you think!

 Working on a re-write of Holocraft that is much cleaner. After much aluminum scoring and grooving I had come to the realization that I needed to mitigate the fact that groove optics were allowed to intersect with abandon. This allowed for spots on holograms that are densely populated with optics to appear 'dirty' and effectively ruin the holographic effect. In order to properly deal with this within the way that Holocraft was slapped together would be just more sloppy work, so I opted to re-write to allow for much better.... well... everything.

 Occlusion culling will be on-point, and the program itself will run much faster, and deal with larger and more complex geometry much better. More on this once it's finished.

 Also on the todo list is documenting Bitphoria's scripting system, which is the final step before an initial public release. I want people to be able to begin playing with the scripting system and see what they come up with. Multiplayer functionality is all there, and entire games can be made out of Bitphoria but I have not been so inclined to actually make a game as of the past year.

 I still need to figure a master-server setup that will allow players to easily start and join one-another's games. This will be included in a later release.

Holocraft - The CNC Machining Adventures

 Much has happened with Holocraft since the last blog post. I now have an X-Carve tabletop CNC routing/milling machine now, which I spent the entire holiday season building from the ground up. I needed a place to put the machine on, because I had no space large enough to accommodate it's massive 31" square size (except the kitchen/dining table, but that wouldn't have gone over well with the wife). So I invested in two smaller tables from IKEA that when placed butted up against one-another they create a perfectly sized platform for the machine.

The TARENDO table from IKEA.

The tables are sturdier than they look. I assumed the legs would be wood, just as the top surface of the table is, but they are actually steel, and the whole underside of the table is also braced with similar steel beams. The tables, however, are not completely impervious to wobbling when the machine is dancing about across a hologram, which required some extra fastening and stabilization to be put in place.

The machining setup nearing completion atop the pair of TARENDO tables ordered from IKEA

When I ordered my X-Carve from Inventables.com I went ahead with the option to get the Dewalt 611 router to use as a spindle in the machine. Unfortunately both the DWP611 and the power supply interface board were out of stock and wouldn't be shipped out until January 8th at the latest. I ordered my machine on the 16th of December, which was a Wednesday. Everything arrived (minus the spindle and PSU) the following wednesday in a pair of boxes.

UPS had just left my driveway when this happened.

Since the Dewalt spindle was going to take nearly a month since my X-Carve order was placed to arrive at my homestead, I opted for a backup solution and invested in a high value package deal I found on Amazon for a Konmison 48v DC spindle that comes with it's own PSU, and a set of collets up to 7mm in size (just over a quarter inch). It also comes with its own CNC mounting hardware but it isn't usable on the X-Carve, so I opted for the 'universal spindle mount' that Inventables.com sells on their website, and it has been working out just fine.

Being that both the X-Carve and Konmison spindle have their own PSUs, I opted to stack them so that the fan in the XC PSU would help the Konmison spindle PSU cool down as well, by placing the KSPSU upside down ontop of the XC PSU.

This was the end result:

I call it the 'Frankensupply'.

As you can see, the XC Arduino and GShield are on the left, and the Chinese PSU is strapped ontop of the XC PSU, with the spindle potentiometer strapped down on the corner of the spindle's PSU. I figured that this configuration will best be suited to whatever I come up with insofar as an encasement or enclosure are concerned, cutting holes for the potentiometer, air flow, and power/USB lines. So far I have not been electrocuted, so that's good.

Another issue that arose was how I was going to be mounting my aluminum into the machine as I opted to save 250 bucks by not going for the default wasteboard that comes with the XC machine. Instead, I tried mounting the aluminum directly to the machine frame itself. This *does* work, but it allows for much torque against the X-axis gantry. This is due to the fact that the workpiece sits so far down below the gantry that there is a considerable amount of leverage against the gantry itself, being that the tool is not directly below the gantry but instead jutted out infront of it where the spindle itself is.

The Konmison DC spindle itself has been serving rather appropriately. I have managed to create a few different things with it.. On the plus side it is very light (compared to the DWP611) and runs at a rather decent 12k RPM, according to the seller, but this is something I've yet to determine with something like a tachyometer.


On McMaster Carr's website there is a slew of different metals to choose from. Knowingly, I opted to go for either the 1100 alloy or the 3003 alloy, both of which are extremely pure forms of aluminum. Being that they are pure they are also extremely corrosion resistant, simply because aluminum itself is highly non-corrosive. The other property of aluminum is that it, in its pure state, is very soft. It is on the order of between lead and copper. You can easily scratch it with a pushpin. It's not exactly the softness of lead, but it's definitely not steel.

I had originally opted to go for the softest and purest aluminum available via McMaster, which is the 1100 alloy. The reason for this was simply that it was just the purest they offered, and it was pretty cheap. I started out with five 6x6x0.063" sheets of this (1/16" thick) just to try out. At the time I was still milling the aluminum, using tiny 1/16" and 1/32" ball-nose end mill cutters, and cutting this soft aluminum was wretched at best. It would effectively pile up the removed aluminum along the sides of the grooves. This was disgusting.

I then went ahead and tried out the 3003 alloy, which is actually a bit cheaper than the already-cheap 1100 alloy. It seems to be virtually the same, machining-wise. But sine it's cheaper it's going to be my go-to hologram metal.

The 3003 also comes in a wider variety of thicknesses. Now, provided that I will only be making grooves that are only a few thousandths of an inch deep into the metal, I still need the metal plate itself to not be flimsy and prone to getting bent by slight forces, so thus far I have been opting for sheets that are .050". I actually have on order some more that are only .032" thick, just to see what that's like (plus it's even cheaper).. So hopefully that works out. But thus far, between the 1100 and the 3003 I think I will be sticking with the 3003 simply due to its price.

Makercam.com made life somewhat easy for a while.

Now, being that Holocraft's original means of output was by way of spitting out SVG file paths for the eCraft paper crafting machine, it was a miracle to discover that out of all the free CAM software out there there was only one that could handle the thousands, and even tens of thousands of grooves being output by Holocraft, and that was MakerCam.

MakerCAM made it a snap to convert my hologram toolpaths from an SVG file into a CNC g-code file. This was not without its caveats, of course... For one, the user cannot control how exactly the toolpaths are generated for the paths of any given SVG file. Many times I would find that MC's output would resume cutting a groove from a single side. Over and over it would enter the material to cut a groove, cut through to the other end, then it would raise the tool up over the surface to move back to the beginning side again. To my mind, it would be much quicker to finish a groove, move a little deeper into the material, and then continue back the other way in reverse. No, this wasn't happening with MakerCAM.

In order to actually control my machine and run my hologram-groove CNC programs to create actual metal surfaces I needed a program that would drive my GRBL-based CNC machine. Among the popular online communities there are a few recommendations that seem to satisfy everybody's needs. Unfortunately, I had no luck with these suggestions because they were not suited for massive g-code programs with tens of thousands of lines of code. These programs could only handle *maybe* a thousand lines of g-code at a time, which was useless for specular holography purposes.

Lo-and-behold, I managed to come across grblControl, which is a relatively newer GRBL controller program that features all of the bells and whistles of the other popular programs with the exception that it runs FAST. It can handle the largest of g-code programs I can throw at it, without breaking a sweat. To anybody using a GRBL based CNC I highly recommend you check it out. It is the only program I have used with my CNC, ever.

It is simple, efficient, and has plenty of features that make machining as painless as possible (which is still rather painful, but at least grblControl doesn't contribute to the pain).

There were a few things that were not exactly desirable about grblControl, but being that it is open source I was able to install and load up QT-creator and dive into the code and start making my own custom version of it. The first thing I opted to change was the fact that it operates strictly in metric, and all of my experience, expertise, and tools are designed for imperial. So, after some hunting and pecking I made my own imperial version of grblControl.

Aside from that I have made a slew of other changes, visually, and also functionally, just to get grblCotrol to be best suited to what I am trying to accomplish with it. Thus far I am really happy with where it's at now.

After a while it became apparent that if I were to have finer control over how the grooves were being cut I would need to implement functionality in Holocraft that would directly output g-code for a CNC machine, and completely obviate the need for any CAM software to generate the toolpaths in the first place.

The way that MakerCAM was interpreting the SVG files was random, at best. I could not rely on the fact that just because a path was defined going from point A to point B that it would be machine in that order. In some cases it seemed to make weak attempts at optimizing the toolpath by alternating directions between successive optical grooves, where when it ended cutting one groove it would then move up to the end of the next groove and cut toward the starting side of the groove definition, but there was no metric by which to reliably cause this to happen, or not happen..

As it stands, my machine has issues with machining holograms (or metal, as it were) due to the mere fact that when it is cutting in the Y+ direction (cutting away from the front of the machine) the leverage on the gantry causes it to lift up, which effectively prevents it from cutting as deep as it is supposed to because it is too friendly to the surface when moving in the Y+ direction.

Conversely, when the machine is cutting in the Y- direction, the gantry leverage just sucks the tool down harder and deeper into the material, gouging it much deeper than would be intended. The end result is that I must cut my holograms with the grooves being formed in one direction along the Y axis. I chose the Y+ direction simply because I'd rather have lighter grooves than inevitably and irreversibly deep gouging grooves that are formed otherwise.

This was discovered when originally cutting holograms where the grooves were traveling from X- to X+, in a left-to-right fashion. What was happening was that the left side of the groove (traveling in the Y+ direction while moving X+ rightward) was lighter than the groove was on the downslope traveling in the Y- direction. This is purely a product of the design of my machine, which was not designed to be used as a sort of drag-engraving machine in the first place, and so ways and means have to be put into place to work around this weakness of the machine.

Another issue that arose was the resolution of the machine itself. Was the X-Carve even capable of distincting grooves into the surface of the aluminum without there being obvious stair-stepping resolution artifacts? Well, we are running with 20-tooth pulleys on 2mm pitch belts means one revolution is 40mm along the belt.. With 200 steps per motor shaft revolution, with 8x microstepping, should be at 40mm / 1600steps =  0.025mm.. Therefore, we should easily have a resolution of at the very most .001" of an inch for our grooves, which seems plenty fine provided that we are malking those grooves fast and smooth and not moving to each exact increment of the motor to scribe the metal's surface.

Now, in practice, what I've found is that running the machine at the highest possible speed (going into GRBL config via '$$' command and playing around with max speeds and accelerations while tweaking the power dials on the gShield going out to the steppers) I've managed to get my CNC to fly like none other. The problem is that when I exert force into the surface of aluminum with a carbide bit at such speeds there is enough leverage at play to allow for what we in the States refer to as 'speed wobble'. This is not a machining term, this is something that happens when you are flying down a hill on a bicycle or a skateboard and your rate of speed just becomes too much.... Too.... Much... The end product being that your handlebars or skateboard begin resonating side-to-side uncontrollably so until the point that a crash of some kind is usually inevitable.

In this case, it results in wobbly little grooves, which are exactly *NOT* what we want, because we are trying to scribe optically accurate/useful grooves into the surface of the aluminum.

So, it has become a balance of slowing the machine down to minimize the wobbles as much as possible, without sacrificing speed, and without introducing a sort of stippling that arises from the actual machine position increments manifesting themselves in the grooves themselves, which are equally as ugly when it comes to optical applications.

Playing with the depth of the groove and the speed at which it is formed has been a bit of a journey, as well as taking other measures to mitigate the 'wobble' by raising the workpiece closer to the gantry to minimize the leverage that the tooling edge has against it. Stiffening up everything on the machine has been another project as well.


Here is a low-fi video of a hologram I have been working on for my younger sister, for her birthday. When I can manage a better camera I will (feel free to donate!).

Here is yet another video of another test hologram featuring some random abstract cuboidal shapes merged together in a sort of splatted configuration. Again. feel free to donate better camera ware!

Links:

IKEA TARENDO Table - ikea.com
Konmison 300w Spindle Motor with PSU and 13pcs ER11 - Amazon.com
MakerCAM - makercam.com