Topic: 3D Piping

[Draftek]

I'm considering building a 3D piping package - spec driven.
Modeling at first and then either generated Pipe Isometrics and / or using Isogen.

I would expect to have modes - 2d, 3d single line and 3d solid. No custom objects.

Two ways to approach the 'user interface' - manipulate the usc and / or point filters.
Lines okay for the route?

Anybody got any suggestions or other warnings?

[MickD]

Maybe you might want to tag along with this project once it starts up (the next day or so) -> http://www.theswamp.org/index.php?topic=32074.0

I like the idea of using simple line work for setting out, I then use it to build the 3d model from which I can produce 2d output from. I have a lot of the routines in place already, they just need cleaning up a fresh for this project.

I know sfa about piping but I'm sure there are a lot of simularities on the modelling and data/material side of things. Using the modules in this project will make it a lot easier for you I think.

[Draftek]

Cool!

Very interested to see what you have.
I was thinking of building a generic 3D Geometry library to begin with anyway.

I have some experience with piping - and you are correct, it will be similar at a high level with steel.
I built a 2D commercial package back in the old lisp days.

Thanks

[David Hall]

I use simple lines in my 3d Substation design for drawing the bus runs, it works very well.

[Draftek]

I guess that would work like tubing David,
How do you handle joints like elbows?

[jmaeding]

I am doing this for civil pipelines (no vertical pieces or pipe on top of itself).
You essentially record the centerline alignment with lines and arcs, then record props for fittings and diameter of things.
The issues I see coming up for plant type piping are how you let the user pick and get info about the pipe.
If the pipe wraps under itself, or is vertical, what portion of the pipe is the user wanting to get info on or label?
You could make routines to label automatically at key points, but an interface to allow user placed labels or get info must involve a z parameter.
The programming side gets interesting when you feed the computer a point in space, and tell it to find the closest point on the pipeline.  Its easy for civil's, not easy for mechanicals.

[David Hall]

Inserted blocks.  Probably not the best method, but it works.

[Draftek]

Interesting, thanks.

I'm thinking of having the center line of the pipe be the intelligent object containing all data necessary.
Then having some draw routines for pipe, elbows, valves, etc.
Then having modes like solid3d, single line, double line, etc. that would call the appropriate draw routines.
The user will work in a 3d view.

Iso's will be the tricky part - I think that is where making it ISOGEN compatible will work. The logic for doing that myself will be over my head.

[Draftek]

Mick,
I'm interested to see how you handle connections.

Are you doing this entirely with the geometry or some extra data?

For instance how does the end of a pipe know it's connected to an elbow or is that even necessary?

In your case, I guess a post and beam connection would be similar.

[MickD]

Mick,
I'm interested to see how you handle connections.

Are you doing this entirely with the geometry or some extra data?

For instance how does the end of a pipe know it's connected to an elbow or is that even necessary?

In your case, I guess a post and beam connection would be similar.

The wire frame geometry is the 'first principal' base for calculations of cuts, joins etc. This geometry can store it's own data or it's stored elsewhere with the line being the 'key' to the data. I'll be using a database for this as I think it will be the easiest to maintain and the quickest to query and extract info. Things such as flanges can be stored as data but in your case a lot of these items will be 'on the shelf' and not require detailing so I'd probably opt for a library of ready modelled parts for insertion.

A line for instance has a start and endpoint (direction) and a normal (elevation of 'alignment' if you like in space). It may also be supported at each end and have end conditions such as a connection or welded or cut. These connections are based on the data of the supporting member or in the case of no support just the end conditions.
Regardless of how many connections there may be along a section of pipe or steel (excluding the pipes start and end conditions) all the other connections belong to other sections, ie. their end conditions, so really, all you have to worry about is each end of each pipe section and the intermediate connections look after themselves.

In your case for iso diagrams (I think that's what you're after) I'd probably remove the solids or turn the layers off and leave the wireframe, add some 2d symbols at each connection node and use the 2d engine (which I already have) to 'flatten' the view for detailing.

[Glenn R]

Out of curiousity, is anybody using the Overrule API for these ideas?

[Draftek]

I'm playing with it for a different application and will 'think' about it for this.

Not sure I can build 3d entities inside the overrule yet.

This type of application lends itself to actually drawing the objects since they are more or less off the shelf types.

[Draftek]

I think I understand what your saying Mick and we are on the same page.

[MickD]

Out of curiousity, is anybody using the Overrule API for these ideas?

Yes, I have thought about it but I'm not sure it's going to be useful to produce 2d views from when running through the hlr engine.
The reason being that using the overrule you are only changing how an object draws itself or behaves so I might not be able to pick up the 'solids' as they won't be part of the db proper, they just get drawn.
In this case we only draw a line but the overrule could draw the 3d solids the line represents if you can do that at all, I'm pretty sure you can only draw graphics (not db) primitives.

The behaviour side might be worth looking into though....

The idea I want to persue is to only use Autocad to display output from the modelling engine, ie. get the primitive data (line work), use that as set up geometry, calc the mods required and feed it to the modeller to output to screen. I may also want to port it to other cad app's so this interface will be as slim as possible with only the bare minimum reliance on the host cad application.

[jmaeding]

isn't the overrule for 2010 and above only? I'm on 2009 anyway for a while so have to wait.
I also came to the conclusion that transient entities would be good enough, and simpler from what I have seen.  I'm all for fancy though if it gives a better interface for the pipe designer.
The key thing is to give infomation "on canvas" so the user does not look to some dialog box to decide things.
I'm surprised Autodesk does not have things to do this better, its very common for users to need numbers for elevation, since that is what is cumbersome to manage.  For instance, why does Civil3D not show profile PVI's in plan view?  Its the first thing I did for my LISP tools, even before stationing or BC/EC labels.