STL to 3d array

Hello all,

Ive had a quick look at the code and i thought before i reinvent the wheel i'll check if someone else has done it.

has anyone written any code to turn a stl file into a 3d array?
or does anyone know how it would work? and maybe would be kind enough to write some rough persudo code for me?

I know the java code works well but im trying it in C, well C# (just for the user interface) and i know a 3d array will take up alot of memory but its easer for me to manipulate , and would really help me not only try out new filling pattens etc but make life alot easer to work out surport structures!

Anyhelp would be great,

Noz

A 3D array of what? The STL is a 3D description of a solid object.

Can you tell me a bit more about what you have in mind?

simply a 3d array,

each element in the array is either 1 or a 0, depending if that space is filled with the the object or not. so the 3d array is in reality a representatoin of 3d space which the object will inhabit.

for example sake say we have an array 100 by 100 by 100, each element is 1mm. meaning are reselutoin is 1mm. then say i want to build a cube in the corner, for arguemnt sake is 2mm by 2mm by 2mm

so

(1,1,1)=1;
(1,1,2)=1;
(2,1,1)=1;
(2,1,2)=1;

(1,2,1)=1;
(1,2,2)=1;
(2,2,1)=1;
(2,2,2)=1;

in the array is 1, the rest are 0.

Hope you get the idea of what im after.

Yeah, I get the idea. Got lotsa DRAM do you? The usual resolution of a Darwin runs about 0.1 mm. Suppose you have a print that occupies a volume of 5x5x3 cm. You are talking about 75 megabytes just for that. If you have a print volume of 300x300x150 mm you're talking about an array 1.35e10.

gotcha, not possible.

Very annoying, Although large would of made alot of stuff hell of alot easer.

Need to have a rethink.

thanks for the info though, im sure i'll come up with a equally impossible idea tommorow.

They're not all impossible. Even that one is not impossible if you map the array onto your hard disk. It's just a little slow.

Just have a hard time relating to the way it works, normally i look at code but im useless at java so i aint got a clue, i want to put my own bits and pieces in to add functoinality.

Medical MRI data is stored exactly like that. So it is very possible. One way is by using octrees [en.wikipedia.org]. They only need high resolution at the edges of the solid.

--Blerik

Trying to figure if that would work for the reprap.

brain hurts..

Octrees are nice things, in that they're pretty easy to understand and code.

If you're going to slice the model up anyway (for reprapping at least, though perhaps not for milling) you can store each layer as a quadtree instead, which is twice as simple.

The reprap host does all sorts of terribly cunning things which are not yet fully documented, and so are a bit of a pain to understand from reading the code alone. Perhaps you might have better luck looking at the work Enrique has done on Skeinforge? If you search the forums, there will be links to useful places to download a copy.

Any thoughts about using multi-page tiff (or other image file type) to store 3D model data.

Using an existing image format to store the 3D data would:
1. Enable using an existing image viewer to look at the individual layers.
2. Leverage the compression algorithms already developed for 2D images
3. Allow the use of different colors to represent different materials (main material, support material, etc)

It would still be computationally expensive to operate on the data as a 3D array but it would be simple to extract the data in that form from the image file if one wanted to.

This format could also be used as an intermediate file for printing. Eliminating the need to parse the 3D data at the time of printing.
[forums.reprap.org]

During printing the REPRAP host software would calculate a fill pattern for each layer as it is retrieved. If the data was higher resolution than the printing capability of the REPRAP layers could be skipped or boolean operations could be performed on adjacent layers.

Scorch

Quote

Any thoughts about using multi-page tiff (or other image file type) to store 3D model data.

This will rapidly become enormous in size.

What is wrong with STL, anyway? It isn't exactly ideal for our needs (a more abstract constructive solid geometry model would be much nicer, for example) but on the other hand it is widely support and, all thing considered, pretty easy to parse and manipulate.

The textual form will zip up quite nicely, because it is text. The binary form can also be archived, but it s already signficantly shrunk compared to the textual form.

Because of the way it (should) define objects, large yet simple objects will not result in an enormous file, whereas standard image file formats will grow proportionally with scale. Vector image file formats would be fine, but all they're doing then is replicating the exact same functionality found in STL.

Admittedly, a multipage 2d vector image format would be a sensible way to store non-infilled layers, perhaps. But no-one seems terribly interested in intermediate formats right now.

STL is a vector based format, what is it that you are trying to do that requires a 3D raster? If you really need to plot it to a raster you could work with one layer at a time, and make sure the old one is deleted from RAM before you start the next one.

Ru Wrote:
-------------------------------------------------------
> Admittedly, a multipage 2d vector image format
> would be a sensible way to store non-infilled
> layers, perhaps. But no-one seems terribly
> interested in intermediate formats right now.

I am, I have been continuing to develop an XML / polygon based toolpath format that only takes up about 10-20% more space than gcode

Quote

I am, I have been continuing to develop an XML / polygon based toolpath format that only takes up about 10-20% more space than gcode

Good stuff. I think intermediate formats are a good thing, as they allow a nice modular toolchain; something we lack at the moment.

