bsuter ben.suter at gmail.com
Thu Jun 2 13:05:22 EDT 2016

```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.

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?

<ml-node+s1091067n17531h31 at n5.nabble.com> 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 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.
>>
>> 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: http://forum.openscad.org/STL-without-render-tp17503p17532.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...