Thu Jun 2 13:20:56 EDT 2016

```On 2 June 2016 at 18:05, bsuter <ben.suter at gmail.com> 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.
>
> 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] <http:///user/SendEmail.jtp?type=node&node=17532&i=0>>
> 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
> >> >> at each point in STL-format.
> >>
> >> this is an example of the outcome:
> >>
> >> 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
> >> >> 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.
> >> has
> >> some nice animation support on the CSG-level. Trygon used it to do some
> >> amazing things.
> >>
> >>
>
> >> Much more of course is offered by Blender.
> >>
> >> Rudolf
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >> Sent from the OpenSCAD mailing list archive at Nabble.com.
> >>
> >> _______________________________________________
> >> [hidden email]
> >
> >
> >
> > _______________________________________________
> > [hidden email]
> >
> >
> > ________________________________
> > below:
> > NAML
>
> ------------------------------
> View this message in context: Re: STL without render?
>
> at Nabble.com.
>
> _______________________________________________