Hello Steve,
Firstly thank you for the spline file. I have fixed that crash in the current development release (not long now till I release it) and it behaves much better.
The main focus of coming development now is to sort out any crashes, bugs, glitches and usability issues so I really appreciate all and any bug reports like this.
Splines are actually NURBS (beziers are a subset of these). They are very versatile and can be used to store and approximate many mathematical curves and also natural shapes.
The ultimate problem we face for CNC is that typical gcode only supports straight lines and circular (or helical) arcs.
So to convert splines to gcode you must either digitize them to lines with many small segments (a common approach), or try to fit arc and line segments to it (as I try to do in CamBam).
A Polyline is simply a linked line with straight or circular segments which corresponds nicely to the gcode requirement...this is why all the drawing objects ultimately end up as polylines before generating toolpaths from them.
Fitting polylines to splines can not be done precisely. Under Tools->Options, there is a parameter called
SplineToPolylineTolerance. The default 0.001. For many spline files (especially when using mm), this is much too small and something like 0.1 may be more appropriate. Basically this is the maximum error allowable when trying to fit a line or arc into the spline. Smaller tolerances result in many more smaller segments needed.
There is another setting in Tools->Options called
SplineCurveSteps. This is used for displaying splines only. If you reduce this number you will see the splines appear more jagged. However, when you convert them to polylines they will use the tolerance value and regain their curviness.
In the later free versions, a bug crept in that used the general tolerance for SplineToPolylineTolerance, which is why the free version appears to hang with splines. It is basically trying to fit circular arcs to a ludicrous precision.
Like you, I think there are too many drawing entities to confuse things. My future plan is to make lines, arcs, circles, rectangles and splines all just types of polylines. The way you edit the polylines would vary (center+diameter for cirlce, control points for splines etc). There would be no need to do conversions to polylines as this would be done when needed by the program to a set tolerance.
Lastly a bit about regions...
Regions, like a number of other features, currently only work from polylines. As polylines are so fundamental to gcode and CamBam, I usually get routines working with those then go back and add code to do any conversion from other types.
Sometimes I get distracted and these internal conversions remain on the todo list. This is another good example of the type of issues I am now concentrating on ticking off.
The need to use Regions has now been greatly reduced.
In CamBam plus, you can now just select 2 (or more) concentric circles (or closed polylines, rectanges or splines), insert a pocket and it will auto detect any regions needed.
The only real need for Regions at the moment, is for profiles, so that CamBam knows whether it should be swapping the inside/outside cuts for inside shapes.
I hope that explains things a little.
Hopefully some of the more dumber and crashier parts of CamBam will start disappear soon.
