Hello,

I'm looking for a bit of input.

My initial thought regarding the connection of arbitrarily placed cylinders with
sections of a torus follows, which as you will see presented a number of
annoying problems which seem to be resolved by my second idea.

[Idea 1]
Lets assume that I have trace placed cylinders of a constant radius and variable
length all over some poor object, and have saved in an array the two vectors
describing the cylinder along with the translate vector from trace().

Problem 1)
I'm not sure how I might handle the required Reorient_Trans() in terms of
manipulating the three previously saved vectors.

Problem 2)
Determining the parameters of the torus which would correctly connect two
cylinders. Would need to ensure no torus is inside() my traced object, if
inside(), take some alternate action still resulting in a cylinder-cylinder
connection.

Problem 3)
Determining exactly what kind of torus section would be appropriate in degrees,
and modifying the radius of the torus to not look stupid from over/under hang.

Problem 4)
Ensure no duplicate or overlapping connections/objects

Problem 5)
Placing objects along the path defined by the result from above.

[Idea 2]
This lead me to think my initial idea would be the entirely wrong way to go
about this, and perhaps the right answer would be to generate a halton cloud of
points inside the bounding box of the target object but not inside the target
itself. Then I could place disposable spheres of the appropriate diameter along
that path, trace() snap them to the object, test for any intersections between
them with inside(), eliminate violating points, connect the remaining points
with some kind of path/spline, then sphere_sweep using that path.

On initial evaluation, this seems to solve every problem from the other very
kludgey solution.

Am I on the right track here? Any head-slappers I missed?

I'm not entirely sure how to go about full implementation of [Idea 2], though I
have a good enough idea to at least start the thing.

I appreciate any input, as always.

Thank you,
Ian

Post a reply to this message

Le 14/10/2011 15:11, [GDS|Entropy] a écrit :
> Hello,
> 
> I'm looking for a bit of input.
> 
> My initial thought regarding the connection of arbitrarily placed cylinders with
> sections of a torus follows, which as you will see presented a number of
> annoying problems which seem to be resolved by my second idea.
> 
> [Idea 1]
> Lets assume that I have trace placed cylinders of a constant radius and variable
> length all over some poor object, and have saved in an array the two vectors
> describing the cylinder along with the translate vector from trace().
> 
> Problem 1)
> I'm not sure how I might handle the required Reorient_Trans() in terms of
> manipulating the three previously saved vectors.
> 
> Problem 2)
> Determining the parameters of the torus which would correctly connect two
> cylinders. Would need to ensure no torus is inside() my traced object, if
> inside(), take some alternate action still resulting in a cylinder-cylinder
> connection.

sub-issue: a cylinder's end defines 2 vectors: 1 position, 1 normal.
When connecting 2 cylinders' ends, you ends up with 4 vectors.
That's too much to allow an always matching torus.

Cross-product of normals give a plane-normal (unless both normals are
parrallel). The second position must be on a parralel plan that contains
also the first position. Very unlikely.
(and the torus will be in that plane too, as the center of the torus is
at the intersection of the perpendicular of the normal ).

It's the classical issue of: 1 tangent & 2 points defines a circle. More
informations are just counter-productive.

> 
> Problem 3)
> Determining exactly what kind of torus section would be appropriate in degrees,
> and modifying the radius of the torus to not look stupid from over/under hang.

As previous point showed, that's not a problem. It's just impossible in
most case.

> 
> Problem 4)
> Ensure no duplicate or overlapping connections/objects

Mu.

> 
> Problem 5)
> Placing objects along the path defined by the result from above.
> 
> [Idea 2]
> This lead me to think my initial idea would be the entirely wrong way to go
> about this, and perhaps the right answer would be to generate a halton cloud of
> points inside the bounding box of the target object but not inside the target
> itself. Then I could place disposable spheres of the appropriate diameter along
> that path, trace() snap them to the object, test for any intersections between
> them with inside(), eliminate violating points, connect the remaining points
> with some kind of path/spline, then sphere_sweep using that path.
> 
> On initial evaluation, this seems to solve every problem from the other very
> kludgey solution.
> 
> Am I on the right track here? Any head-slappers I missed?
> 
> I'm not entirely sure how to go about full implementation of [Idea 2], though I
> have a good enough idea to at least start the thing.
> 
> I appreciate any input, as always.
> 
> Thank you,
> Ian
> 
> 
> 
> 


