STL without render?

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

STL without render?

bsuter
Is it possible to save an STL file without going through the full render step?

It frustrates me that I can *see* the surface model using "preview",
but apparently can not simply save this as an STL file?

Background: I am using OpenSCAD to generate surface models of neurons,
because the ability to programmatically define 3D surfaces from a set
of tapered cylinders closely matches the way in which neuronal
geometry is represented when derived from experimental measurements.
My goal is to make an STL file that I can use for 3D printing - I
don't care about lighting, viewpoints, textures, colors. Just the pure
surface model.

Currently the render takes 2.5 hours per neuron, severely limiting my
ability to process many neurons and making me doubt whether it's
feasible for me to assemble a single scene with ~50 neurons (as I had
hoped).

In any case, I'm very happy to have found OpenSCAD and have to say
it's been a great pleasure using it in my processing pipeline. Thank
you, and please keep up the great work!


PS: Currently my scene consists of a few thousand individual cylinders
and spheres, each with its own translation and rotation relative to
the origin. However, each of these segments naturally falls into a
geometrical hierarchy - so alternatively I could represent the scene
as a hierarchy of rotations and translations of each child segment
relative to its parent. Is there reason to believe that the
hierarchical representation (with few root nodes) would render faster?

PPS: Here's the console output after my latest render - note this is
on a 16-core Xeon / Windows 7 64-bit / 72 GB RAM / SSD / GTX 970
machine. Are there any OpenSCAD settings I should modify to make
better use of these resources?

Geometries in cache: 6514
Geometry cache size in bytes: 60051248
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Total rendering time: 2 hours, 19 minutes, 58 seconds
Top level object is a 3D object:
Simple: yes
Vertices: 490328
Halfedges: 1703918
Edges: 851959
Halffacets: 730078
Facets: 365039
Volumes: 3
Rendering finished.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

nophead
No you can only save an image from the preview. The geometry hasn't been calculated at the point, just a picture of it using graphic rendering tricks.

On 1 June 2016 at 12:30, Ben Suter <[hidden email]> wrote:
Is it possible to save an STL file without going through the full render step?

It frustrates me that I can *see* the surface model using "preview",
but apparently can not simply save this as an STL file?

Background: I am using OpenSCAD to generate surface models of neurons,
because the ability to programmatically define 3D surfaces from a set
of tapered cylinders closely matches the way in which neuronal
geometry is represented when derived from experimental measurements.
My goal is to make an STL file that I can use for 3D printing - I
don't care about lighting, viewpoints, textures, colors. Just the pure
surface model.

Currently the render takes 2.5 hours per neuron, severely limiting my
ability to process many neurons and making me doubt whether it's
feasible for me to assemble a single scene with ~50 neurons (as I had
hoped).

In any case, I'm very happy to have found OpenSCAD and have to say
it's been a great pleasure using it in my processing pipeline. Thank
you, and please keep up the great work!


PS: Currently my scene consists of a few thousand individual cylinders
and spheres, each with its own translation and rotation relative to
the origin. However, each of these segments naturally falls into a
geometrical hierarchy - so alternatively I could represent the scene
as a hierarchy of rotations and translations of each child segment
relative to its parent. Is there reason to believe that the
hierarchical representation (with few root nodes) would render faster?

PPS: Here's the console output after my latest render - note this is
on a 16-core Xeon / Windows 7 64-bit / 72 GB RAM / SSD / GTX 970
machine. Are there any OpenSCAD settings I should modify to make
better use of these resources?

Geometries in cache: 6514
Geometry cache size in bytes: 60051248
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Total rendering time: 2 hours, 19 minutes, 58 seconds
Top level object is a 3D object:
Simple: yes
Vertices: 490328
Halfedges: 1703918
Edges: 851959
Halffacets: 730078
Facets: 365039
Volumes: 3
Rendering finished.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

RobWLakes
In reply to this post by bsuter
I like the idea of modeling cellular activity or constructions. OpenSCAD
lends itself really well to visualizing these things, but
computationally we are still limited compared to the biological
capacity. I think a previous thread discussing narrowing bifurcating
cylinders with smooth transitions, similar to what we could expect going
from arteries to capillaries and back to veins, was running into a
similar exponential growth in the computational challenge. It reminded
me though that as every cell reproduces, it essentially spawns another
two computational units in the nucleus of those new cells (The answer to
the N squared problem?).  The programs in the DNA are applying their
rules in the new environment for each new cell.  I can't see us
surpassing this system too quickly with our silicon models, but I admire
the efforts of people such as Ben who are investigating these areas.
Rob

On 01/06/16 21:30, Ben Suter wrote:

> Is it possible to save an STL file without going through the full render step?
>
> It frustrates me that I can *see* the surface model using "preview",
> but apparently can not simply save this as an STL file?
>
> Background: I am using OpenSCAD to generate surface models of neurons,
> because the ability to programmatically define 3D surfaces from a set
> of tapered cylinders closely matches the way in which neuronal
> geometry is represented when derived from experimental measurements.
> My goal is to make an STL file that I can use for 3D printing - I
> don't care about lighting, viewpoints, textures, colors. Just the pure
> surface model.
>
> Currently the render takes 2.5 hours per neuron, severely limiting my
> ability to process many neurons and making me doubt whether it's
> feasible for me to assemble a single scene with ~50 neurons (as I had
> hoped).
>
> In any case, I'm very happy to have found OpenSCAD and have to say
> it's been a great pleasure using it in my processing pipeline. Thank
> you, and please keep up the great work!
>
>
> PS: Currently my scene consists of a few thousand individual cylinders
> and spheres, each with its own translation and rotation relative to
> the origin. However, each of these segments naturally falls into a
> geometrical hierarchy - so alternatively I could represent the scene
> as a hierarchy of rotations and translations of each child segment
> relative to its parent. Is there reason to believe that the
> hierarchical representation (with few root nodes) would render faster?
>
> PPS: Here's the console output after my latest render - note this is
> on a 16-core Xeon / Windows 7 64-bit / 72 GB RAM / SSD / GTX 970
> machine. Are there any OpenSCAD settings I should modify to make
> better use of these resources?
>
> Geometries in cache: 6514
> Geometry cache size in bytes: 60051248
> CGAL Polyhedrons in cache: 0
> CGAL cache size in bytes: 0
> Total rendering time: 2 hours, 19 minutes, 58 seconds
> Top level object is a 3D object:
> Simple: yes
> Vertices: 490328
> Halfedges: 1703918
> Edges: 851959
> Halffacets: 730078
> Facets: 365039
> Volumes: 3
> Rendering finished.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Rob W
Lake Tyers Beach,
Victoria, Australia
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

