Latest revision |
Your text |

Line 47: |
Line 47: |

| == Detailed Description == | | == Detailed Description == |

| | | |

| + | * Determine pipe start and end points |

| + | - Pipe.c contains the lin_pipe structure which contains atributes for the start and end regions of the pipe. |

| + | - Pipe_regions(): method which reads vectors for the start and end regions of the pipe. Test functionality with unit tests and store results. |

| | | |

− | ~~I believe the computational geometry problem of approximating triangular meshes describing pipes ~~and ~~pipe T- and Y-joints, using solid geometry pipe structures instead.~~
| + | * Determine BoT inner and outer diameters |

| | | |

− | ~~ The original programs obviously model ~~the ~~lines and flows using data structures similar to pipes, not as triangular meshes. [Fluid analysis often requires some sort of finite element cell meshing, but I bet they are formed as needed, from the original ~~pipe ~~structures, instead of always describing the pipes as meshes.~~
| + | * Traverse the BoT line placing pipe vertices where necessary |

| | | |

− | ~~BRL-CAD has a ~~pipe ~~primitive, which takes a list of vertices the pipe axis passes through, with inner radius, outer radius, and bend radius ~~for each ~~vertex also specified. Note that there have been reports (crashes) when the primitive is used, so I'm not certain how reliable or well-tested the primitive is~~.
| + | * negotiate line models that have T or Y shaped intersections creating pipe solids for each leg. |

| | | |

− | ~~This problem shares certain interesting properties with another ~~of ~~my favourites, angular momentum cancellation for nanocluster simulation.~~
| + | * utilize the pipe solid bend radius attribute to limit the number of vertices necessary to create a bend |

| | | |

− | ~~The Bot ~~to ~~Pipe converter problem has ~~a ~~symmetry "axis", with a point cloud surrounding that axis -- except that the "axis" itself is a vague concept, and may even branch (T and Y joints~~) ~~in this case. In many ways, the pipe case is easier, since the mesh provides the vertex connectivity graph.~~
| + | * Apply a vertex reduction algorithm based on user defined tolerances (angular tolerance to define a straight segment) |

| | | |

| + | * Implement options allowing the automatic generation of a fluid component (fuel or hydraulic fluid within the line) |

| | | |

− | ~~= Unravelling Meshes =~~
| + | * Implement options that allow for automatic Boolean operations into both line and fluid Regions |

− | ~~I'd start by unraveling the meshes.~~
| |

− | | |

− | ~~Look at the triangular mesh connectivity graph. Given a specific vertex, the circuit with the shortest 3D circumference (sum of Cartesian edge lengths) containing that vertex, such that you cannot short-circuit/bypass any of the vertices in the circuit, is a cross section of the cylinder the mesh approximates at ~~that ~~point. (The circuit obviously has to have more vertices than the maximum number of sides in the vertex mesh polygons; otherwise you're just looking at a single polygon.)~~
| |

− | | |

− | ~~Such polygons are the shortest ones containing that vertex, that circle the cylinder/pipe axis (the vertex mesh approximates) at that point. ~~
| |

− | ~~Also a relatively straightforward way to analyse the mesh to obtain the roughly-cross-sectional polygons would be: ~~
| |

− | | |

− | ~~* determine the order of those polygons from the connectivity graph.~~
| |

− | ~~The above will give a stack of not-exactly-flat-but-close, almost-circular polygons, forming the approximate cross sections of the pipe. (The inner mesh will correspond to the pipe inner surface, and outer mesh to outer surface. Because the 'pipe' primitive can only describe pipes with symmetric walls, I'll assume the cross sections are coaxial/concentric.)~~
| |

− | | |

− | ~~Also, If the mesh is very coarse, it will not model a pipe, but a twisted polygonal rod. If such data is prevalent in practice, I'd also consider a completely different approach: ~~
| |

− | | |

− | ~~*sweeping the meshes with spheres [or cylinders, in practice]. It will be a lot slower approach, although there are lots of mathematical tricks which can be employed to make it faster. Here, the sphere centers and radiuses form a set of intermediate data, to which the pipe parameters are fitted to.)~~
| |

− | | |

− | ~~At joints, the mesh gets silly so I'll model everywhere else first, and then extrapolate the joint properties last, using the mesh vertices as helpful point cloud data only. (For example, ~~for ~~a T or Y joint, all three legs of the joint tend to be straight. The point closest to all three axis vectors is most likely the joint point. ~~
| |

− | | |

− | ~~* Using Leg Information~~
| |

− | ~~Another option is to use the leg information to construct a prototype joint, ~~and ~~compare the joint prototype to the mesh data, adjusting the parameters to obtain the best fit.)~~
| |

− | | |

− | ~~Any small-scale features at joints like the nooks used in old sewers near tight bends, causing turbulence in the flow, keeping the bend clean from debris -- are always lost, but that should not matter here anyway: the 'pipe' primitive cannot model them anyway.~~
| |

− | | |

− | ~~Overall, I think it's quite achievable to implement the triangular mesh to pipe conversion -- either as a BRL-CAD command, or as an external utility. A lot of work, but good results are certainly achievable.~~
| |

| | | |

| == Deliverables == | | == Deliverables == |