-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

"[GDS|Entropy]" <nomail@nomail> wrote:
> Hello,
>
> I'm looking for a bit of input.
>
> My initial thought regarding the connection of arbitrarily placed cylinders with
> sections of a torus follows, which as you will see presented a number of
> annoying problems which seem to be resolved by my second idea.
>
As noted, connecting two arbitrarily placed cylinders by a torus segment isn't
possible except as a rather special case.

The simplest object that is guaranteed to connect two cylinders is a Bezier
spline which has four control points. p1 and p4 are the cylinder end centres. p2
is such that the vector p2-p1 is along the first cylinder axis. Similarly p4-p3
and the second cylinder axis.

I have a Bezier sweep macro. Joining cylinders of different radii is also
possible

There is some freedom in choosing |p2-p1| and |p4-p3| to make sure kinks and
loops don't appear.

The Bezier spline has the tetrahedron with vertices p1,p2,p3,p4 as its convex
hull, which might help with removing intersections.

However, generating a lot of connected cylinders and ensuring that nothing
intersects would be rather difficult - in general it isn't possible. Think of
six cylinders surrounding a seventh. Join opposite of cylinders (using the
|p2-p1|, |p4-p3| freedom to remove any intersections but keeping the joining
Bezier sweeps as close as possible). There would be no path from the centre
cylinder to any other.

Trying to allow for intersections (with no guarantee of success) by splitting
single Bezier sweeps into multiple sweeps would be possible.

I've never tried to work out whether two Bezier sweeps intersect. Feels like an
interesting problem, but it must have been looked at.

If you want the macro, I can send it.

JimT

Post a reply to this message

"JimT" <nomail@nomail> wrote:
> As noted, connecting two arbitrarily placed cylinders by a torus segment isn't
> possible except as a rather special case.
>
> The simplest object that is guaranteed to connect two cylinders is a Bezier
> spline which has four control points. p1 and p4 are the cylinder end centres. p2
> is such that the vector p2-p1 is along the first cylinder axis. Similarly p4-p3
> and the second cylinder axis.
>
> I have a Bezier sweep macro. Joining cylinders of different radii is also
> possible
>
> There is some freedom in choosing |p2-p1| and |p4-p3| to make sure kinks and
> loops don't appear.
>
> The Bezier spline has the tetrahedron with vertices p1,p2,p3,p4 as its convex
> hull, which might help with removing intersections.
>
> However, generating a lot of connected cylinders and ensuring that nothing
> intersects would be rather difficult - in general it isn't possible. Think of
> six cylinders surrounding a seventh. Join opposite of cylinders (using the
> |p2-p1|, |p4-p3| freedom to remove any intersections but keeping the joining
> Bezier sweeps as close as possible). There would be no path from the centre
> cylinder to any other.

Detecting this and rerouting through a hole with a bendy part, or possibly
killing that cylinder? Elimination of violating components is acceptable.

> Trying to allow for intersections (with no guarantee of success) by splitting
> single Bezier sweeps into multiple sweeps would be possible.
>
> I've never tried to work out whether two Bezier sweeps intersect. Feels like an
> interesting problem, but it must have been looked at.

I love interesting problems. :) I agree, there must have been someone who
encountered a flavor of this problem at some point within the scope of some
discipline or another. However I doubt they are a Pov-NG user. :p

> If you want the macro, I can send it.

Please do, thanks! :)

Ian

Post a reply to this message

> > If you want the macro, I can send it.
>
> Please do, thanks! :)
>
This seems to work.

ft is the multiple of the distance between cylinder ends used for the position
of the internal control points along the line of each cylinder axis. Should give
a proportionate loop for cylinders separated by differing distances.

