video card choices mac osx speed

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

video card choices mac osx speed

terramir
Openscad F6 of a model can take hours with more complex models, I have the following choices HD 4k graphics on my main HD3k graphics on my sandy bridge laptop and GT220 on my second desktop. My question is the following what determines speed on F6 (which is needed to export STL) also I noticed when I do F5 on my Laptop 2357M 1.3 ghz i3 with HD3000 graphics a lot of stuff won't display with F5 for some reason but with F6 it will I'm actually better off using screensharing and using my old computer (the one with the gt220 so I can see what I'm doing)
Currently I'm actually processing a model it's already been over half an hour.
What is processing on macOSX the F6 modeling ? The graphic card alone? is my quad core doing really any of the work? since it's using like only 130 out of 400% 
would an improved graphics card help things along?

Need some knowledge here 
terramir


 
Respectfully,
R. Daniel Borkan
727 S. Coronado St. 201
Los Angeles, CA 90057
H: (213) 739-1863
C: (213) 271-6721
All written content of this e-mail is confidential and only intended for the named recipient. This message is subject to copyright and is intellectual property of the sender. All rights reserved (c) 2013 

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

nophead
I think I am right is saying the graphics processor affects the speed of F5 but only one core of the CPU is used for F6.


On 24 June 2014 14:25, r.d. terramir <[hidden email]> wrote:
Openscad F6 of a model can take hours with more complex models, I have the following choices HD 4k graphics on my main HD3k graphics on my sandy bridge laptop and GT220 on my second desktop. My question is the following what determines speed on F6 (which is needed to export STL) also I noticed when I do F5 on my Laptop 2357M 1.3 ghz i3 with HD3000 graphics a lot of stuff won't display with F5 for some reason but with F6 it will I'm actually better off using screensharing and using my old computer (the one with the gt220 so I can see what I'm doing)
Currently I'm actually processing a model it's already been over half an hour.
What is processing on macOSX the F6 modeling ? The graphic card alone? is my quad core doing really any of the work? since it's using like only 130 out of 400% 
would an improved graphics card help things along?

Need some knowledge here 
terramir


 
Respectfully,
R. Daniel Borkan
727 S. Coronado St. 201
Los Angeles, CA 90057
H: <a href="tel:%28213%29%20739-1863" value="+12137391863" target="_blank">(213) 739-1863
C: <a href="tel:%28213%29%20271-6721" value="+12132716721" target="_blank">(213) 271-6721
All written content of this e-mail is confidential and only intended for the named recipient. This message is subject to copyright and is intellectual property of the sender. All rights reserved (c) 2013 

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

drxenocide
How much work is involved in making parallelizing F6? I for one would love to have a reason to build a render farm of RPi's.


On Tue, Jun 24, 2014 at 9:44 AM, nop head <[hidden email]> wrote:
I think I am right is saying the graphics processor affects the speed of F5 but only one core of the CPU is used for F6.


On 24 June 2014 14:25, r.d. terramir <[hidden email]> wrote:
Openscad F6 of a model can take hours with more complex models, I have the following choices HD 4k graphics on my main HD3k graphics on my sandy bridge laptop and GT220 on my second desktop. My question is the following what determines speed on F6 (which is needed to export STL) also I noticed when I do F5 on my Laptop 2357M 1.3 ghz i3 with HD3000 graphics a lot of stuff won't display with F5 for some reason but with F6 it will I'm actually better off using screensharing and using my old computer (the one with the gt220 so I can see what I'm doing)
Currently I'm actually processing a model it's already been over half an hour.
What is processing on macOSX the F6 modeling ? The graphic card alone? is my quad core doing really any of the work? since it's using like only 130 out of 400% 
would an improved graphics card help things along?

Need some knowledge here 
terramir


 
Respectfully,
R. Daniel Borkan
727 S. Coronado St. 201
Los Angeles, CA 90057
H: <a href="tel:%28213%29%20739-1863" value="+12137391863" target="_blank">(213) 739-1863
C: <a href="tel:%28213%29%20271-6721" value="+12132716721" target="_blank">(213) 271-6721
All written content of this e-mail is confidential and only intended for the named recipient. This message is subject to copyright and is intellectual property of the sender. All rights reserved (c) 2013 

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

Alan Cox
In reply to this post by nophead
On Tue, 24 Jun 2014 14:44:22 +0100
nop head <[hidden email]> wrote:

> I think I am right is saying the graphics processor affects the speed of F5
> but only one core of the CPU is used for F6.

Single core of the CPU, driving what is (for many historic reasons) a
rather slow CSG engine.

But on the bright side there is no conceptual reason why OpenSCAD
shouldn't be several thousand times faster than today.

Alan
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

Alan Cox
In reply to this post by drxenocide
On Tue, 24 Jun 2014 11:31:29 -0400
Ari Diacou <[hidden email]> wrote:

> How much work is involved in making parallelizing F6? I for one would love
> to have a reason to build a render farm of RPi's.

You would need to fix it to use fixed point maths first at which point
much of the problem would go away.

In theory you parallelise it by treating the tree of geometry operations
as a scheduling problem. Every geometry operation in the tree is blocked
by its children, but all the children may execute in parallel.

Alan
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

kintel
Administrator
In reply to this post by drxenocide

On Jun 24, 2014, at 11:31 AM, Ari Diacou <[hidden email]> wrote:

> How much work is involved in making parallelizing F6? I for one would love to have a reason to build a render farm of RPi’s.
>
See https://github.com/openscad/openscad/issues/391

As Alan points out, putting resources towards a faster CSG engine may have much larger benefits, but could be combined with parallelization.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

drxenocide
As a matter of curiosity, why is CSG optimization your problem? I assumed it was another project with different developpers. Also, how much parallelization work could be shunted off to different packages? If you wanted to add that feature, how much would you have to write?


On Tue, Jun 24, 2014 at 5:08 PM, Marius Kintel <[hidden email]> wrote:

On Jun 24, 2014, at 11:31 AM, Ari Diacou <[hidden email]> wrote:

> How much work is involved in making parallelizing F6? I for one would love to have a reason to build a render farm of RPi’s.
>
See https://github.com/openscad/openscad/issues/391

As Alan points out, putting resources towards a faster CSG engine may have much larger benefits, but could be combined with parallelization.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

kintel
Administrator

On Jun 24, 2014, at 17:35 PM, Ari Diacou <[hidden email]> wrote:

> As a matter of curiosity, why is CSG optimization your problem? I assumed it was another project with different developpers. Also, how much parallelization work could be shunted off to different packages? If you wanted to add that feature, how much would you have to write?
>
We use those libraries what make sense, license-wise and feature-wise. Whether or not we write our own code to solve particular tasks (CSG evaluation, parallelization support tools) primarily depends on what is out there that we can use and how much time it would take to shoehorn it into OpenSCAD.
At the end of the day, all these things are our problems. If nobody offers such technology, it might be time to make it happen.

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

Oskar
In reply to this post by Alan Cox
Alan Cox wrote
> How much work is involved in making parallelizing F6? I for one would love
> to have a reason to build a render farm of RPi's.

You would need to fix it to use fixed point maths first at which point
much of the problem would go away.
While I think fixed point math is may be a good idea, I don't think it is the panacea for all performance problems. Yes, fixed point math makes it much easier to implement robust geometric predicates – but by using a filtered kernel, robust predicates are also possible to do efficiently with floating point. There is a performance difference, but my guess is that it is something like a factor of 2. In order to calculate exact geometric constructions, such as the intersection point of two lines, fixed point math is not sufficient and a rational representation is needed.

It may be possible to do CSG robustly without needing to calculate exact point positions (one such method could be to represent points implicitly as the intersection of three planes rather then with euclidian coordinates, another promising approach is by using controlled perturbation), but using exact values during intermediary calculations makes things much easier and doesn't have to be that expensive if done right.

The main reason the current CSG engine is slow is that it it uses a Nef polyhedron representation that requires exact values for *all* internal data. OpenSCAD also makes Nefs remain exact Nefs during chained CSG operations, during which time the the internal unlimited precision rational representation has a tendency to grow quite significantly. This has a quite severe memory and also performance impact that could be addressed somewhat by quantizing the intermediate results by transforming back to a fixed point or floating point representation. (The problem with this approach is that it gives rise to degenerate and even self-intersecting geometry.)

Transforming (especially rotating) a CGAL Nef object has even more severe memory impact. In one particular OpenSCAD example (no 24 iirc) a quite complex chain of CSG makes OpenSCAD use something like 200 mb of memory until one of the last operations – a simple rotation – which causes the total memory usage to explode to 1.3 GB(!).

When it comes to CSG, there are a number of different interesting approaches one could consider:

* Implementing a floating point to floating point (or fixed -> fixed) CSG mesh operation using a small amount of exact arithmetics for intermediate calculations. Degenerate and self-intersecting geometry can be a problem, so some kind of mesh cleaning must likely be performed afterwards. As an experiment I have implemented one such library based on Cyril Leconte's code in MEPP. The speed-up from CGAL Nef is currently in the order of 20–50 x.

* OpenJSCAD implements very fast CSG using pure JavaScript. The CSG operations are based on BSP trees in a very elegant way implemented in only a few hundred lines of code. The main problem that I see is that the resulting meshes are nonmanifold. Vertices on one triangle does often not correspond to vertices on another triangle, but rather approximately to an edge of another triangle. You get lots of small cracks, degenerate triangles and and potentially self-intersections. It may be possible to fix that.

* A third option I find very interesting for additive manufacturing is deferring CSG operations to the actual slicing step. 2D CSG is much faster than 3D CSG and all slicers have polygonal slices as a simple intermediary representation.
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

Alan Cox
> While I think fixed point math is may be a good idea, I don't think it is
> the panacea for all performance problems. Yes, fixed point math makes it
> much easier to implement robust geometric predicates – but by using a
> filtered kernel, robust predicates are also possible to do efficiently with
> floating point. There is a performance difference, but my guess is that it
> is something like a factor of 2. In order to calculate exact geometric
> constructions, such as the intersection point of two lines, fixed point math
> is not sufficient and a rational representation is needed.

Its depends a lot on the processor, especially if you want to support non
x86 processors or to an extent x86 Atom processors

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf

is the guide for X86 timings.

All the good stuff really wants SIMD instructions.

> It may be possible to do CSG robustly without needing to calculate exact

It is, people have been doing it for ages. It's armwavingly equivalent to
replacing each point in space with a small sphere. This is not rocket
science. Minecraft is an extreme example 8)

However it really comes down to a different geometry engine.

> * Implementing a floating point to floating point (or fixed -> fixed) CSG
> mesh operation using a small amount of exact arithmetics for intermediate
> calculations. Degenerate and self-intersecting geometry can be a problem, so
> some kind of mesh cleaning must likely be performed afterwards. As an
> experiment I have implemented one such library based on Cyril Leconte's code
> in MEPP. The speed-up from CGAL Nef is currently in the order of 20–50 x.

In itself a very good start. In real terms thats a 5 minute render down to
10 seconds or so, which is a big big win!
 
> * A third option I find very interesting for additive manufacturing is
> deferring CSG operations to the actual slicing step. 2D CSG is much faster
> than 3D CSG and all slicers have polygonal slices as a simple intermediary
> representation.

That was kind of where ImplicitCAD was heading before it got abandoned
by its author. At that point the slicer simply solves the equation
describing what is inside/outside for the x and y range with z set for
each slice.
 
The mathematical manipulations are well understood (by mathematicians at
least 8)) and it is relatively easy to describe some quite complex
curves, fillets and rounding.

Alan
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

Oskar
Alan Cox wrote
> It may be possible to do CSG robustly without needing to calculate exact

It is, people have been doing it for ages. It's armwavingly equivalent to
replacing each point in space with a small sphere. This is not rocket
science. Minecraft is an extreme example 8)
Alan Cox wrote
Do you have any references to approaches to this? Most work within computational geometry seem focused on computing surfaces, while what we want is really computing approximate volumes.
However it really comes down to a different geometry engine.
It is comical actually how we start with a very compact exact representation of what we want, turn that into a very rough (in relative terms) boundary approximation, while accepting a data expansion of up to several orders of magnitude, spend an insane amount of time and resources on computing exact boolean operations of these rough approximations, and follow that by finally approximating that exact result with a floating point representation. After that, we feed the resulting floating point representation into another software that does a very rough quantization along one dimension, and in some cases then tries to guess what a projection of the original exact geometric representation looked like. After that, there are in many cases further approximations of the data, but we can stop here.