bsuter
In reply to this post by nophead
Thank you both for your feedback and input!

nophead wrote
No you can only save an image from the preview. The geometry hasn't been
calculated at the point, just a picture of it using graphic rendering
tricks.
Aha, so the GPU did all the hard work of tessellating, etc. but we can't "recapture" that? Interesting how fast the GPU preview works (< 1 sec) compared to how long the render takes (2.3 hours).

Three questions:

1. Are there any other tools like OpenSCAD that I could try, that also allow declarative description of 3D surfaces using cylinder and sphere primitives together with geometric transformations? Maybe tools that use the GPU or multiple cores for the "render" step?

2. I'd very much appreciate any tips or suggestions for alternatives: I don't need lighting, color, textures or such, I just want to describe the geometry using tapered cylinders and spheres, and then have the software convert this to a surface model (e.g. tessellate) suitable for 3D printing (e.g. STL, OBJ, VRML).

3. Sticking with OpenSCAD, is it better to have a "flat" or "hierarchical" scene graph?
bsuter wrote
> PS: Currently my scene consists of a few thousand individual cylinders
> and spheres, each with its own translation and rotation relative to
> the origin. However, each of these segments naturally falls into a
> geometrical hierarchy - so alternatively I could represent the scene
> as a hierarchy of rotations and translations of each child segment
> relative to its parent. Is there reason to believe that the
> hierarchical representation (with few root nodes) would render faster?
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

bsuter
In reply to this post by bsuter
Thank you both for your feedback and input!

<quote author="nophead">
No you can only save an image from the preview. The geometry hasn't been
calculated at the point, just a picture of it using graphic rendering
tricks.
</quote>

Aha, so the GPU did all the hard work of tessellating, etc. but we
can't "recapture" that? Interesting how fast the GPU preview works (<
1 sec) compared to how long the render takes (2.3 hours).

Four questions:

1. Are there any other tools like OpenSCAD that I could try, that also
allow declarative description of 3D surfaces using cylinder and sphere
primitives together with geometric transformations? Maybe tools that
use the GPU or multiple cores for the "render" step?

2. I'd very much appreciate any tips or suggestions for alternatives:
I don't need lighting, color, textures or such, I just want to
describe the geometry using tapered cylinders and spheres, and then
have the software convert this to a surface model (e.g. tessellate)
suitable for 3D printing (e.g. STL, OBJ, VRML).

3. Sticking with OpenSCAD, is it better to have a "flat" or
"hierarchical" scene graph?
<quote author="bsuter">
> PS: Currently my scene consists of a few thousand individual cylinders
> and spheres, each with its own translation and rotation relative to
> the origin. However, each of these segments naturally falls into a
> geometrical hierarchy - so alternatively I could represent the scene
> as a hierarchy of rotations and translations of each child segment
> relative to its parent. Is there reason to believe that the
> hierarchical representation (with few root nodes) would render faster?
</quote>

4. I subscribed to this email list, but am not getting replies to this
thread in my inbox. On the web interface (Nabble) I can see replies,
but when I post a reply there myself, I get a message indicating that
my reply "was not yet accepted to the mailing list". Any advice on how
to improve this?


On Wed, Jun 1, 2016 at 1:30 PM, Ben Suter <[hidden email]> wrote:

> Is it possible to save an STL file without going through the full render step?
>
> It frustrates me that I can *see* the surface model using "preview",
> but apparently can not simply save this as an STL file?
>
> Background: I am using OpenSCAD to generate surface models of neurons,
> because the ability to programmatically define 3D surfaces from a set
> of tapered cylinders closely matches the way in which neuronal
> geometry is represented when derived from experimental measurements.
> My goal is to make an STL file that I can use for 3D printing - I
> don't care about lighting, viewpoints, textures, colors. Just the pure
> surface model.
>
> Currently the render takes 2.5 hours per neuron, severely limiting my
> ability to process many neurons and making me doubt whether it's
> feasible for me to assemble a single scene with ~50 neurons (as I had
> hoped).
>
> In any case, I'm very happy to have found OpenSCAD and have to say
> it's been a great pleasure using it in my processing pipeline. Thank
> you, and please keep up the great work!
>
>
> PS: Currently my scene consists of a few thousand individual cylinders
> and spheres, each with its own translation and rotation relative to
> the origin. However, each of these segments naturally falls into a
> geometrical hierarchy - so alternatively I could represent the scene
> as a hierarchy of rotations and translations of each child segment
> relative to its parent. Is there reason to believe that the
> hierarchical representation (with few root nodes) would render faster?
>
> PPS: Here's the console output after my latest render - note this is
> on a 16-core Xeon / Windows 7 64-bit / 72 GB RAM / SSD / GTX 970
> machine. Are there any OpenSCAD settings I should modify to make
> better use of these resources?
>
> Geometries in cache: 6514
> Geometry cache size in bytes: 60051248
> CGAL Polyhedrons in cache: 0
> CGAL cache size in bytes: 0
> Total rendering time: 2 hours, 19 minutes, 58 seconds
> Top level object is a 3D object:
> Simple: yes
> Vertices: 490328
> Halfedges: 1703918
> Edges: 851959
> Halffacets: 730078
> Facets: 365039
> Volumes: 3
> Rendering finished.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

nophead
I am seeing all your messages twice on the mailing list so they are getting there. When you post on the forum it always says it has not been accepted to start with.

The preview works by rendering the primitive objects into the Z buffer and using that to work out which bits are visible. For example when you union two objects it just draws them both separately. It never actually works out a 3D representation of the union, just a 2D picture of what it looks like from one angle.

