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.

[LE3]

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?

That can be easy with the use of ExtrudeAlongPath();

[LE3]

That can be easy with the use of ExtrudeAlongPath();

For example and just to provide a viewable sample, to generate pipes and fittings as 3D solids from a 2D line work:

[MickD]

Thanks LE3, that is pretty much what we want to do but we need to add quite a lot more intelligence into the model for things like bills of material and 2d output. There's quite a bit more to do but it's very doable.

I've created a new open source project here - http://dcs3d.sourceforge.net/

Stay tuned as I'll be uploading some code over the next few days to get going with this and feel free to join the project if you're interested.
cheers,
Mick.

[LE3]

Thanks LE3, that is pretty much what we want to do but we need to add quite a lot more intelligence into the model for things like bills of material and 2d output. There's quite a bit more to do but it's very doable.

I've created a new open source project here - http://dcs3d.sourceforge.net/

Stay tuned as I'll be uploading some code over the next few days to get going with this and feel free to join the project if you're interested.
cheers,
Mick.

Hi Mick,
Is this pipe app something you are doing too?... I read Draftek on the first post....

and yes I know your dcs3d stuff... btw.

[MickD]

There are a lot of similarities in the processes of modelling between piping and structural steel so I think could easily be done in tandem, perhaps a branch just for piping can be created if the need arises.
The main focus of the new project is to build the 3d modelling and 2d engines that can be used for pretty much any 3d projects so the possibilties are endless

[LE3]

There are a lot of similarities in the processes of modelling between piping and structural steel so I think could easily be done in tandem, perhaps a branch just for piping can be created if the need arises.
The main focus of the new project is to build the 3d modelling and 2d engines that can be used for pretty much any 3d projects so the possibilties are endless

I am not fan of the open source - sorry, but can see too the possibilities, have done two projects now in 3D one for structures and the other for pipes - with intelligent objects

PS> Mick, if you still are interested to try/use/test/trash/ignore/etc my old Oriented Bounding Box - OBB app for A2010, let me know, in my last guess it is working on the 90% of the 3D solids.

[MickD]

Will do Luis, thanks.

I wasn't sure if it was you before Luis, good to see you again. Yes, your experience will be invaluable when we get to the harder questions.

I wasn't a big fan of oss either but there comes a time when even what you do have might be quite valuable but it's not worth much if you can only sell a few copies.
I see more possibilities for making possible income in the services (SaaS) side of the software and when you give it away you have a much larger potential customer base to work for than what you have if you sold your software.

Another benefit of the oss business model, if the project builds up some momentum it will have a chance to grow a lot quicker, fix bugs quicker and have much better code which benefits all.

Unless you have a show stopping application it is very hard to make money in software using the closed source business model, if I can pick up a bit of work coding and be paid for it I'll be more than happy.

But, that isn't my main objective, what is though is getting some software up to a usable, solid state so user can get their work done easier and better, every thing else is just a bonus

[LE3]

I wasn't sure if it was you before Luis, good to see you again. Yes, your experience will be invaluable when we get to the harder questions.

I wasn't a big fan of oss either but there comes a time when even what you do have might be quite valuable but it's not worth much if you can only sell a few copies.
I see more possibilities for making possible income in the services (SaaS) side of the software and when you give it away you have a much larger potential customer base to work for than what you have if you sold your software.

Another benefit of the oss business model, if the project builds up some momentum it will have a chance to grow a lot quicker, fix bugs quicker and have much better code which benefits all.

Unless you have a show stopping application it is very hard to make money in software using the closed source business model, if I can pick up a bit of work coding and be paid for it I'll be more than happy.

But, that isn't my main objective, what is though is getting some software up to a usable, solid state so user can get their work done easier and better, every thing else is just a bonus

I will if I can.

And I agree...

Where do I send you the arx file?... (I have your emails any of the two?) - will probably posted back here in the old thread (if I can find it) or some place here.

[Jeff_M]

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.

I do not wish to hijack this thread, so I'm just going to post a quick question here, and a follow up in the Land Lubber group. James, C3D can show profile information in plan, automatically, too.

[LE3]

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.

I do not wish to hijack this thread, so I'm just going to post a quick question here, and a follow up in the Land Lubber group. James, C3D can show profile information in plan, automatically, too.

You can find that feature/ability/option in MEP and depending on how it is the viewstyle and or the iso view it will display the objects - BTW.

I use that API, but it is not friendly at all - at least for me.