One reason for this convoluted path is that the intermediary result (the polygonal mesh) is very useful for visualization, but OpenCSG kind of solves that problem in a very different and elegant way (still with limitations however – the entire convexity hack feels like something we'd want to get around. Maybe we can simply do that by letting CGAL do convex decompositions for us rather than using the Goldfeather algorithm).

Alan Cox wrote
> * A third option I find very interesting for additive manufacturing is
> deferring CSG operations to the actual slicing step. 2D CSG is much faster
> than 3D CSG and all slicers have polygonal slices as a simple intermediary
> representation.

That was kind of where ImplicitCAD was heading before it got abandoned
by its author. At that point the slicer simply solves the equation
describing what is inside/outside for the x and y range with z set for
each slice.
 
It would not be hard to take an existing slicing engine (CuraEngine seems like a good candidate) and add support for taking presliced polygons rather than STLs. And it's further not hard to turn most of our geometry (before surface evaluation) into polygonal slices.

Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

szabi
In reply to this post by Oskar


* A third option I find very interesting for additive manufacturing is
deferring CSG operations to the actual slicing step. 2D CSG is much faster
than 3D CSG and all slicers have polygonal slices as a simple intermediary
representation.


I was ponderig exactly the same thing in recent days!

I.e. basically keeping a parametric representation in the tree, then in the slicing operation simply fix z for different values in [0 : slicewidth : z_max], and do the CSG calculation (union, difference, minkowski) on the parametric, now 2D-representations for each slice...

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

Greg Frost
Isn't a 3D minkowski() something that can't be done in 2D?

Sent from my iPhone

On 25 Jun 2014, at 5:44 pm, "Szelp, A. Sz." <[hidden email]> wrote:



* A third option I find very interesting for additive manufacturing is
deferring CSG operations to the actual slicing step. 2D CSG is much faster
than 3D CSG and all slicers have polygonal slices as a simple intermediary
representation.


I was ponderig exactly the same thing in recent days!

I.e. basically keeping a parametric representation in the tree, then in the slicing operation simply fix z for different values in [0 : slicewidth : z_max], and do the CSG calculation (union, difference, minkowski) on the parametric, now 2D-representations for each slice...

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

kintel
Administrator
In reply to this post by Oskar
On Jun 24, 2014, at 18:32 PM, Oskar <[hidden email]> wrote:
>
> * A third option I find very interesting for additive manufacturing is
> deferring CSG operations to the actual slicing step. 2D CSG is much faster
> than 3D CSG and all slicers have polygonal slices as a simple intermediary
> representation.
>
This has been discussed a bit in the past, but I think mostly outside the mailing list.
This feature could also be interesting for slicing 3D models for e.g. laser cutting layers.

Since this would be specific to certain toolchains supporting this, it cannot really replace what we do today, but could be an interesting supplement.

Every time we try smth. like this, we’re forced to refactor and improve surrounding code, so it seldomly hurts to try :)

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