When you do F6 CGAL is used to calculate the 3D solids very accurately and is very slow because it uses rational numbers instead of floating point.

Others maybe able to suggest faster alternatives. It is fast enough for the designs I do so I haven't looked elsewhere.

On 1 June 2016 at 14:30, Ben Suter <[hidden email]> wrote:
Thank you both for your feedback and input!

<quote author="nophead">
No you can only save an image from the preview. The geometry hasn't been
calculated at the point, just a picture of it using graphic rendering
tricks.
</quote>

Aha, so the GPU did all the hard work of tessellating, etc. but we
can't "recapture" that? Interesting how fast the GPU preview works (<
1 sec) compared to how long the render takes (2.3 hours).

Four questions:

1. Are there any other tools like OpenSCAD that I could try, that also
allow declarative description of 3D surfaces using cylinder and sphere
primitives together with geometric transformations? Maybe tools that
use the GPU or multiple cores for the "render" step?

2. I'd very much appreciate any tips or suggestions for alternatives:
I don't need lighting, color, textures or such, I just want to
describe the geometry using tapered cylinders and spheres, and then
have the software convert this to a surface model (e.g. tessellate)
suitable for 3D printing (e.g. STL, OBJ, VRML).

3. Sticking with OpenSCAD, is it better to have a "flat" or
"hierarchical" scene graph?
<quote author="bsuter">
> PS: Currently my scene consists of a few thousand individual cylinders
> and spheres, each with its own translation and rotation relative to
> the origin. However, each of these segments naturally falls into a
> geometrical hierarchy - so alternatively I could represent the scene
> as a hierarchy of rotations and translations of each child segment
> relative to its parent. Is there reason to believe that the
> hierarchical representation (with few root nodes) would render faster?
</quote>

4. I subscribed to this email list, but am not getting replies to this
thread in my inbox. On the web interface (Nabble) I can see replies,
but when I post a reply there myself, I get a message indicating that
my reply "was not yet accepted to the mailing list". Any advice on how
to improve this?


On Wed, Jun 1, 2016 at 1:30 PM, Ben Suter <[hidden email]> wrote:
> Is it possible to save an STL file without going through the full render step?
>
> It frustrates me that I can *see* the surface model using "preview",
> but apparently can not simply save this as an STL file?
>
> Background: I am using OpenSCAD to generate surface models of neurons,
> because the ability to programmatically define 3D surfaces from a set
> of tapered cylinders closely matches the way in which neuronal
> geometry is represented when derived from experimental measurements.
> My goal is to make an STL file that I can use for 3D printing - I
> don't care about lighting, viewpoints, textures, colors. Just the pure
> surface model.
>
> Currently the render takes 2.5 hours per neuron, severely limiting my
> ability to process many neurons and making me doubt whether it's
> feasible for me to assemble a single scene with ~50 neurons (as I had
> hoped).
>
> In any case, I'm very happy to have found OpenSCAD and have to say
> it's been a great pleasure using it in my processing pipeline. Thank
> you, and please keep up the great work!
>
>
> PS: Currently my scene consists of a few thousand individual cylinders
> and spheres, each with its own translation and rotation relative to
> the origin. However, each of these segments naturally falls into a
> geometrical hierarchy - so alternatively I could represent the scene
> as a hierarchy of rotations and translations of each child segment
> relative to its parent. Is there reason to believe that the
> hierarchical representation (with few root nodes) would render faster?
>
> PPS: Here's the console output after my latest render - note this is
> on a 16-core Xeon / Windows 7 64-bit / 72 GB RAM / SSD / GTX 970
> machine. Are there any OpenSCAD settings I should modify to make
> better use of these resources?
>
> Geometries in cache: 6514
> Geometry cache size in bytes: 60051248
> CGAL Polyhedrons in cache: 0
> CGAL cache size in bytes: 0
> Total rendering time: 2 hours, 19 minutes, 58 seconds
> Top level object is a 3D object:
> Simple: yes
> Vertices: 490328
> Halfedges: 1703918
> Edges: 851959
> Halffacets: 730078
> Facets: 365039
> Volumes: 3
> Rendering finished.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

Parkinbot
In reply to this post by bsuter
Can you share some image that shows your model in detail?

In OpenSCAD there are fast and slow alternatives to produce a design. If you stack too many primitives on top of each other, use boolean operations over too much detail (number of vertices) or special high-level operators like minkowski() and hull(), rendering gets slow. And it gets even slower, when you try to clone complex shapes into more complex structures like grids.

There are also ways to create complex shapes by doing most of triagulation work on your own. So it depends much on the programming approach you use and of course on the complexity of the design itself.
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

cacb
In reply to this post by bsuter
On 01. juni 2016 15:30, Ben Suter wrote:
> 1. Are there any other tools like OpenSCAD that I could try, that also
> allow declarative description of 3D surfaces using cylinder and sphere
> primitives together with geometric transformations? Maybe tools that
> use the GPU or multiple cores for the "render" step?

You could try http://arnholm.org/angelscript-csg-ide/

Be warned that the current public version relies on OpenSCAD to do the
booleans, so you don't gain anything in speed that way.

I do have an unreleased test version that does not use OpenSCAD for
booleans and that is much faster. But it isn't released at this time.

Carsten Arnholm




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

bsuter
In reply to this post by Parkinbot
Parkinbot wrote
Can you share some image that shows your model in detail?
Sure, I'm attaching a view here.

CA3pyr-Amaral-c11571.png

Parkinbot wrote
In OpenSCAD there are fast and slow alternatives to produce a design. If you stack too many primitives on top of each other, use boolean operations over too much detail (number of vertices) or special high-level operators like minkowski() and hull(), rendering gets slow. And it gets even slower, when you try to clone complex shapes into more complex structures like grids.
My model currently consists of a single sphere at the origin, and then about 1600 instances of a (tapered) cylinder with a sphere at the end (I add these spheres where two non-parallel cylinders come together, to "fill out" the join between them). I naively implemented each of these cylinder-sphere pairs like this:

translate([-2.918, -7.452, 0.698])
rotate(93.4419, [0.800474,-0.596353,0])
cylinder($fn=20, 0.499704, 0.8, 0.5);
translate([-3.216, -7.852, 0.668])
sphere($fn=20, 0.5);

