Using the well-known "Pipe_2" plugin (for generating pipes along curves) as a base, I created a version better suited to my specific needs and requirements.
The plugin is still a bit rough around the edges, and I am continuing to refine it, but it is already fully functional.
If anyone is interested, let me know, and I’ll upload the files here.
Feedback and suggestions are welcome.
=======================

Demonstration of the plugin in action – at the link:

https://youtu.be/QTe_J5uWSv8?si=fkl18p7HA9IW9v4P

=======================
Description:
Creates a pipe along one or more curves and allows you to edit the path without exiting the command.

## Launch
Select curves → launch Pipe3 (or launch first, then select curves). The files `Pipe3_NN.js` and `Pipe3_NN.htm` are located in the MoI `commands` folder.

## Panel
- **Circle / Square / N-Side** — cross-section type. Circle: Diameter (toggles to Radius by clicking the label). Square: H. N-Side: Sides, Circum (size to face / to corner, same as the native Polygon command).
- **Thickness** — wall thickness; 0 or empty — solid pipe.
- **Update** — build/rebuild the pipe using current parameters and the curve.
- **Done** — accept. **Cancel** — remove the pipe and restore the original curve.

## Edit Curve — path editing
- `Move points` ☑ — points are visible on the curve.
- click and drag a point → moves it (along with all other selected points);
- click — select one; Ctrl+click — add/remove; click in empty space — deselect all;
- **Shift+drag**: curve end — moves strictly along its segment; corner — moves within the plane of its adjacent segments.
- The pipe rebuilds after every drag operation (`Hide pipe` ☑ — hides the pipe while editing).
- Fillets near a moved point rebuild automatically (maintaining the same radius).

## Segment — welded elbow
Open the tab → points become visible. Click on a corner (or the midpoint of a fillet) → **Segments** (number of straight sections, 1–10), **Radius** → **Apply**.
Applying with different values ​​modifies that specific corner. If the radius is larger than the original fillet, the elbow segments extend into the adjacent straight sections. ## Preview, Undo, and Commit
- Everything done within **Edit Curve** / **Segment** is a preview. **Update** commits the changes. Exiting the tool without using **Update** (e.g., by deselecting **Move points** or leaving the **Segment** tab) reverts the curve to its initial state.
- **Undo** (button / Ctrl+Z): inside the tool, it reverses one action at a time; outside the tool, it reverts through committed **Update** steps back to the original curve.

Hi Krass,
Great Contribution! Useful!

I'll load it up when you are ready.

Thank you for your effort.

Hi, BurrMan!
Here’s the latest (current) version, 3_107.
"At your own risk!" — well, of course, there’s no real risk; it’s just a figure of speech. :)

If you find any bugs or errors - let me know!

Hi Krass,
"Bugs or errors"?

Loaded it and it runs fine so far.

1 input as you move forward I noticed?

It is looking for a hard coded filename for the command

Most of Michaels commands are "Unaware" of the actual filename. I can name it "JimsBigToe" if I want

Your file errors if the filenames are changed to anything else.

For me I see a limitation there. No big deal now. I'll keep it loaded at its default state..

If you are using "AI" to create this command, maybe Michael can chime in to give what I am speaking about "A Name", Then you can use that to re-Prompt your input and change this behaviour.

But be careful with AI. it really is rubbish.

funny !
Seems works as it must to do! :)

@ Burr,

re:
> Most of Michaels commands are "Unaware" of the actual filename. I can name it "JimsBigToe" if I want
>
> Your file errors if the filenames are changed to anything else.

Renaming them seems to work ok over here, maybe it's been updated above?

It looks like there is a hard coded path in there though:
var LOG_PATH = 'F:/MOI/Pipe3/pipe3_log.txt';

@krass - maybe put these at the top so they're easier for someone to find and update?

- Michael

Hi, BurrMan!

I agree—AI is total nonsense!
But I’m not a programmer at all; I’m a designer and don’t know how to write those beautiful lines of code—so I have to work with the nonsense. :)
Which hard-coded name are you talking about? Tell me, and I’ll fix it.

And—I doubt Mike would have the time to deal with this nonsense of mine.

Frenchy, you totally blew my mind—
the last thing I ever thought was that a tube plugin could be used to create branching corals.