nophead
Adrian Bowyer's original Reprap host did the slicing via CSG equations I believe. The slow part was converting STL into CSG half planes but that step could potentially be skipped.


On 25 June 2014 16:11, Marius Kintel <[hidden email]> wrote:
On Jun 24, 2014, at 18:32 PM, Oskar <[hidden email]> wrote:
>
> * A third option I find very interesting for additive manufacturing is
> deferring CSG operations to the actual slicing step. 2D CSG is much faster
> than 3D CSG and all slicers have polygonal slices as a simple intermediary
> representation.
>
This has been discussed a bit in the past, but I think mostly outside the mailing list.
This feature could also be interesting for slicing 3D models for e.g. laser cutting layers.

Since this would be specific to certain toolchains supporting this, it cannot really replace what we do today, but could be an interesting supplement.

Every time we try smth. like this, we’re forced to refactor and improve surrounding code, so it seldomly hurts to try :)

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

szabi
In reply to this post by kintel
Then again...

Such a z-slicing idea originates from a certain toolchain/process, it can be well used internally in general for OpenSCAD:

At some point you do tessellate for display anyway. By using the mentioned method the triangles would have height = slice_height.

Might be suboptimal for models with huge plane sides, true, but incorporatable into the current process.

Ugh, I'm tired, I hope that still makes some sense.

