Re: [OpenSCAD] Lattice structure
Well, I think that even 23 seconds is a long time for such a trivial
construction. It really ought to be a fraction of a second. Suppose you
wanted a 100x100x100 grid, instead of 2x4x6? With linear scaling, that
would be more than 7 days of rendering, but union scales non-linearly in
OpenSCAD, and probably in Carv as well.
On 24 March 2017 at 15:40, Carsten Arnholm arnholm@arnholm.org wrote:
On 24. mars 2017 13:07, Parkinbot wrote:
That is exactly the point. Anything beyond linear_extruding a 2d object,
is
exactly where the problem starts. Try to render (F6) the following small
piece - about 6 minutes on my machine. Then just multiply any dimension
sx,
sy, or sz by just 2 and watch how render time grows.
http://forum.openscad.org/file/n21013/lattice.png
I tried your code on my new Linux machine using 2015.03-1 and found it
(F6) completed in 2 minutes and 48 seconds. I also translated your OpenSCAD
code into AngelScript and ran it through my Carve based boolean engine on
the same computer. It completed in 23 seconds, with a result that looks
similar to openSCAD.
Elsewhere, doug moen mentions that "This issue (complex lattices vs
boolean operations) is a limitation in the design of OpenSCAD."
One could argue that it is probably not so much a limitation in the design
of OpenSCAD but perhaps more a question of the characteristics of the
boolean engines (CGAL vs. Carve).
One thing I found was that creating subgroups (spheres+ybars, xbars,
zbars) was helpful in speeding things up in my code. I am guessing it is
because of bounding box checks.
As mentioned before, I am going to release my carve based engine on github
when I get around to it (need to learn git as well).
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
It's all in the facets
http://forum.openscad.org/file/n21021/lattice_3.jpg
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/Lattice-structure-tp21001p21021.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
this explains it very clearly , the code seems to work fine.While extruding
it followed by rendering the final object it takes a few minutes.Open SCAD
does offer a good environment to perform a range of operations.
Prior to the start of my work while doing initial research I came across an
article that describes possibility of generating so called 'Selective space
structures' , that enables to generate these reticulated mesh arrays , I
believe it involves complex algorithm designs but nonetheless OpenScad works
fine
http://www.georgehart.com/rp/10-3.html
http://www.georgehart.com/rp/10-3.html
--
View this message in context: http://forum.openscad.org/Lattice-structure-tp21001p21022.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On 2017-03-25 00:54, doug moen wrote:
Well, I think that even 23 seconds is a long time for such a trivial
construction. It really ought to be a fraction of a second.
Of course one wants everything at no cost, but that is not going to
happen. It is better to evaluate what the main factors are and what
realistically can be achieved. The number of facets is obviously one
major factor, but it isn't the only answer.
My little example showed it is possible to improve ~an order of
magnitude just by using another boolean engine. There are also other
paths to pursue, such as multi-threaded processing, which I will try at
some stage. The numbers I gave were just snapshots of current working
implementations for comparison, both single threaded.
Another thing I tried was observing memory use. I factored the
dimensions up by 2 and watched memory use. For this relatively small
model, OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems
hard to justify. That alone is a major performance issue. My Carve-based
engine was never higher than 400MB ram for the same problem, so you are
looking at an order of magnitude difference there.
Carsten Arnholm
So is there anything that would prevent CGAL being replaced by Carve? Does
it miss some features?
I don't think it would be too hard to speed up CGAL by many orders of
magnitude that may be naive. It obviously does make any attempt to skip the
facets that need no modification in a union, which is often all of them.
On 25 March 2017 at 11:14, arnholm@arnholm.org wrote:
On 2017-03-25 00:54, doug moen wrote:
Well, I think that even 23 seconds is a long time for such a trivial
construction. It really ought to be a fraction of a second.
Of course one wants everything at no cost, but that is not going to
happen. It is better to evaluate what the main factors are and what
realistically can be achieved. The number of facets is obviously one major
factor, but it isn't the only answer.
My little example showed it is possible to improve ~an order of magnitude
just by using another boolean engine. There are also other paths to pursue,
such as multi-threaded processing, which I will try at some stage. The
numbers I gave were just snapshots of current working implementations for
comparison, both single threaded.
Another thing I tried was observing memory use. I factored the dimensions
up by 2 and watched memory use. For this relatively small model,
OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems hard to
justify. That alone is a major performance issue. My Carve-based engine was
never higher than 400MB ram for the same problem, so you are looking at an
order of magnitude difference there.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Sorry typed the opposite of what I meant.
I don't think it would be too hard to speed up CGAL by many orders of
magnitude, but that may be naive. It obviously doesn't make any attempt to
skip the facets that need no modification in a union, which is often all of
them.
On 25 March 2017 at 12:25, nop head nop.head@gmail.com wrote:
So is there anything that would prevent CGAL being replaced by Carve? Does
it miss some features?
I don't think it would be too hard to speed up CGAL by many orders of
magnitude that may be naive. It obviously does make any attempt to skip the
facets that need no modification in a union, which is often all of them.
On 25 March 2017 at 11:14, arnholm@arnholm.org wrote:
On 2017-03-25 00:54, doug moen wrote:
Well, I think that even 23 seconds is a long time for such a trivial
construction. It really ought to be a fraction of a second.
Of course one wants everything at no cost, but that is not going to
happen. It is better to evaluate what the main factors are and what
realistically can be achieved. The number of facets is obviously one major
factor, but it isn't the only answer.
My little example showed it is possible to improve ~an order of magnitude
just by using another boolean engine. There are also other paths to pursue,
such as multi-threaded processing, which I will try at some stage. The
numbers I gave were just snapshots of current working implementations for
comparison, both single threaded.
Another thing I tried was observing memory use. I factored the dimensions
up by 2 and watched memory use. For this relatively small model,
OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems hard to
justify. That alone is a major performance issue. My Carve-based engine was
never higher than 400MB ram for the same problem, so you are looking at an
order of magnitude difference there.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 2017-03-25 13:25, nop head wrote:
So is there anything that would prevent CGAL being replaced by Carve?
Does it miss some features?
Well, esoteric features (IMHO) like Minkowski is not there, so if you
consider it essential it will need an independent implementation. It is
a 3d boolean engine, you still need e.g. Clipper for 2d.
Carsten Arnholm
If it has hull and convex decomposition we can make Minkowski.
On 25 March 2017 at 13:07, arnholm@arnholm.org wrote:
On 2017-03-25 13:25, nop head wrote:
So is there anything that would prevent CGAL being replaced by Carve?
Does it miss some features?
Well, esoteric features (IMHO) like Minkowski is not there, so if you
consider it essential it will need an independent implementation. It is a
3d boolean engine, you still need e.g. Clipper for 2d.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
s.dwivedi wrote
Prior to the start of my work while doing initial research I came across
an article that describes possibility of generating so called 'Selective
space structures' , that enables to generate these reticulated mesh arrays
, I believe it involves complex algorithm designs but nonetheless OpenScad
works fine
http://www.georgehart.com/rp/10-3.html
http://www.georgehart.com/rp/10-3.html
What a beautiful lattice! At least that one can be roughly modeled with
OpenSCAD.
// lattice data in the form [ vertex list, path list ]
lat = [ [ [0,0,4], [0,1,3], [1,1,2], [1,0,1], [0,0,0],
[4,4,4], [3,3,4], [3,2,3], [4,1,3], [4,0,4],
[0,4,0], [1,4,1], [2,3,1], [3,3,0], [4,4,0],
[2,2,2] ]/4,
[ [0,1,2,3,4], [5,6,7,8,9], [10,11,12,13,14],
[2,15,7], [15,12]] ];
WellsLattice(lat,20,3,3,3,1);
module WellsLattice(p,size,nx,ny,nz,th)
for(i=[0:nx-1])
for(j=[0:ny-1])
for(k=[0:nz-1])
color([1,0,0,2*(k/nz+j/ny+i/nx)/9+1/3]) // unnecessary
translate([i,j,k]*size)
latticeVoxel(p,size,th);
module latticeVoxel(p,size,th) {
for(pi=p[1]){
line = size*[for(nj=pi) p[0][nj]];
polyline(line,th=th);
}
}
module polyline(p,th)
for(i=[0:len(p)-2]){
hull() {
translate(p[i]) sphere(th1.5);
translate((p[i+1]+p[i])/2) sphere(th/2);
}
hull() {
translate(p[i+1]) sphere(th1.5);
translate((p[i+1]+p[i])/2) sphere(th/2);
}
}
The preview of a 4x4x4 lattice is very fast. The render took 2 min (3x3x3),
3.5 min (4x4x3) and 5.5 min (4x4x4) in my rather old machine.
Geroge Hart's images are far more smooth than mine. His technique is to make
a polyhedron model with triangulated faces (like mine) and apply a
subdivision method (such as Loop's one) to the surface. That would be
feasible to be done in OSCAD if we had a 2D manifold triangulation data
structure and a way to retrieve vertex data from a model. With these two
resources, organic model would be possible in OSCAD.
--
View this message in context: http://forum.openscad.org/Lattice-structure-tp21001p21029.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD is an awesome tool, but I don't think its design is the best for
doing George Hart style fractals, lattices, etc.
Consider Parkinbot's lattice, a union of spheres and cylinders. OpenSCAD
converts these spheres and cylinders into mesh approximations as early as
possible, and then uses a very expensive mesh-based union operator
(currently from CGAL) to perform the union. The performance and memory
consumption degrades non-linearly as $fn gets higher. That will still be
true if OpenSCAD switches to Carve.
A better approach, I think, it to represent spheres and cylinders exactly,
using a very cheap representation (origin, radius, height), and delay the
construction of the mesh until the final stage of rendering, using high
level information from the CSG tree to pick rendering strategies.
OpenSCAD is also single threaded. I think the best performance will result
from doing the rendering on the GPU, because then you can take advantage of
massive parallelism.
I'm interested in exploring these ideas within an open source project.
On 25 March 2017 at 07:14, arnholm@arnholm.org wrote:
On 2017-03-25 00:54, doug moen wrote:
Well, I think that even 23 seconds is a long time for such a trivial
construction. It really ought to be a fraction of a second.
Of course one wants everything at no cost, but that is not going to
happen. It is better to evaluate what the main factors are and what
realistically can be achieved. The number of facets is obviously one major
factor, but it isn't the only answer.
My little example showed it is possible to improve ~an order of magnitude
just by using another boolean engine. There are also other paths to pursue,
such as multi-threaded processing, which I will try at some stage. The
numbers I gave were just snapshots of current working implementations for
comparison, both single threaded.
Another thing I tried was observing memory use. I factored the dimensions
up by 2 and watched memory use. For this relatively small model,
OpenSCAD/CGAL required more than 6GB of ram (64bit), which seems hard to
justify. That alone is a major performance issue. My Carve-based engine was
never higher than 400MB ram for the same problem, so you are looking at an
order of magnitude difference there.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org