Since publishing this recent post to simplify the process of generating centrelines for surfaces representing pipes – as imported from an external piping system that only generates SAT files – I’ve been thinking on and off about how best to simplify the process of measuring the lengths of these various “pipes”.
Greg Robinson’s comment over the weekend spurred me on even further (thanks, Greg! :-):
I'm musing on how one might code up the logic of creating a single continuous 3D poly from the horrid collection of surfaces the step file (.sat) make.
This is a daunting logic issue. As humans we can "visually" prescribe a pipe. How does one ask a machine to do it?
Then after you solve the simple piping route how do you explain to the machine there are many to one relationships of pipes, like a tree? Hmmm, growing a tree..…
This is really an interesting point. In my mind it calls into question the common assumption that it makes sense to have the computer attempt to solve this problem on its own. Very often having the user provide some guidance – perhaps selecting the pipes in sequence for them to have their centrelines extracted and stitched, or letting the user select the centrelines to stitch and measure one-by-one – can lead to better results and still save considerable time and effort.
In the coming posts we’re going to attempt the following two things, in fact:
- Provide two simple commands: one to generate centrelines for a bunch of pipe-representing surfaces and another to count the length of a selected set of curves.
- The point is that one of these can be used to feed the other, with some human intervention (to only select the appropriate geometry).
- Provide a more complex command that asks the user to select pipes in sequence, at which point it will validate the contiguity of the sections before continuing and providing an overall length.
We’ll take a look at these two “tasks” in the next few posts. In the meantime, though, it’s worth re-considering the problem itself. The problem is really to count the lengths of the pipes, rather than to create a single centreline (although Greg should really step in and say if a single centreline is actually going to be needed). Looking at this problem in terms of counting the lengths of “connected” sections of pipes ends up being more straightforward and ultimately more accurate: 3D polylines don’t have arc segments, which means that any single 3D object is likely to be an approximation of the desired geometry.
I did look at generating a sequence of 2D Polyline objects using Entity.JoinEntities(), but creating planar entities in 3D space just proved too problematic (it’s an interesting API, though, so I’ll be sure to cover it in a post at some point).
It also occurred to me that having the pipes grouped in some way – for instance using a block or a group – might also be helpful: maintaining the objects in some kind of container or persistent collection would allow the operation to count their lengths to be repeated more easily (which I expect is the primary reason for generating a single centreline).
Should neither of the overall approaches prove to be compelling, we can certainly look at something more automated. But I definitely see headwind there: even the act of deciding whether a particular polyline should belong to a section of pipe or should be discarded as being the centreline of a cross section (the technique we implemented previously generates both, for better or worse) ends up being quite tricky. You can check to see whether it’s perpendicular to the overall pipe direction, but that could provide false positives and negatives, unless you get a more local direction. And that’s a relatively simple piece of the puzzle… which just steers me further towards asking the user, instead. :-)
