Octtree output format with normals and inproducts on end 'partial' cubes.

[o-jasper]

Excellent program! The nearly-openscad input is a very good idea, too. It'd be crazy if this wasnt successful. I think the program being on windows and in the linux distro repositories matters too, though.(Its already in the AUR, at least)

Anyway, being all annoyed with .stls being broken and slicing badly(or the slicer being broken, hard to tell), i was wondering why we're using a potentially ambiguous format in the first place.

I implemented a poorly tested and now defunct CSG in Julia using an octtree and the ability to determine if a convex object(like a matrix-transformed cube) is inside, outside or partial other objects. So it comes naturally to me to think of octrees.

But that would leave the edges 'steppy', requiring high resolution with poor information on normals,(though you could infer) probably it would be better if the 'partial' cubes of the octtree have a normal and an inproduct, and 'inside' is normal⋅position < inproduct, or probably better, some kind of interpolation.

As far as i can see(admittedly mostly based on the essay from the FAQ), your approach could work with outputting this file format? The idea would be that the 'partial' cubes of the octtree are those where the function is zero inside and the normal is the gradient of the function,

Now that i think of it, though, it doesnt strictly need to be an octree. Probably should pick a data structure that will work well with slicers or converters to .stl afterwards though.

I realize you just have limited time, so consider it 'just throwing in an idea'.

[julialongtin]

.. And 8 years later...

I'm in the middle of writing a slicer, and am using .stl to start with.. but as i want to break the layers always being on top of one another, i'm looking at making implicitcad something the slicer can talk to, to get a contour, or a surface description via an RPC call.