So the above 5 lines repeat roughly 1600 times, of course with different values. The $fn values I chose basically to balance speed and beauty ...

As you can see in the image, this model is a naturally branched structure - so for many of these cylinder-sphere segments, their translation and rotation could naturally be defined as relative to their parent segment, rather than using a flat structure with each segment oriented relative to the origin (as I do now). Would you expect one of these approaches to be faster?

Parkinbot wrote
There are also ways to create complex shapes by doing most of triagulation work on your own. So it depends much on the programming approach you use and of course on the complexity of the design itself.
Interesting. Could you point me to some more info on the pre-triangulated approach? I think I can maybe use Matlab (where I am analyzing the geometry and generating the .scad now) to generate tessellated coordinates for each cylinder, or at least the vertices.

Thank you very much!
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

Parkinbot
How lovely! Nice to see, what people do with OpenSCAD.

A similar problem, doing a union() of a large number of cylinder and sphere primitives is currently discussed here.
http://www.thingiverse.com/groups/openscad/topic:6515#comment-900694
CGAL rendering is not very efficient when (very) large numbers of shapes come into play.

I've implemented some Matlab class to generically describe arteries with an interpolation scheme. The output is a winding 'wire' in 3D with free radius a each point in STL-format. In lack of an own union or furcation operator capable to do the intersection triangulation we currently use OpenSCAD and Blender to compose porperly placed wires into tree structures which we again cut into puzzle pieces for 3D print.

You might be interested for inspiration or even build on at least part of the code (in a non-commercial way), e.g. to implement this 'little' details on your own. Send me a PM to get in further touch.

I imagine some tree class, allowing for a (recursive) generic description of path points with radii that can render its objects to STL. In your case, I guess, you will add a net class to connect those tree objects formally into a network to do functional simulation.
OpenSCAD or any other CAD-Programm could be used to provide the final union() operation connecting some number of precompiled trees (neurons) into a printable unit. I wouldn't advise to do the programming natively in OpenSCAD.


Rudolf

Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

bsuter
Dear Rudolf, thank you for this info - it may take me some time to
fully understand, I'll try.

> A similar problem, doing a union() of a large number of cylinder and sphere
> primitives is currently discussed here.
> http://www.thingiverse.com/groups/openscad/topic:6515#comment-900694
> CGAL rendering is not very efficient when (very) large numbers of shapes
> come into play.

In that post you wrote "A single sweep() along a smoothed trajectory
will be faster than a union of cylinders and spheres describing the
same". Could you please explain further what you mean, in OpenSCAD
terms, by "single sweep() along a smoothed trajectory"? This sounds
useful. Certainly each of my branches can be modeled as a sequence of
nodes, where each node has an associated radius. Is there a way to
represent this directly in OpenSCAD? I.e. to specify a trajectory in
3D, and then extrude (ideally a circular cross-section, but a polygon
would work too) along this trajectory, with the extrusion radius
defined at each node?

Essentially this is what I tried to mimic using cylinder primitives
(and spheres at the nodes, to fill in the gaps between cylinder ends).

> I've implemented some Matlab class to generically describe arteries with an
> interpolation scheme. The output is a winding 'wire' in 3D with free radius
> a each point in STL-format.

This part I seem to understand. Arteries are quite similar, in the
present context, to dendritic arbors - tapered cylinders with branch
points. Ultimately all I want is STL. In my own Matlab code I am able
to generate a reasonable 3D figure (by using the cylinder() function
and, after some manipulations, passing the results to the surf()
function). I've toyed with the idea of instead taking the cylinder()
output (basically the vertices at the bottom and top edge of the
cylinder) and using these to generate a tessellated surface in STL
syntax. As long as I use a fixed # of vertices for all cylinders,
connecting the top of one to the base of the next via triangles should
be quite doable.

> In lack of an own union or furcation operator
> capable to do the intersection triangulation we currently use OpenSCAD and
> Blender to compose porperly placed wires into tree structures which we again
> cut into puzzle pieces for 3D print.

This part I don't understand ;(

> You might be interested for inspiration or even build on at least part of
> the code (in a non-commercial way), e.g. to implement this 'little' details
> on your own. Send me a PM to get in further touch.
Thank you!

> I imagine some tree class, allowing for a (recursive) generic description of
> path points with radii that can render its objects to STL. In your case, I
> guess, you will add a net class to connect those tree objects formally into
> a network to do functional simulation.

Such a class would be quite useful - seemingly to a variety of problem domains.

For functional simulations, the format we already use is quite
suitable (it's called SWC; a list of tuples, each tuple has <ID, type,
x, y, z, r, parent>) and widely used (see neuromorpho database if
curious).

My main goal is (a) virtual reality visualization of many neurons
together, and (b) 3D printing of individual neurons. For the latter,
there's a nice paper, but the code there is implemented within a
simulation environment (NEURON) and does not fit well with my current
pipeline.

McDougal, R. A. and G. M. Shepherd (2015). 3D-printer visualization of
neuron models. Frontiers in neuroinformatics 9.

> OpenSCAD or any other CAD-Programm could be used to provide the final
> union() operation connecting some number of precompiled trees (neurons) into
> a printable unit. I wouldn't advise to do the programming natively in
> OpenSCAD.
>
>
> Rudolf
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://forum.openscad.org/STL-without-render-tp17503p17524.html
> To unsubscribe from STL without render?, click here.
> NAML
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

Parkinbot
bsuter wrote
In that post you wrote "A single sweep() along a smoothed trajectory
will be faster than a union of cylinders and spheres describing the
same". Could you please explain further what you mean, in OpenSCAD
terms, by "single sweep() along a smoothed trajectory"?
This code is a good starting point and show case: http://www.thingiverse.com/thing:547620/#files
to get an idea, how sweeps behave. The (implicit) union() is needed for marriage of different sweep trajectories.