#include "colors.inc"
//
global_settings {max_trace_level 15}
//
background{White}
//
#macro SF_roundcone(bigend,smallend,bigrad,smallrad)
//
// bigend, smallend are vectors, bigrad, smallrad are scalars
//
//#warning concat("bigrad   is:",str(bigrad,7,3),"\n")
//#warning concat("smallrad is:",str(smallrad,7,3),"\n")
#local big2small = smallend-bigend;
#local el        = vlength(big2small);
#local big2small = big2small/el;
#local ex        = smallrad*el/(bigrad - smallrad);
#local sinalpha  = smallrad/ex;
#local cosalpha  = sqrt(1-sinalpha*sinalpha);
#local conebig   = bigend + (bigrad*sinalpha)*big2small;
#local conesmall = smallend + (smallrad*sinalpha)*big2small;
//
union{
   sphere{smallend smallrad}
   sphere{bigend bigrad}
   cone{conebig bigrad*cosalpha conesmall smallrad*cosalpha}
     }
//
#end
//
#macro SF_snake(nsegs,p1,p2,p3,p4,r1,r2,r3,r4)
//
// nsegs Number of segmennts
// p1-p4 Positions of Bezier Spline control points
// r1-r4 Radii of shape used as Bezier control points
//
  #local pLast = p1;
  #local rLast = r1;
  #local icount = 0;
  union{
    #while(icount< nsegs)
      #local icount = icount + 1;
      #local tNow = icount/nsegs;
      #local f1 = (1-tNow)*(1-tNow)*(1-tNow);
      #local f2 = 3*tNow*(1-tNow)*(1-tNow);
      #local f3 = 3*tNow*tNow*(1-tNow);
      #local f4 = tNow*tNow*tNow;
      #local pNow = f1*p1+f2*p2+f3*p3+f4*p4;
      #local rNow = f1*r1+f2*r2+f3*r3+f4*r4;
//
      #if(rNow > rLast)
        object{SF_roundcone(pNow,pLast,rNow,rLast)}
      #else
        #if(rNow < rLast)
          object{SF_roundcone(pLast,pNow,rLast,rNow)}
        #else
          sphere{pNow rNow}
          sphere{pLast rLast}
          cylinder{pNow pLast rLast}
        #end
      #end
      #local pLast = pNow;
      #local rLast = rNow;
    #end
        }
#end
// First cylinder
#declare p11 = <0,0,0>;
#declare p12 = <0,4,0>;
#declare r11 = 1;
//Second cylinder
#declare p21 = <3,0,0>;
#declare p22 = <4,3,2>;
#declare r22 = 0.5;
//
// Bigger ft gives loopier blend
#declare ft = 1.5;
//
#declare cyldist = vlength(p12-p22);
//
#declare p1 = p12;
#declare p2 = p12+ft*cyldist*(p12-p11)/vlength(p12-p11);
#declare p3 = p22+ft*cyldist*(p22-p21)/vlength(p12-p11);
#declare p4 = p22;
//
#declare r1 = r11;
#declare r2 = r11;
#declare r3 = r22;
#declare r4 = r22;
//
#declare nsegs = 50;
//
#declare cylblend = union{
                      cylinder{p11 p12 r11 pigment{Red}}
                      cylinder{p21 p22 r22 pigment{Green}}
                      object{SF_snake(nsegs,p1,p2,p3,p4,r1,r2,r3,r4)
pigment{Blue}}
                         }
object{cylblend translate <0,-3,0>}
object{cylblend rotate <0,45,0> translate <0,-3,7>}
object{cylblend rotate <0,-45,0> translate <0,-3,-7>}
//
camera {orthographic location <15,0,0> look_at <0,0,0>}
light_source {<400,200,-300> rgb <1, 1, 1.00> shadowless}

Post a reply to this message

"JimT" <nomail@nomail> wrote:
> > > If you want the macro, I can send it.
> >
> > Please do, thanks! :)
> >
> This seems to work.
<Snippage>

That is pretty slick!
I've thought of about 5 things I can use that for in as many seconds, and I'm
itching to give this technique a go.

Thanks!

Ian

Post a reply to this message