My Slice and Dice software produces an XML formatted intermediate file as well. The nice part is that you can, if you need to, edit an intermediate file format.

My main reason for wanting a 3d array is to automate scaffolding, to surport whatever im building and to make it easer when we add new things , like milling (which i will attempt) and pick and place etc. if we had a differnt format we could use several files to make one "blueprint" with layering,milling,electronics etc all in it and all automated. Im thinking if we use a milling machine we can lower the resolutoin of the array and then use a more precise raster process to finnish it, and scince the plastic can be reused it should be effiecent.

Noz Wrote:
-------------------------------------------------------
> My main reason for wanting a 3d array is to
> automate scaffolding, to surport whatever im
> building

I'm working on that, but I am only using a grid for one slice at a time.

I have figured it out how to do some bits in an 2d array or bitmap by using nearest neighbor routines, like the scaffolding , but cant be 100% that they will not ruin the overall affect, Also milling may become a problem as it will have to cut the supports off and figuring that out could be complicated.

problem with using slices is that its less computatoins but still trying to fit a 3d object into a 2d box .

Ive designed my reprap but i dont want to build till i have a better idea overall how its going to work.

Oh yeah and i figure it can have a 1000 by 1000 by 1000 mm array in 0.116415322GB/119.20929MB with 1mm tollerance. Reast can be taken care of by the milling by using rasters .
should be able to get better than 0.1mm tollerance !

Edited 1 time(s). Last edit at 07/01/2008 11:57AM by Noz.

I'm frankly not interested in turning Reprap into just another CNC machine.

I apologise if i was blunt or rude.

I dont quite understand what i said that implys i want to turn it into anouther CNC machine. Guessing its over my head.

Once again i apologise , i just like to make things (mostly robots and furniture) and i hoped that i could help the reprap project.

Heavens! No need to apologise! I was just expressing a personal opinion. When I see what Nophead is accomplishing with just extrusion, I can't see complicating Reprap with CNC demands.

[hydraraptor.blogspot.com]

Ahh!!

Get back to the origins of this thread, i hoped a 3d array would make everything much simpler! we use STL files,triangles,math and Gcode etc feels messy.
The current way might be best, but i will try in vain to improve non the less.

Objects are designed as vectors, and the RepRap machine prints things as vectors. Rastering and re-vectoring is only normally a last resort because it is inherently 'messy' process.

Oh good lord. This turned into an enormous long post. No ranting intended!

Quote

problem with using slices is that its less computatoins but still trying to fit a 3d object into a 2d box

Doing filament deposition in 3d would be possible, rather than doing it in a succession of 2d layers. But there are a few little problems. Firstly, you still have to build upon existing material, and if you're making an infilled object what you're building upon is going to look suspiciously like a bunch of 2d layers.

Secondly, unlike a a mill which is (forgive the generalisation here) going to be cutting using the edge of a tool, or the face of a tool, filaments are extruded from the centre of the reprap tool. This means you can squeeze it into, say, the angle between a horizontal surface and a vertical surface. You have to build up in layers to prevent toolhead/material collision.

You could, in theory, have some kind of scary 6dof platform (like a hexapod) that would allow you to deposit on an abitrary position by tiling the whole model, I guess. But the kinematics behind that, whilst quite cool, are going to be fearsomely complex.

So, if you're doing additive manufacturing in the way we are, layers are what you're pretty much stuck with. Its not a bad sacrifice to have to make, I'd say, considering the quality of what it can produce.

Quote

My main reason for wanting a 3d array is to automate scaffolding, to surport whatever im building

I was thinking of computing scaffolding by using a ray-tracing type method. Shoot rays vertically downwards from above a model, and compute the shadow volume underneath. Then you've just got another polyhedron which you can slice and dice as normal.

It isn't as programmatically simple as filling in a big 3d array, but it has many advantages, not least of which is the fact that working with vector shapes is hugely easier on RAM than working with quantised things in an array. The maths behind the process aren't that complex either... basic raytracers are quite simple programs.

But without a suitable scaffolding material, this is all a bit pie in the sky.

Quote

Oh yeah and i figure it can have a 1000 by 1000 by 1000 mm array in 0.116415322GB/119.20929MB with 1mm tollerance

Sounds kinda lumpy, but I guess if you're going to do a finishing pass with a mill that won't matter.

That memory usage assumes 1 bit per volume element. I presume you will only be using one sort of material, then? Consider: support material, construction material, stuff to remove via milling. Suddently its tripled, and you're punting around great hulking lumps of ram which isn't going to be particularly efficient.

If you want to have other materials, like conductive circuitry traces, it goes up by another 120M.

Quote

STL files,triangles,math and Gcode etc feels messy

Vectors are nice things to work with. They don't develop aliasing, which a raster-based system is going to. They're nice and easy to manipulate mathematically. They're quite compact, memory wise.

Also, filaments are continuous things, not discrete blobs. Milling toolpaths likewise. This is why gcode is a perfectly good way to define them.

I'd go on about tracing long routes in say, conductive material in one pass, and then switching to a different toolhead to deposit bulk material around it rather than continuous changing as you traverse the array and find the next element is a different material.

But I've gone on for far to long already!