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

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
> (http://people.bath.ac.uk/ensab/G_mod/Svlis/), which implements all
> these operations, to drive RepRap version 2.0...

Interesting!
Received on Sat Dec 09 00:55:50 2006