Certainly each of my branches can be modeled as a sequence of
nodes, where each node has an associated radius. Is there a way to
represent this directly in OpenSCAD? I.e. to specify a trajectory in
3D, and then extrude (ideally a circular cross-section, but a polygon
would work too) along this trajectory, with the extrusion radius
defined at each node?
There is no language support for general extrusion along trajectories, and there is no data structure support (or let's say only weak array support) for things like trees and so on. But there are libraries like sweep() and skin() going into this direction. Also see here: http://www.thingiverse.com/thing:900137

> I've implemented some Matlab class to generically describe arteries with an
> interpolation scheme. The output is a winding 'wire' in 3D with free radius
> at each point in STL-format.
this is an example of the outcome:  http://forum.openscad.org/Non-Linear-Transformations-tp14539p14597.html

The class simply does some nspline calculation over a sequence of 4D vectors (x, y, z, r) describing a skeleton line. Most of the code is for handling STL-triangulation and output.

> In lack of an own union or furcation operator
> capable to do the intersection triangulation we currently use OpenSCAD and
> Blender to compose porperly placed wires into tree structures which we again
> cut into puzzle pieces for 3D print.
This part I don't understand ;(
STL triagulation is easy and fast if you don't have to check for self-intersection (SI). I.e. if the code can assume, no SI will happen, it can skip all tests and calculations that would be needed to treat SI and just knit some generic triangulation pattern in a straight forward manner. Its helps to think about physical knitting to understand what is going on.
For the puzzle part: It might be interesting to print a structure in pieces, e.g. to compose a construction kit or similar (which can also be used for moulding).  In your case, it might be advantegous to print the neurons and the dendrits as destinct pieces and design a connector for piecing parts together as puzzle.
 
A union of any non-SI shapes might be SI - and will be SI at defined locations in the case of furcations and trees. So, if SI is only happening at furcation points, the intersection can be calculated somehow in a fast manner, to get a proper triangulation. Have a look, how the union of two cylinders is mapped into STL (to get a first impression, you can use F10 and Ctrl+1 which only partly triangulates).
This is the principle. OpenSCAD has this operator in form of union(). So, one way is to import a bunch of branches (STLs) already correctly placed und let OpenSCAD do the work dirty work in a general way.
In fact at CSG-level (F5) this is done only virtually by the graphics card. And when it comes to STL output (F6) CGAL is used, which takes its time.

Knowing that all your branches will not SI, except at furcation points, you can write your own specialized (and thus fast) union() that remeshes just the furcation intersection part of the branches.

My main goal is (a) virtual reality visualization of many neurons
together, and (b) 3D printing of individual neurons.
It depends on how often this is repeated. If you model just some two or three examples, long CGAL rendering times for that what you have, might be tolerable, as recoding consumes much more time.

For virtual visualization you might want to put in more effort. OpenSCAD has some nice animation support on the CSG-level. Trygon used it to do some amazing things. http://forum.openscad.org/Product-Video-produced-with-OpenSCAD-td15783.html. Much more of course is offered by Blender.

Rudolf
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

nophead
Simply replacing the unions with a cylinder by a hull of two spheres will probably give a decent improvement in speed. Unioning a sphere with a cylinder can be very slow.

On 2 June 2016 at 15:29, Parkinbot <[hidden email]> wrote:
bsuter wrote
> In that post you wrote "A single sweep() along a smoothed trajectory
> will be faster than a union of cylinders and spheres describing the
> same". Could you please explain further what you mean, in OpenSCAD
> terms, by "single sweep() along a smoothed trajectory"?

This code is a good starting point and show case:
http://www.thingiverse.com/thing:547620/#files
to get an idea, how sweeps behave. The (implicit) union() is needed for
marriage of different sweep trajectories.


> Certainly each of my branches can be modeled as a sequence of
> nodes, where each node has an associated radius. Is there a way to
> represent this directly in OpenSCAD? I.e. to specify a trajectory in
> 3D, and then extrude (ideally a circular cross-section, but a polygon
> would work too) along this trajectory, with the extrusion radius
> defined at each node?

There is no language support for general extrusion along trajectories, and
there is no data structure support (or let's say only weak array support)
for things like trees and so on. But there are libraries like sweep() and
skin() going into this direction. Also see here:
http://www.thingiverse.com/thing:900137


>> I've implemented some Matlab class to generically describe arteries with
>> an
>> interpolation scheme. The output is a winding 'wire' in 3D with free
>> radius
>> at each point in STL-format.

this is an example of the outcome:
http://forum.openscad.org/Non-Linear-Transformations-tp14539p14597.html

The class simply does some nspline calculation over a sequence of 4D vectors
(x, y, z, r) describing a skeleton line. Most of the code is for handling
STL-triangulation and output.


>> In lack of an own union or furcation operator
>> capable to do the intersection triangulation we currently use OpenSCAD
>> and
>> Blender to compose porperly placed wires into tree structures which we
>> again
>> cut into puzzle pieces for 3D print.
> This part I don't understand ;(

STL triagulation is easy and fast if you don't have to check for
self-intersection (SI). I.e. if the code can assume, no SI will happen, it
can skip all tests and calculations that would be needed to treat SI and
just knit some generic triangulation pattern in a straight forward manner.
Its helps to think about physical knitting to understand what is going on.
For the puzzle part: It might be interesting to print a structure in pieces,
e.g. to compose a construction kit or similar (which can also be used for
moulding).  In your case, it might be advantegous to print the neurons and
the dendrits as destinct pieces and design a connector for piecing parts
together as puzzle.

A union of any non-SI shapes might be SI - and will be SI at defined
locations in the case of furcations and trees. So, if SI is only happening
at furcation points, the intersection can be calculated somehow in a fast
manner, to get a proper triangulation. Have a look, how the union of two
cylinders is mapped into STL (to get a first impression, you can use F10 and
Ctrl+1 which only partly triangulates).
This is the principle. OpenSCAD has this operator in form of union(). So,
one way is to import a bunch of branches (STLs) already correctly placed und
let OpenSCAD do the work dirty work in a general way.
In fact at CSG-level (F5) this is done only virtually by the graphics card.
And when it comes to STL output (F6) CGAL is used, which takes its time.

Knowing that all your branches will not SI, except at furcation points, you
can write your own specialized (and thus fast) union() that remeshes just
the furcation intersection part of the branches.


> My main goal is (a) virtual reality visualization of many neurons
> together, and (b) 3D printing of individual neurons.

It depends on how often this is repeated. If you model just some two or
three examples, long CGAL rendering times for that what you have, might be
tolerable, as recoding consumes much more time.

For virtual visualization you might want to put in more effort. OpenSCAD has
some nice animation support on the CSG-level. Trygon used it to do some
amazing things.
http://forum.openscad.org/Product-Video-produced-with-OpenSCAD-td15783.html.
Much more of course is offered by Blender.

Rudolf




--
View this message in context: http://forum.openscad.org/STL-without-render-tp17503p17530.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

bsuter
Aha, I think I see what you mean:
1. What I'm doing now: cylinder from point A to point B, a sphere at
point B, another cylinder from point B to point C

2. What you suggest: spheres at points A, B and C; plus hull() of each
pair of spheres? But would I need to duplicate the sphere at point B,
since it's part of two hulls?

Did I understand that correctly? I'll try this.

I found another thread that discusses something similar. Interestingly
it starts with someone doing a hull() of two spheres, and hoping for a
faster solution.
http://forum.openscad.org/Rods-between-3D-points-td13104.html

3. User runsun then suggested: "It will be much faster if you can
generate points on both end points and use polyhedron.", followed by
detailed instructions.

In my case, I am able to generate the points framing a circle at each
end of the intended segment, call this pts_base and pts_top. So it
sounds like I could try:
pts = concat(pts_base, pts_top);
faces = faces(shape="rod", nside= len(pts_base), nseg=1);
polyhedron(points=pts, faces=faces("rod", nside=12));

However, this still needs some way to "fill the joint" at the
intersection of two such rods, and from what I've been reading in this
thread, it sounds like maybe it's precisely this problem (which I
"solved" by inserting a sphere at each joint) that is computationally
expensive?


On Thu, Jun 2, 2016 at 6:36 PM, nophead [via OpenSCAD]
<[hidden email]> wrote:

> Simply replacing the unions with a cylinder by a hull of two spheres will
> probably give a decent improvement in speed. Unioning a sphere with a
> cylinder can be very slow.
>
> On 2 June 2016 at 15:29, Parkinbot <[hidden email]> wrote:
>>
>> bsuter wrote
>> > In that post you wrote "A single sweep() along a smoothed trajectory
>> > will be faster than a union of cylinders and spheres describing the
>> > same". Could you please explain further what you mean, in OpenSCAD
>> > terms, by "single sweep() along a smoothed trajectory"?
>>
>> This code is a good starting point and show case:
>> http://www.thingiverse.com/thing:547620/#files
>> to get an idea, how sweeps behave. The (implicit) union() is needed for
>> marriage of different sweep trajectories.
>>
>>
>> > Certainly each of my branches can be modeled as a sequence of
>> > nodes, where each node has an associated radius. Is there a way to
>> > represent this directly in OpenSCAD? I.e. to specify a trajectory in
>> > 3D, and then extrude (ideally a circular cross-section, but a polygon
>> > would work too) along this trajectory, with the extrusion radius
>> > defined at each node?
>>
>> There is no language support for general extrusion along trajectories, and
>> there is no data structure support (or let's say only weak array support)
>> for things like trees and so on. But there are libraries like sweep() and
>> skin() going into this direction. Also see here:
>> http://www.thingiverse.com/thing:900137
>>
>>
>> >> I've implemented some Matlab class to generically describe arteries
>> >> with
>> >> an
>> >> interpolation scheme. The output is a winding 'wire' in 3D with free
>> >> radius
>> >> at each point in STL-format.
>>
>> this is an example of the outcome:
>> http://forum.openscad.org/Non-Linear-Transformations-tp14539p14597.html
>>
>> The class simply does some nspline calculation over a sequence of 4D
>> vectors
>> (x, y, z, r) describing a skeleton line. Most of the code is for handling
>> STL-triangulation and output.
>>
>>
>> >> In lack of an own union or furcation operator
>> >> capable to do the intersection triangulation we currently use OpenSCAD
>> >> and
>> >> Blender to compose porperly placed wires into tree structures which we
>> >> again
>> >> cut into puzzle pieces for 3D print.
>> > This part I don't understand ;(
>>
>> STL triagulation is easy and fast if you don't have to check for
>> self-intersection (SI). I.e. if the code can assume, no SI will happen, it
>> can skip all tests and calculations that would be needed to treat SI and
>> just knit some generic triangulation pattern in a straight forward manner.
>> Its helps to think about physical knitting to understand what is going on.
>> For the puzzle part: It might be interesting to print a structure in
>> pieces,
>> e.g. to compose a construction kit or similar (which can also be used for
>> moulding).  In your case, it might be advantegous to print the neurons and
>> the dendrits as destinct pieces and design a connector for piecing parts
>> together as puzzle.
>>
>> A union of any non-SI shapes might be SI - and will be SI at defined
>> locations in the case of furcations and trees. So, if SI is only happening
>> at furcation points, the intersection can be calculated somehow in a fast
>> manner, to get a proper triangulation. Have a look, how the union of two
>> cylinders is mapped into STL (to get a first impression, you can use F10
>> and
>> Ctrl+1 which only partly triangulates).
>> This is the principle. OpenSCAD has this operator in form of union(). So,
>> one way is to import a bunch of branches (STLs) already correctly placed
>> und
>> let OpenSCAD do the work dirty work in a general way.
>> In fact at CSG-level (F5) this is done only virtually by the graphics
>> card.
>> And when it comes to STL output (F6) CGAL is used, which takes its time.
>>
>> Knowing that all your branches will not SI, except at furcation points,
>> you
>> can write your own specialized (and thus fast) union() that remeshes just
>> the furcation intersection part of the branches.
>>
>>
>> > My main goal is (a) virtual reality visualization of many neurons
>> > together, and (b) 3D printing of individual neurons.
>>
>> It depends on how often this is repeated. If you model just some two or
>> three examples, long CGAL rendering times for that what you have, might be
>> tolerable, as recoding consumes much more time.
>>
>> For virtual visualization you might want to put in more effort. OpenSCAD
>> has
>> some nice animation support on the CSG-level. Trygon used it to do some
>> amazing things.
>>
>> http://forum.openscad.org/Product-Video-produced-with-OpenSCAD-td15783.html.
>> Much more of course is offered by Blender.
>>
>> Rudolf
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.openscad.org/STL-without-render-tp17503p17530.html
>> Sent from the OpenSCAD mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://forum.openscad.org/STL-without-render-tp17503p17531.html
> To unsubscribe from STL without render?, click here.
> NAML
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

nophead


On 2 June 2016 at 18:05, bsuter <[hidden email]> wrote:
Aha, I think I see what you mean:
1. What I'm doing now: cylinder from point A to point B, a sphere at
point B, another cylinder from point B to point C

2. What you suggest: spheres at points A, B and C; plus hull() of each
pair of spheres? But would I need to duplicate the sphere at point B,
since it's part of two hulls?

Yes but duplicating a sphere takes no time at all because it is cached. Hull is faster than union in later versions of OpenScad but you still need to union the results so it won't be very fast but perhaps twice the current speed at a guess.
 

Did I understand that correctly? I'll try this.

I found another thread that discusses something similar. Interestingly
it starts with someone doing a hull() of two spheres, and hoping for a
faster solution.
http://forum.openscad.org/Rods-between-3D-points-td13104.html

3. User runsun then suggested: "It will be much faster if you can
generate points on both end points and use polyhedron.", followed by
detailed instructions.

In my case, I am able to generate the points framing a circle at each
end of the intended segment, call this pts_base and pts_top. So it
sounds like I could try:
pts = concat(pts_base, pts_top);
faces = faces(shape="rod", nside= len(pts_base), nseg=1);
polyhedron(points=pts, faces=faces("rod", nside=12));

However, this still needs some way to "fill the joint" at the
intersection of two such rods, and from what I've been reading in this
thread, it sounds like maybe it's precisely this problem (which I
"solved" by inserting a sphere at each joint) that is computationally
expensive?

Unioning things that have lots of vertices is very expensive. Generating polyhedra from points is very fast but you have to be able to fully describe the shape mathematically. That is not easy where there is a branch, so best case I think you will need a union per branch or a very clever recursive function that makes one big polyhedron.
 


On Thu, Jun 2, 2016 at 6:36 PM, nophead [via OpenSCAD]
<[hidden email]> wrote:

> Simply replacing the unions with a cylinder by a hull of two spheres will
> probably give a decent improvement in speed. Unioning a sphere with a
> cylinder can be very slow.
>
> On 2 June 2016 at 15:29, Parkinbot <[hidden email]> wrote:

>>
>> bsuter wrote
>> > In that post you wrote "A single sweep() along a smoothed trajectory
>> > will be faster than a union of cylinders and spheres describing the
>> > same". Could you please explain further what you mean, in OpenSCAD
>> > terms, by "single sweep() along a smoothed trajectory"?
>>
>> This code is a good starting point and show case:
>> http://www.thingiverse.com/thing:547620/#files
>> to get an idea, how sweeps behave. The (implicit) union() is needed for
>> marriage of different sweep trajectories.
>>
>>
>> > Certainly each of my branches can be modeled as a sequence of
>> > nodes, where each node has an associated radius. Is there a way to
>> > represent this directly in OpenSCAD? I.e. to specify a trajectory in
>> > 3D, and then extrude (ideally a circular cross-section, but a polygon
>> > would work too) along this trajectory, with the extrusion radius
>> > defined at each node?
>>
>> There is no language support for general extrusion along trajectories, and
>> there is no data structure support (or let's say only weak array support)
>> for things like trees and so on. But there are libraries like sweep() and
>> skin() going into this direction. Also see here:
>> http://www.thingiverse.com/thing:900137
>>
>>
>> >> I've implemented some Matlab class to generically describe arteries
>> >> with
>> >> an
>> >> interpolation scheme. The output is a winding 'wire' in 3D with free
>> >> radius
>> >> at each point in STL-format.
>>
>> this is an example of the outcome:
>> http://forum.openscad.org/Non-Linear-Transformations-tp14539p14597.html
>>
>> The class simply does some nspline calculation over a sequence of 4D
>> vectors
>> (x, y, z, r) describing a skeleton line. Most of the code is for handling
>> STL-triangulation and output.
>>
>>
>> >> In lack of an own union or furcation operator
>> >> capable to do the intersection triangulation we currently use OpenSCAD
>> >> and
>> >> Blender to compose porperly placed wires into tree structures which we
>> >> again
>> >> cut into puzzle pieces for 3D print.
>> > This part I don't understand ;(
>>
>> STL triagulation is easy and fast if you don't have to check for
>> self-intersection (SI). I.e. if the code can assume, no SI will happen, it
>> can skip all tests and calculations that would be needed to treat SI and
>> just knit some generic triangulation pattern in a straight forward manner.
>> Its helps to think about physical knitting to understand what is going on.
>> For the puzzle part: It might be interesting to print a structure in
>> pieces,
>> e.g. to compose a construction kit or similar (which can also be used for
>> moulding).  In your case, it might be advantegous to print the neurons and
>> the dendrits as destinct pieces and design a connector for piecing parts
>> together as puzzle.
>>
>> A union of any non-SI shapes might be SI - and will be SI at defined
>> locations in the case of furcations and trees. So, if SI is only happening
>> at furcation points, the intersection can be calculated somehow in a fast
>> manner, to get a proper triangulation. Have a look, how the union of two
>> cylinders is mapped into STL (to get a first impression, you can use F10
>> and
>> Ctrl+1 which only partly triangulates).
>> This is the principle. OpenSCAD has this operator in form of union(). So,
>> one way is to import a bunch of branches (STLs) already correctly placed
>> und
>> let OpenSCAD do the work dirty work in a general way.
>> In fact at CSG-level (F5) this is done only virtually by the graphics
>> card.
>> And when it comes to STL output (F6) CGAL is used, which takes its time.
>>
>> Knowing that all your branches will not SI, except at furcation points,
>> you
>> can write your own specialized (and thus fast) union() that remeshes just
>> the furcation intersection part of the branches.
>>
>>
>> > My main goal is (a) virtual reality visualization of many neurons
>> > together, and (b) 3D printing of individual neurons.
>>
>> It depends on how often this is repeated. If you model just some two or
>> three examples, long CGAL rendering times for that what you have, might be
>> tolerable, as recoding consumes much more time.
>>
>> For virtual visualization you might want to put in more effort. OpenSCAD
>> has
>> some nice animation support on the CSG-level. Trygon used it to do some
>> amazing things.
>>
>> http://forum.openscad.org/Product-Video-produced-with-OpenSCAD-td15783.html.
>> Much more of course is offered by Blender.
>>
>> Rudolf
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.openscad.org/STL-without-render-tp17503p17530.html
>> Sent from the OpenSCAD mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]

>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://forum.openscad.org/STL-without-render-tp17503p17531.html
> To unsubscribe from STL without render?, click here.
> NAML


View this message in context: Re: STL without render?

Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

Neon22
As pointed out above. Nophead's solution of "hull between spheres at junction points" is the least effort for speedup. You can set the sphere resolution low ($fn) for faster preview.

The route best suited to your specific problem is extruding a cross sectiin along a 'wire' for which there is code linked above. You' d make many 'wires' and then skin them, finally union these together if you needed a single solid object.
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

bsuter
> As pointed out above. Nophead's solution of "hull between spheres at
> junction points" is the least effort for speedup. You can set the sphere
> resolution low ($fn) for faster preview.

Thank you - preview is instantaneous (sub-second) for my current
solution (cylinders and spheres), but render takes 2.5 hours per
neuron (and I have many neurons to render). I will try the "hull
between spheres at junction points" and report back.

> The route best suited to your specific problem is extruding a cross sectiin
> along a 'wire' for which there is code linked above. You' d make many
> 'wires' and then skin them, finally union these together if you needed a
> single solid object.

What I don't yet understand about this solution is how the "joint" or
"junctions" are handled: does the extrusion "turn the bend", so to
speak, or does this solution still require additional spheres (or ?)
at the points where the wire changes direction?

Many thanks!

>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://forum.openscad.org/STL-without-render-tp17503p17535.html
> To unsubscribe from STL without render?, click here.
> NAML
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

Parkinbot
the problem is that a general union() will check each edge against each edge of each other shape. This is a quadratic problem, if no optimization or short cut scheme is employed. Double number of edges (shapes) four times longer execution.
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

Ronaldo
In reply to this post by nophead
I did some very basic speed tests and even so the results were very surprising.

A sphere with 250000 facets ($fn=500) takes virtually no time to render (less than 1sec). But if you render the union of a few disjoint spheres the time grows very fast:
               total #        total         total #
               facets         time        of spheres ($fn=20)
                   362          0s              1
                  3100        31s            10
                 31000      550s           100
The union of 10 coincident spheres (r=10, $fn=20) spent 800s!, that is much more than 10 similar disjoint spheres.

What was a lot surprising for me was the time only one refined cylinder spent to render.
                # facets           time
                 50000               7s
                100000             29s
                200000           129s
                250000           212s
To confirm that using polyhedron is faster, I wrote the following code that is able to generate a set (union) of disjoint "spheres"  using only one call of polyhedron:
n = 20; // $fn
m = n/2;
N = 2000; // number of spheres
radius = 10;

unitary_circle = [ for(i=[0:n]) [ cos(360*i/n), sin(360*i/n), 0 ] ];
// sphere
sphere_vertices  = radius*[ for( j=[-m/2:m/2], p=unitary_circle )
                            cos(180*j/m) * p + [0, 0, sin(180*j/m)] ];
nvert = len(sphere_vertices);

// triangulated faces of the sphere
faces = concat(
            [ for(i=[0:n-1])
                    [ 0, n+i+1, n+i+2 ] ] ,
            [ for(j=[1:m-1], i=[0:n-1])
                    [ (n+1)*j+i+1, (n+1)*j+i, (n+1)*(j+1)+i ] ] ,
            [ for(j=[1:m-1], i=[0:n-1])
                    [ (n+1)*j+i+1, (n+1)*(j+1)+i, (n+1)*(j+1)+i+1 ] ] ,
            [ for(i=[0:n-1])
                    [ (n+1)*(m-1)+i, (n+1)*(m+1)-1, (n+1)*(m-1)+i+1] ] ) ;

// vertices of the union of N spheres
unispheres = [ for(k=[1:N], p=sphere_vertices) p+[25*k,0,0] ];

// facets of the union of N spheres
unifaces  = [ for(k=[1:N], f=faces) [for(i=f) i+nvert*(k-1) ] ];

polyhedron( points = unispheres, faces = unifaces);
sphere(10); // a regular sphere
As expected, the set of spheres generated by this code renders a lot faster than the regular union of OpenSCAD spheres. And the time seems to grow linearly:
timing of a set of sphere in one polyhedron
               # facets       time        # spheres
                 40000            2s         100
                400000          22s        1000
A neuron with just 1600 disjoint $fn=20 spheres will require a lot of time to render. I don't believe that doing hulls between spheres and the cylinders would result in a significant gain because those parts need to be unioned and that is the bottleneck. To get a significant reduction in the render time you will need to code the generation of vertices and facets to be sent to polyhedron as the code above do. Doing that for a whole neuron is a huge task.

The lesson here is: to do CSG operations with B-rep (the internal representation CGAL uses) works only for small number of primitives. To deal with a great number of primitives OpenSCAD needs to look for alternative internal representations.
tp3
Reply | Threaded
Open this post in threaded view
|

Re: STL without render?

tp3
On 06/03/2016 03:58 AM, Ronaldo wrote:
> The lesson here is: to do CSG operations with B-rep (the internal
> representation CGAL uses) works only for small number of primitives.
> To deal with a great number of primitives OpenSCAD needs to look
> for alternative internal representations.
>
Yes, this is all pretty much known, and the discussion about
alternatives is also not new. The Problem is that there's no
real alternative in sight.

The page collecting some info is:
https://github.com/openscad/openscad/wiki/Project%3A-Survey-of-CSG-algorithms

ciao,
  Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
12