Szelp, André Szabolcs

+43 (650) 79 22 400


On Wed, Jun 25, 2014 at 5:11 PM, Marius Kintel <[hidden email]> wrote:
On Jun 24, 2014, at 18:32 PM, Oskar <[hidden email]> wrote:
>
> * A third option I find very interesting for additive manufacturing is
> deferring CSG operations to the actual slicing step. 2D CSG is much faster
> than 3D CSG and all slicers have polygonal slices as a simple intermediary
> representation.
>
This has been discussed a bit in the past, but I think mostly outside the mailing list.
This feature could also be interesting for slicing 3D models for e.g. laser cutting layers.

Since this would be specific to certain toolchains supporting this, it cannot really replace what we do today, but could be an interesting supplement.

Every time we try smth. like this, we’re forced to refactor and improve surrounding code, so it seldomly hurts to try :)

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

szabi
In reply to this post by nophead
The idea would be to skip the STL part completely.

You export a parametric model description,

and the slicer uses that directly to get the slices by fixing z for consecutive values in [0 : step : z_max].



Szelp, André Szabolcs

+43 (650) 79 22 400


On Wed, Jun 25, 2014 at 5:15 PM, nop head <[hidden email]> wrote:
Adrian Bowyer's original Reprap host did the slicing via CSG equations I believe. The slow part was converting STL into CSG half planes but that step could potentially be skipped.


