Okay, I'm a CAD software developer instead of an actual CAD engineer, so my perspective may be a bit biased. But this CSG (constructive solid geometry) idea is not in any way new. The reason it's kind of obscure now is that spline-based boundary representation systems (B-reps) took over the market decades ago. If you think about, say, the latest car designs, those free-flowing shapes are pretty easy to do in B-rep, and quite hard in CSG. [1]
I've worked in CAD translators for the last two decades. Though both the IGES and STEP file formats include CSG modeling features, I have never implemented them. To the best of my recollection, I've never even had a request from a customer to do so. A pity, I think they'd be fun to try to implement... and most of the thorny bugs would officially be the B-rep geometry kernel's, not mine. :)
And Auto-CAD had a Lisp engine in the '80s ... You could automate almost any function of the drawing system, build "macros" as well as patterns and even alter the DXF generation.
I think it was release 2.18, retroactively named R6 maybe. John Walker and I hacked up a p.d. thing called xlisp by David Betz, removing some of the best bits (the 'X' parts) and fitting it into its own 64k 'small model' (x86) segment. I was a bit of a lisp nut, but even I (product manager at the time too) thought lisp as a 'macro language' for AutoCAD was a tinge crackers. Glad we did it though!
Yes, according to the timeline, it was 2.18, but it lists 2.1 as R6, so despite it's huge impact in allowing the creation of tools like AEC-Architectural it apparently doesn't get its own integer. As a scripting language it seemed to me a pretty good choice, because sat reasonably well with the command-line based interface in that it somewhat reflected its <command> <argument>* format.
And of course in the 1980's Lisps were tech's "the sharing economy". One of the reasons I went to vocational school to study drafting was to get my hands on AutoCad to get my hands on AutoLisp to get my hands on a Lisp. In 1991, I was doing timed Cad competitions using R10. My secret weapon was twenty minutes writing my own "PGP" command aliases in AutoLisp with edlin before I started drawing. That's how I won my copy of R11.
> And of course in the 1980's Lisps were tech's "the sharing economy". One of the reasons I went to vocational school to study drafting was to get my hands on AutoCad to get my hands on AutoLisp to get my hands on a Lisp. In 1991, I was doing timed Cad competitions using R10. My secret weapon was twenty minutes writing my own "PGP" command aliases in AutoLisp with edlin before I started drawing. That's how I won my copy of R11.
That sounds like a great story. Would you consider sharing it?
"Lisp?!?! Why the Hell did you pick the most arcane, obscure, and hopelessly-rooted-in-the-computer-science-department language in the world for an AutoCAD programming language? Over the next six months, all of us will have the opportunity to answer this question."
That was in 1985. Not so much has changed in 30 years :P
You can still run Lisp commands on the commandline interface in AutoCAD. Or even as you type out command inputs. So for example, if you know that you just put in 187 for length, but the next line needs to be double that, you can type (* 2 187) when it's time to put in the length and AutoCAD calculates it.
I thought they turned it into a license feature (so LT doesn't have it, only the full version does)?
But yes, I found AutoLisp to be very useful for automating things. The place I used to work for had to have the CNC machines cut out differently sized shapes from a library of shapes, so I created functions to draw each library shape for me quickly.
This is a lot easier than trying to form four mutually tangent circular arcs into an oval by constructing everything by hand.
LT is the follow on to AutoSketch and marketed to those who don't find value from working in 3d. AutoDesk upbranded the product and raised the price point when they renamed it, and a lot of people who say they use AutoCad are using LT "instead". In fairness, there are a lot of people using AutoCad with color based plotting (style based was introduced with Acad2000 in 1999) and who don't use those "new features" like Paper Space and Xrefs (introduced in r11 in 1990). Making things is very much bound by traditions.
To be honest, when I used it, AutoLisp was really the only feature I cared about other than drawing basic 2D shapes. You could have left me with only points, lines, arcs and dimension text, as long as I had lisp to automate it all.
You are correct. I describe AutoCad LT as either "Fisher Price" AutoCAD, or AutoCAD without the useful stuff. Most people that use AutoCAD might as well be using Etch-A-Sketch...
I know... I had a hard time once trying to explain that the newer LT version was completely worthless to me because I needed the AutoLisp from the real version and that the "upgrade" gave me no useful features and merely made it impossible to automate anything.
Sure, I could construct everything by hand, but that's pretty unreasonable when I'm redoing the same basic shapes all day.
Well, those shapes are hard to accomplish with a CSG of primitive shapes at least.
This isn't really "plain CSG" though. I think it uses distance fields (a tree of distance functions), which can be of any kind. The simples ones are just primitives, but anything that has a defined distance could be used, including parametric surfaces, fractals... (If you are using it for actual CAD and not just visualization, you probably want to be able to triangulate though). These distance fields have some neat features when rendering, such as blending, which is hard to do with classical CSG:
http://iquilezles.org/www/articles/distfunctions/gfx18.png
(from http://iquilezles.org/www/articles/distfunctions/distfunctio...).
Yeah, but how difficult is it to make a distance field with the same versatility as a spline which lets you drag its surface, explicitly add seams of lower continuity (which are important out past the second derivative for reflections), shell a surface to uniform thickness, etc?
Blending shapes is neat trick but the market cares most about fundamental operations and it seems to me that the fundamentals are harder to implement with CSG.
Yes, it's definitely a tradeoff. I wouldn't think distance field modeling will ever be mainstream in design for manufacturing, just like CSG won't be. They are mainly useful in direct visualization. There may be lost of niches such as content creation for gaming etc where other representations can be useful.
Antimony does general implicit surfaces, not just CSG with Platonic primitives. So it has operations like "morph" https://github.com/mkeeter/antimony/blob/develop/py/fab/shap..., "blend" (for fillets!), and "shell", and it seems like it would be pretty easy to add metaballs, although Matt doesn't seem to have done them.
I think you missed his/her point... OP wasn't saying that Bézier curves in car models were something new. What OP said is that (as an example) latest car desings are hard to do with constructive solid geometry but easy to do with B-rep
Haha! Smiles from the town of Béziers, Hérault, France... apparently no direct relation to the curve. From the AMS:
Bézier curves are ubiquitous in computer graphics. They were introduced implicitly into theoretical mathematics long before computers, primarily by the French mathematician Charles Hermite and the Russian mathematician Sergei Bernstein. But it was only the work of Pierre Bézier, an employee of the automobile maker Renault, and of Paul de Casteljau, of Citroen, that made these curves familiar to graphics specialists. Recently, the polynomials defined by Bernstein have become again of interest to mathematicians.http://www.ams.org/samplings/feature-column/fcarc-bezier
Wikipedia expands:
Bézier curves were adopted as the standard curve of the PostScript language and subsequently were adopted by vector programs such as Adobe Illustrator, CorelDRAW and Inkscape. Most outline fonts, including TrueType and PostScript Type 1, are defined with Bézier curves.http://en.wikipedia.org/wiki/Pierre_B%C3%A9zier#B.C3.A9zier_...
... though almost certainly CorelDraw (and Quark xPress?) came before Illustrator, and PostScript's popularization came through the rather embrace-and-extend PDF format it spawned.
FWIW, I have fond memories of doing CSG with Povray - http://povray.org/ - as an 11 year old. When the supply of new DOS games ran out, it sure beat writing batch file viruses, the other primary form of entertainment.
Illustrator was released in 1986, CorelDraw in 1989. I'm not sure why QuarkXPress is included (it is a page layout/desktop publishing tool, not an illustration tool), but it was released in 1987.
Postscript became popular[1] well before any version of the PDF format existed. It was popularized by the Apple Laserwriter, the first printer to natively support it.
[1] Well, I suppose it depends on what one means by 'popular'. I think creating the desktop publishing industry counts; YMMV.
From a marketing standpoint where everyone dreams of out Frank Ghery'ing Frank Ghery splines rule, but CSG is probably well suited from a practical standpoint for representing the walls and windows of the architecture that typically gets built.
The problem of course, is that once there's a column with acanthus leaves, splines are the way to model its details and a WYSIWG needs them. For architecture, splines are in the aesthetic details, but constructive solids are a good tool for representing the important part of the constructed solids that are buildings.
I think the major problem in CAD/CAM software is the creation of technical drawings.
I enjoy every new CAD program (solvespace, implicitCAD, nanoCAD, ...) when they come but each time it lacks this vital function. Even fat dinausors like CATIA, Pro/E, Inventor & co have a very poor ux at that level.
So I will recommend to master the rules of technical drawings and geometric dimensionning and tolerancing before going to deep in 3D. Likewise, BRep, CSG, constraints solvers, code/GUI will be just straightforward "plugins". It's safer and more useable in real life.
By the way, the Purdue University have some good innovative lectures, ie. Erep [1]
Computer Aided Engineering Design by Anupam Saxena & Birendra Sahay is cool and informative.
In general, the Indian Institute of Technology of Kampur [2] has some pretty intense books on the subject.
Finally, Knowledge-based engineering [127] will extend a lot your future awesome opensource haskell CAD package!
Having used OpenSCAD, Solidworks and NX fairly extensively, I can say that "code-based" solid modelling systems are good for some specific things - anything that is highly parametric, for example:
For anything else they aren't at all suitable. It's just a million times easier to be able to click on dimensions on the actual sketch and change them. You're never going to see a power tool or a tractor or whatever designed in OpenSCAD.
Few 2D drawing programs are specified in code - the only ones I can think of are things like TikZ for Latex, and ... well there's a reason only Latex geeks use them. They aren't very easy to use.
The main reason they exist is that it is much (like 100 times) easier to write a code-drive CAD system than a GUI-driven one.
> The main reason they exist is that it is much (like 100 times) easier to write a code-drive CAD system than a GUI-driven one.
The reason they exist is because they are very well suited for making changes on the model ... on shallow and deep level. It might be easer to "click on dimensions on the actual sketch and change them" for a few elements, but try making a fundamental change without code.
GUI vs. code/config file preference seems to be a personal disposition not only for CAD but for all kinds of software.
A parametric modeler, i.e. every major CAD system in use since 1995, allows you to specify your dimensions based on formulas that use relationships between components. If you look at Solidworks or CATIA and think "man it must be slow to point and click to set dimensions" you are missing how it is actually used in professional practice.
The difference between point and clicking dimensions in those tools and how they are supposed to be used is greater than the difference between pecking in Notepad and being a power user in Emacs/Vim.
Exactly my point. "Based on formulas that use relationships between components" means that they have internal language which if used well helps enormously.
Being a career software developer who has recently learned to use parametric CAD (specifically, Geomagic Design, formerly known as Alibre Design), this is just not true. On the software side, I'm one of those who generally prefers code vs. GUI config. But that's an utterly terrible analogy to parametric CAD, which is really a touch closer to a kind of end-user programming language.
Parametric CAD is far better about keeping relevant dimension values, formulas, and model constraints right where they're relevant and trivial to visually comprehend in terms of their function in the model.
A better analogy for the uninitiated would be the frustration of a spreadsheet where the cell values and formulas had to be edited on some entirely separate text code UI sheet, requiring flipping back and forth and holding stuff in short-term memory to do anything to the model.
That said, I'm actually quite interested to play with Antimony. At first blush, it looks far more appealing than OpenSCAD for practical applications. Over time, it's UI might be able to converge functionally to the mature CAD packages, but allow for greater insight into how the engine is really building up the model, especially in complex projects. Constraint debugging in parametric CAD can occasionally be a frustrating kind of hell. Antimony and/or its descendents may be able to help out with that.
"You're never going to see a power tool or a tractor or whatever designed in OpenSCAD."
I beg to differ on this, I've been using OpenSCAD for a couple of years now, and the two most complicated designs I have done were for a dual drive robot base and a simple 3-axis CNC machine. Many of the parts were COTS (which I built modules for) and the rest were designed for these projects, including some parts which were sent directly to my 3D printer. In doing this, I've been developing various functions and modules that simplify common operations such as attaching two separate parts and using difference to form a free fit hole for a specific type of screw. I find this to be much easier than clicking on dimensions in a sketch, but this is because I have all of the mental habits developed by learning to build complex software.
My last job, at a CAD company, we had a competition to see who could create the coolest models programmatically using the new Javascript based scripting language we were creating. My entry was a library that could generate Lego pieces, which I used to build a Lego truck. I can't find a pic of the full truck, but here are some samples:
Anyway, as much as I enjoyed creating the truck, the reality is that a decent mechanical engineer, experienced in SolidWorks, CATIA, or other parametric CAD, could have built the truck in a fraction of the time that it took me. Furthermore, I'm pretty sure that even I would have been faster in a parametric modeler, and I'm a software engineer.
EDIT: I should also mention that the Javascript binding was primarily for developers to test out the modelling kernel's API, rather than creating actual parts.
i also use open scad, but mostly because solid works is too expensive (and i like to have my data on a free format, human readable if possible, always)
i bet if you look at your design code, most of the parametrization and solid are there just to work around the fact that you can't tie one side of a cube to another.
to me at least, that's the killer feature that open scad lacks.
The ideal would be both worlds. 3D editor until you want to go in and change specific relations, which would be specified in code. Like editing an SVG or hand-editing its source, it's useful to have the option depending on your toolset.
The issue isn't whether you're editing text or visually interacting. It's that there's a tension between abstraction (parameterized models) and WYSIWYG editing.
I really like the idea of OpenSCAD, but the language is just unacceptably crappy. It's still better for me with my habits than anything graphical, though. If it had better capabilities for abstraction I think it'd much more suitable for large, complicated objects than a graphical editor.
The main reason to use "code-based" solid modeling systems is it allows the use of version-control systems. We don't have things so powerful with traditional CAD.
There are some GUI-enabled CADs, but their users still prefer to script their designs instead. This applies to the specialised large-block CADs, like those for plant building, ship building industries and such.
Increasing the level of abstraction makes it more rewarding to express the designs in code instead of dragging things with a mouse.
Looks nice. I have been working ten years professionally developing a CAD program, and if I could time travel and give my ten years younger self a single tip it would be to use a proper geometrical kernel (like CGAL) rather than doing anything with floating point.
Thanks, I didn't realise that. Unfortunately, I wasn't looking to charge for my app, so a commercial license isn't feasible for me. As far as I know, GPL3+ is incompatible with the iOS App Store, so that's out too.
Certainly, but they're charging €1000+, so it isn't really an option for me. I'll just re-write the parts I need. I'll just almost certainly do it worse, and it'll take more time, that's all!
Yes -- the images being drawn in the "3D" viewport are actually 2D bitmaps rendered directly from the f-rep then blitted to the screen (with a pixel shader that does proper depth culling on a per-pixel basis).
This is really nice. Seems super easy to use, unlike other CAD/3D modelling software I've tried before. I think a lot of software could benefit from this 'timeless' graph/node based approach, rather than most UI's which only let you see the latest version with a long undo chain. It reminded me a bit of Bret Victor's drawing tool[1] too.
Only problem, to me, is that it seems like a lot of work to get a UI like this off the ground. It'd be lovely to see support of a node-based UI built into some common UI frameworks.
> Antimony is a computer-aided design (CAD) tool from a parallel universe in which CAD software evolved from Lisp machines rather than drafting tables.
Funny, I'd be way more interested in the software engineering tools that are inspired by drafting tables than the mechanical engineering tools inspired by text editors.
If you spend some time with anyone proficient with the big CAD/CAE programs you will see how efficient they are. OpenSCAD and others are familiar to programmers so they are easier to learn, but if you learn CAD/CAE software they make text editors feel clumsy and slow. For an added bonus, use one of the input controllers specifically built for CAD/CAE, it opens a whole other world.
Drafting table style software engineering tools have been around for decades. It turns out that the only ones programmers actually want to use are the ones that deal with something that is actually visual/geometric, i.e. the layout of graphic user interfaces, so those are the ones that were kept; that's how Visual Studio got its name.
Nowadays when you need to cater to web browsers and mobile devices with a large range of screen sizes, even those are largely eschewed because the layout has to be redone at run time anyway. But there are still some in use by people who work on fixed size form layouts.
OpenSCAD is functional (mostly), but it could have been great if they hadn't invented their own language. Then you could have had fancy features like error messages.
It uses a homebrew kernel based on functional representations (http://en.wikipedia.org/wiki/Function_representation). Any function that comes out the end of the graph is rendered (as a bitmap) and blitted to the screen.
I like the interface, and being a Blender3D user, I like nodes.
However, I am long AutoCad / Inventor user, and I don't see what's new. You could do CSG modeling in AutoCad with union, difference, and intersection, and in Inventor you have that and sketch-based parametric modeling; update the sketch, and the model changes. Go back in the history, and change a value, and the model changes. In AutoCad you could use AutoLisp and later VBA. So aside from the look of the interface, and nodes vs. a history hierarchy what distinguishes it from decades-old parametric modelers?
True, but I was addressing the 'novelty' observation made, not cost and licensing.
I do like the look of it.I just think it has been available, and is not new. Even the tease of Lisp machine when it has python in the background, not Lisp. For free, the now-opensource Solvespace [1] is a cool parametric 3D-modeler with STL check export and you can view some kinematic movement by dragging a constrained link in a linkage.
[1] www.solvespace.com
CSG driven by a hierarchy of operations is the standard approach in CAD today. SolidWorks and Autodesk Inventor both work that way. Here's an Inventor tutorial on modeling the wheel of a scooter.[1] I picked this tutorial because the part and the operations used are very similar to the the Antimony screwdriver example.
Antimony looks like a nice entry-level program for this sort of thing. It's way ahead of mesh editors. Those are for graphics, not physical objects. In a mesh editor, you can't move a hole cleanly. In a mesh, the concept of "hole" has been lost.
What you get with the big expensive programs is 1) a GUI that scales well when you need to design something complicated (people do jet engines in these programs), 2) a constraint solver, where you can specify constraints and let the system work out a solution, and 3) lots of additional engineering tools. It's nice to see the low end catching up.
This looks _very_ interesting (from a DIYer point of view), however building under GNU/Linux amd64 isn't seamless. (Missing --std statements in the Makefile, notably)
I find openscad quite painful to use, I whish I learned about Antimony before.
I think this has lot of potential, as a lightweigth, intuitive, free software, notably in the maker/diyer scene.
Looks like a Qt version skew problem; http://doc.qt.io/qt-5/qjsonarray.html suggests that in the current Qt, the QJsonArray constructors take either zero or one arguments, and the code is trying to invoke this one introduced in Qt 5.4 http://doc.qt.io/qt-5/qjsonarray.html#QJsonArray-2, while your installation of Qt5 seems to only declare a two-argument constructor and the copy-constructor.
You probably already knew that, but I think it means the cure is probably to install Qt 5.4 (or the prerelease 5.5) from source.
Do you see other compile problems if you run make -k, or just that one?
After updating qt5base-dev using debian experimental, and adding -fPIC to the CXXFLAGS, it compiled nicely :)
edit: there seems to be a slight problem with text rendering tho(only lowercase 'a' and bullet points are drawn), see http://imgur.com/MiX1hvL More of a qt5 issue I think
It's awesome how the nodes update as you drag things around in the viewer. I wonder whether there's a way to visually specify constraints (two points are coincident, two edges abut one another, and so on) instead of representing constraints implicitly through connections in the node graph.
This is neat, but from a usability standpoint most mechanical engineers prefer to work with draft style sketches rather than a node-based interface. Thus it is neat and impressive, but I am not sure it is what the consumers in the CAD market desire.
Well this is a CAD software from a parallel universe, you wouldn't know what those mechanical engineers from that universe prefer.
I'm a physicist and I only used one CAD software occasionally. In the CAD software I used I had to clone primitive objects to use them in multiple operations. If I wanted to change one dimension I had to update all the clones. Simply the acyclic graph model works better for this than the tree model. (Also some operations were irreversible, that was absolutely inexcusable.)
In 3D CAD it's usually a parametric geometric modeling kernel. Everything is reversible and changeable, it usually it depends on an tree/directed graph.
I just ran across your thesis a couple days ago while searching on representations for CSG. While I did not read it in detail, the representation seemed strange to me. I couldn't see how it can represent things like perfectly round holes.
BTW I was ray tracing CSG objects for RT chess back in 2001. Here's a pic:http://www.caiman.us/scripts/fw/f282.html
I implemented a primitive called quadratic lathe which took 3 points on a curve and revolved them around the vertical axis as an implicit surface intersected with a slab to limit the vertical span. Most of the chess pieces were created by sketching them on graph paper and putting the profile coordinates into code.
If you want to run it, beware of potential malware from sites that have it. Also, replace the SDL dll in there - somehow a bad version got in our original zip. I may not have source for the game any more, but the renderer has progressed a bit and now supports multithreading.
This is a really great question. I don’t know the answer yet. I struggle with this problem every day when I design things in OpenSCAD, because OpenSCAD doesn't give your parametric model access to the results of the modeling operations in any way (!!)
I think that Antimony kind of suffers from the same problem, but because it's using distance fields rather than plain CSG, it does have a “blend” operation (https://github.com/mkeeter/antimony/blob/develop/py/fab/shap...) that attempts to fillet the union of two shapes. Now, Antimony has inversion (complement, more or less), and set A \ B is just A ∩ B', which by De Morgan's Laws is equivalent to (A' ∪ B)'. So what happens if you attempt to approximate a filleted A \ B with invert(blend(invert(A), B))? I don’t know. But damn, I’m sure tempted to try it!
Of course, even if that works, that won’t fillet a specific edge resulting from the subtraction. It will fillet all of them. Invariably, that is what I want.
That makes a lot of sense. I wonder if you can hack this in with a little more CSG stuff: maybe union the blended version with some giant solid blob that covers the crisp seam edges, and then intersect the result with the fully-crisp version. That's a pretty indirect way to solve the problem, but I wonder if it might work?
To add a bit of historical perspective, AutoCad could be extended through Lisp (AutoLisp), back in the day. So I posit that this approach is nothing new and unlikely to be what the customers of CAD packages don't already have.
AutoCad can still be extended using AutoLisp. However, AutoLisp is one of several scripting API's rather than a "first class value" in the drawing database. AutoLisp also lacks a macro facility.
This is very interesting, there is definitely a big opportunity for CAD software that does things differently. A lot of the supposedly 'BIM enabled' and 'parametric' CAD software in use in the construction industry suffers from over defined and inflexible representations of real world objects, which often fail in the edge cases. I don't think software should be defining what it thinks a wall or a slab is or how they connect to each other, I think they should be giving architects and engineers better tools for defining and categorising these things ourselves.
Tangentally related... if you are a student... Solid works is ~$180/year... and autodesk software is free for 3 years from your enrollment. Haven't tried autodesk's offerings but Solidworks is unbelievably powerful software. It's incredible.
Guess what makes you a student? Any community college class. So go take a welding class.
The implicit surface representation is obviously great for 3D printing. I wonder if it would be suitable as input to a CAM system. (note: this is not a rhetorical question. I have no idea how CAM systems work.)
Huh, homebrew non-free license. I wonder if the intention was even to make it non-free. It does not allow commercial use, which is forbidden by default.
Oh well, at least homebrew licenses are getting rarer and rarer these days.
"Permission is hereby granted, [snip] including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software"
The right to sell the software is part of the open source and free software definitions. A license needs to specify this, because by default copyright law does not grant this right. This homebrew license does not allow selling the software, thus it fails to be open source.
Failing to meet this part of the definition is why MAME wasn't open source either until last week.
Anything not explicitly allowed is forbidden. That's how copyright law works. "All rights reserved" is the default. You don't even have to claim it. All rights are reserved unless you relinquish them.
> Anything not explicitly allowed is forbidden. That's how copyright law works.
Well, no, copyright law works by "anything explicitly made exclusive to the copyright holder by law, and not explicitly allowed by either other provisions of law or the copyright holder is forbidden, unless its in the rather ill-defined -- far from explicitly delimited -- domain of 'fair-use', or implicitly permitted by the copyright holder under implicit license, or..."
It does, but I agree that the author should choose an established license instead of trying to make one up by putting 3 lines in the README: https://github.com/mkeeter/antimony
I don't see anything that says that it allows commercial use. It says, "produced, modified, distributed, performed, and displayed for any purpose." Perhaps "for any purpose" is another catch-all for selling, but I'm not sure.
'Selling' and 'Commerical use' are not equivalent. For example, using CAD software to design a product that you subsequently sell would be 'commerical use' of the software, and would be encompassed by the 'any purpose' clause.
"Commercial use" encompasses selling. You are allowed to sell all free software and all open source. This guarantee forms part of the definition. Software that does not have permission to sell it is not free software and is not open source.
Like the windows version it is a single executable file, so just put it somewhere and run it. It's worth reading the reference from top to bottom. Fantastic little program.
I haven't found a free, native Mac CAD software that I like as much as Autodesk Inventor for Windows yet, but there are a number of free one available for the Mac.
123Design comes to mind [1]
You can also peruse the comparison of CAD software at Wikipedia. [2]
I've worked in CAD translators for the last two decades. Though both the IGES and STEP file formats include CSG modeling features, I have never implemented them. To the best of my recollection, I've never even had a request from a customer to do so. A pity, I think they'd be fun to try to implement... and most of the thorny bugs would officially be the B-rep geometry kernel's, not mine. :)
[1] http://en.wikipedia.org/wiki/Boundary_representation