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