Re: [rp-ml] CSG correctness. (LONG!)

From: steve <>
Date: Sat Dec 09 2006 - 01:59:14 EET

Adrian Bowyer wrote:
> Steve has eloquently articulated what I have thought for years.
> I would only add one further thing: instead of voxels, use an oct-tree
> divided to the RP machine's resolution. That would be much more
> efficient in time and storage.

An oct-tree is really just an efficient way to store a bunch of voxels -
a compression scheme to save storage space.

My plan was never to actually store the voxels - to scan one layer a
a time, generate the boundary and cross-hatching and drive the RP
machine directly.

But if that were too time-consuming - or if there were some other
compelling reason to store the voxel-based model - then for sure you'd
want to use an oct-tree.

> The oct-tree division of CSG models was pioneered by my old chum John
> Woodwark back in the eighties, and is perfect for this application.
> A closely-related, and maybe even better, alternative is simply to
> substitute z = 3.85 (o.w.e.) into the entire CSG expression when you're
> making the layer at 3.85 mm high. Then the model becomes an even
> simpler 2D CSG one, whereupon you do a quad-tree division in that plane,
> and have your RP machine zap the resulting bunch of rectangles.

Hmmm. I'm not quite sure how you'd do that directly - I need to think
about it.

I'm basically a polygon-guy because I work in graphics systems where we
don't care about the middles of things! For us, CSG isn't the way to
go because we don't care about holes and such - and we actually quite
like not to have to bother filling them in.

> Maybe I'll get my old SvLis CSG modeller
> (, which implements all
> these operations, to drive RepRap version 2.0...

Received on Sat Dec 09 00:55:50 2006

This archive was generated by hypermail 2.1.8 : Tue Jul 21 2009 - 10:27:52 EEST