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) 7391863 C: (213) 2716721 All written content of this email 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 
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 mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
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:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
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 
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 
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 
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:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
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, licensewise and featurewise. 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 
In reply to this post by 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. 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 selfintersecting 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 selfintersecting 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 speedup 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 selfintersections. 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. 
> 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/64ia32architecturesoptimizationmanual.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 selfintersecting 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 speedup 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 
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).
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. 
In reply to this post by Oskar
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 2Drepresentations for each slice... _______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
Isn't a 3D minkowski() something that can't be done in 2D? Sent from my iPhone
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
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 
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:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
In reply to this post by kintel
Then again... Such a zslicing idea originates from a certain toolchain/process, it can be well used internally in general for OpenSCAD:Szelp, André Szabolcs
+43 (650) 79 22 400 On Wed, Jun 25, 2014 at 5:11 PM, Marius Kintel <[hidden email]> wrote:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
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:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
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 
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 multimaterial 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:
_______________________________________________ OpenSCAD mailing list [hidden email] http://rocklinux.net/mailman/listinfo/openscad http://openscad.org  https://flattr.com/thing/121566 
Free forum by Nabble  Edit this page 