I also wanted to implement another feature...
But alas, experiments showed that the sweep function (using MoI3D's mechanics) imposes limits on the distance between the profile's center (a circle, in this case)
and the polyline's starting point; if the center is too far away, the system doesn't recognize the circle as a valid object for the sweep.

!!! Upd. The issue with the array has been resolved, and I’ll soon post the updated script for your review and critique. Stay tuned for updates!

Hi Michael,
Thank you for looking.

That log path is right below a “version” listing which is the filename. I couldnt find anything else.

When i renamed them i received a “pipe not found” error

But you said it works so let me try again. Maybe i had some type of glitch in my process.

Hi Kraus,
I found one thing to question about the geometry, but i will have to present a case and question to Michael to ask “WHY” it is behaving that way. I couldnt figure it out on my own.

If i draw 2 “boxes” or cubes and face them apart and at an angle. I can delete the 2 faces pointing at each other and run “blend” on both open edges of the boxes and get smooth, matching surfaces that will join

Using the “segment” portion of your command, produces a nice polygonal segmentation that looks good. If i delete a segment or a couple, running blend has touching edges blend “differently” so there is a gap.

There us something about the segmented gap we need to see if ai can solve to make clean geometry. I dont know how to analyze the underlying geometry enough to understand why the “gaps”, or even if it is “normal” or unwanted.

Let me present the case in a bit. Juggling right now

Hi, BurrMan!!
My AI wrote you a couple of lines here )))

"Could you post the .3dm with the problem scene (the segmented pipe with the pieces removed, before Blend)?
I'd like to look at the underlying geometry and see whether it's something the command should do differently."

I'm waiting for the file with the problematic scene (cubes, pipe);
let's try to figure out what the problem is.

Hi Burr, I think that you're probably observing how Blend works differently on "natural surface edges" verses "trimmed edges".

For example here with 2 surfaces like this:


If you select those surfaces and use Edit > Show pts to show the surface control points you can see the UV structure of the control point grid.

Notice how the vertical and horizontal edges are going in the same direction as the control point grid. These are called "isoparms".

The diagonal edges are not isoparms.



If you select 2 of the isoparm edges and do Construct > Blend, you get a result like this:





The directions used with edges that are isoparms will use the other isoparm direction like this:



If you select the 2 edges that are not isoparms you will get a blend like this instead:





For edges that are not isoparms the blend direction will be perpendicular to the edge and not in an isoparm direction.

So it will be like this:



And not this:



When I get a chance to overhaul the Blend command I would like to set up an option for controlling this. But currently if it's an isoparm edge it will align to the other parametric direction but if it is not an isoparm edge it will align perpendicular to the trim edge.

- Michael

@Burr - and the reason why that is happening to the pipe straight segments is that those surfaces are trimmed cylinders, not ruled surfaces (like a loft between 2 curves).

You can see this if you turn on the segment surface's control points.

- Michael

Hi Michael,
Thank you for the great explanation and visuals! Huge help...

I will go over this with Kraus now to see if we can tune up his command, because I think it is usefull.

My results are created in his command when I create a polyline and then use the "square" and his "segmentation" option

I was confused because the result is a "square sweep" with mitered corners, with the segmentation adding the segments to the miters.

Which "should" produce even blends. Its just a square making sharp turns for each segment.

But

When I turned on control points, each segment showed points with large extensions in both directs (Much larger than the actual segment.) So we may need to ask his segmentation to be an "equal divide" so the underlying surfaces are even. Its as if his segments have varying underlying surface lengths. Random even.

I had seen this underlying geometry before, but didnt know enough about it. Like In ViaCad I see alot of "Huge torus points" attached to imported fillets or large underlying construction point objects like hidden cyclinders. I always thought of it as how ACIS did geometry. Actually a great lesson in how to model!!

Let me experiment a bit with what MoI's Regular mitered corners output vs what Krauses command creates to see if they are the same result, or if AI is going about things in a different and unreliable way... (That is the goal to help Kraus get a good, useful tool)

Anyway, enough talk. Let me dig in a bit later today, now that you explained to me what I am seeing. I'll reach out if I need any help.

Thanks again....

Hi Burr, it's not particularly an "error" to have large underlying surfaces, it's a valid way to have geometry constructed.

If you like you can run the ShrinkTrimmedSrf command to reduce them.

I was a little surprised that the segment pieces were trimmed extended cylinders instead of ruled surfaces (like loft between 2 curves) but either way is valid.

But the ruled surface way would probably be a lot simpler to code because you can make something like this in just one use of the Loft command with Loft style = Straight:





That Blend behaves differently on the edge of a box versus the edge of a pipe3 elbow segment (because they are not isoparm edges) is more of a limitation in Blend where it is trying to automatically adjust behavior so that it doesn't pop up a huge set of options.

But it would be useful to be able to control that behavior in Blend so I would like to improve that in the future.

- Michael