On 25 June 2014 16:11, Marius Kintel <[hidden email]> wrote:
On Jun 24, 2014, at 18:32 PM, Oskar <[hidden email]> wrote:
>
> * A third option I find very interesting for additive manufacturing is
> deferring CSG operations to the actual slicing step. 2D CSG is much faster
> than 3D CSG and all slicers have polygonal slices as a simple intermediary
> representation.
>
This has been discussed a bit in the past, but I think mostly outside the mailing list.
This feature could also be interesting for slicing 3D models for e.g. laser cutting layers.

Since this would be specific to certain toolchains supporting this, it cannot really replace what we do today, but could be an interesting supplement.

Every time we try smth. like this, we’re forced to refactor and improve surrounding code, so it seldomly hurts to try :)

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

kintel
Administrator
In reply to this post by nophead
On Jun 25, 2014, at 11:15 AM, nop head <[hidden email]> wrote:

> Adrian Bowyer's original Reprap host did the slicing via CSG equations I believe. The slow part was converting STL into CSG half planes but that step could potentially be skipped.

Yes, that’s also the initial reason why we added the .csg export format. Not sure how far he got with supporting .csg files though.

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: video card choices mac osx speed

doug.moen
In reply to this post by szabi
Under the current design, OpenSCAD generates a file containing a polyhedral representation of the object (currently STL, maybe AMF in the future). This is fed to a slicer, which generates gcode.

If we are discussing a change to this design, then I'd like to point out some potential benefits. This could enable the specification of new kinds of 3D printed objects that are barely feasible with the old architecture. I'm thinking about the ability to algorithmically specify objects with a complex and fine grained internal structure, all the way down to the device resolution.

Right now, the slicer expects a polyhedral model without much internal structure, and takes responsibility for generating the fine grained structure of the print, using parameters such as hull thickness and infill percentage. I want to move this responsibility into the modelling language, so that I can specify things like multi-material objects with continuously varying ratios of the different materials, and metamaterials with precisely specified fine grained structure.


On 25 June 2014 04:14, Szelp, A. Sz. <[hidden email]> wrote:


* A third option I find very interesting for additive manufacturing is
deferring CSG operations to the actual slicing step. 2D CSG is much faster
than 3D CSG and all slicers have polygonal slices as a simple intermediary
representation.


I was ponderig exactly the same thing in recent days!

I.e. basically keeping a parametric representation in the tree, then in the slicing operation simply fix z for different values in [0 : slicewidth : z_max], and do the CSG calculation (union, difference, minkowski) on the parametric, now 2D-representations for each slice...

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566