yep… i was right. it gives pretty good result:

 	fn getBestRotation block target step:45 =
 	(
 		fn getAngle dir vector = 
 		(
 			local up = [0,0,1]
 			ang = acos (dot dir vector)
 			if dot (cross dir up) (cross vector up) < 0 do ang += 180
 			ang
 		)
 		
 		local end = block.children[1]
 		local origin = block.transform
 		local vector = normalize (target.pos - end.pos) 
 		local dist = getAngle end.dir vector, best = 0
 		for angle=0 to 360 by step do 
 		(
 			block.transform = prerotatez block.transform step
 			if (d = getAngle end.dir vector) < dist do
 			(
 				dist = d
 				best = angle
 			)
 		)
 		block.transform = prerotatez origin best
 	)
 

Yeah that gives some pretty badass results.

I’ll get this all implemented and shoot out a build tonight for everyone to mess with. This has turn into quite a fun tool.

Like you have previously mentioned it has drawn quite a lot of attention. I can see why.

there is another idea…
we have to help a little our chain to meet the target.
first of all do the making of new block and the finding the best rotation for it in the same loop.
but every next round check how last one helped. if the direction is still bad (some angle threshold) we need to add probability to pick a bended piece, if we are going in right direction add probability to pick a straight one.

In doing this is the previous pipe is pointing way off in a bad direction it will know to pick a piece of pipe that has a bend on it to help reach the targeted point much quicker than it randomly choosing (the wrong piece…a straight pipe) when it really needs a bent one.

Alright, yea i can see that being a very cool idea and worth implementing.

I’ll get this last round of bits which we just wrapped up on with the rotation/direction implemented and then from there we can then add the probability part. I think that will be very clever and cool.

no… it’s not a right solution. we have to know what type a piece we use. there might be the types:

fast move (long straight piece)

slow move (short)

default move

fast turn (90?)

slow turn (15?)

default turn (45?)

Yeah we can help categorize the types of pipes by making those names part of the pipe rig (start helper)

Update.
Install as described in instructions file located in zip.

Things done:

• Added some bug checks when creating template rigs
• Added Build type options ‘Free flow’ and ‘To target’
• Added Smart rotation function (contributed by Denis) for rotating objects
• Pick Object for target
• Updated icons (not final ones)

Things to add/wishlist:

• Denis ‘Probability Geo Selection’
• Intersection detection system or bounding box collision
• In addition with the sentence above I’d like to add a checkbox which enables/disables intersection detection.
• Along with the two mentioned above, I’d like to add the option for the system to find the ‘endCap’ piece of geo, if available in the pipe list, and use that as the end piece to the pipes if they no longer can grow from their ends.

Does anyone have methods of implementing an undo? I noticed the pipes gen doesn’t seem to handle them to nicely.

I’ve gone ahead and here is the latest one along with a few bug fixes.

Denis!
Got some new avenues here. Check out this latest zip file. Open the max file and once you run pipes gen…changes the rotate range to: 90 – 180 then steps to 90.
Create the first piece and then rotate it to lay it flat.

Then generate. You’ve got yourself a roadway system! Check out the file and let me know your thoughts. If users created the roadway on a grid like system it may be possible to replace intersections with the appropriate piece.

Just a cool idea i figured I would share.

it doesn’t make sense for a mapped or recursive function…