Editing User:Foposseleger/GSoC 2014 proposal


Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
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 ==

Please note that all contributions to BRL-CAD may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see BRL-CAD:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)