Export to Digital Project, CATIA, Tekla and other BIM

Replies to This Discussion

Permalink Reply by Philipp on July 3, 2010 at 3:47pm

wow. It will be great to have a link with revit!

• ▶ Reply

Permalink Reply by Saimon Conti on July 4, 2010 at 2:26am

thank you very much.....i will try soon to link it with CATIA/DP

• ▶ Reply

Permalink Reply by Andrea Graziano on July 4, 2010 at 3:42am

Thx a lot Jon!

• ▶ Reply

Permalink Reply by Jon Mirtschin on July 4, 2010 at 11:04pm

Hi Phillip, Saimon and Andrea,

I'll happily help you to get started.

A direct link to REVIT is on the agenda, but hopefully IFC works sufficiently in the short term.

Cheers,

Jon

• ▶ Reply

Permalink Reply by Marc Syp on July 5, 2010 at 11:03am

Jon -

I am a designer at NBBJ and we are very interested in forging a direct link between Grasshopper and Revit, since we use Revit exclusively in our office for drawing set production. I am interested in the possibility of driving parameter data and therefore the deployment of families in Revit, in addition to the generation of Conceptual Mass objects. I would be curious to hear what your timeline and goals for development might be, as we would definitely be interested in using any plug-in you might develop for new projects in the office. Feel free to add me as a Friend and send private mail if you like. Meanwhile we will be exploring our options with our Autodesk reps. I will let you know of any progress we make that might be helpful to the development of your plug-in.

Cheers,
Marc

• ▶ Reply

Permalink Reply by Jon Mirtschin on July 5, 2010 at 11:51am

Hi Marc,

I'm already directly linking with Autodesk ROBOT (Structural Analysis), and generally that particular programming API has prooven to be reasonably straight forward and quick to produce a functioning exchange.

I'll send you a message, it's always possible to quickly produce a specific functioning plug-in, customized to the particular objects you wish to transfer. The time consuming process is ensuring rhe generic, comprehensive library is fully functional. So if you're interested, we (and anyone else interested) can make a start testing with some specific interaction within a week or two.

Cheers,

Jon

• ▶ Reply

Permalink Reply by Nathan Miller on July 8, 2010 at 11:49pm

Hello fellow NBBJ'er...

As Jon suggested...
transferring specific information to Revit through a custom API plug-in is possible...

see my wiki here for simple example: GH to Revit via CSV

My understanding is that 'Direct' links with Revit... (such as sending commands and data from an outside application....) are nearly impossible because the Revit API still requires user interaction to load and run a command manually from within Revit.

I have seen workarounds where you can use Win32 API functions to send keyboard shortcuts to Revit from about outside app... but I don't know how practical that really is.

hmm...

• ▶ Reply

Permalink Reply by Jon Mirtschin on July 9, 2010 at 1:53am

I haven't tried this, so take it as an assumption to be tested.

But my understanding of how this would likely work is that the commanding program would be a revit plug-in. This would in turn launch Rhino (with a COM or similar handle), then you would open your grasshopper model etc, and data could be extracted back out (or I guess also fed in as an input).

This would be fairly powerful means of operation. Initial means of exchange I'm assuming is IFC or a neutral BIM file format, but hopefully for the medium future such a link could be explored.

Has anyone else tried this?

• ▶ Reply

Permalink Reply by Nathan Miller on July 9, 2010 at 5:56pm

I haven't tested extracting information (points, parameters, etc) from an open Rhino/GH app from within Revit. This direction seems to make more sense.

Going the other direction: Sending information and commands from another application to Revit is a no go because of the lack of inter-process communication support within the Revit API.

• ▶ Reply

Permalink Reply by Steve Lewis on July 31, 2010 at 2:10am

When using parametric tools like catia be a little careful hen exporting. Importing a file does not necessarily mean you will get native objects in the application to which u are interaacting
Catia and dp use a tightly hierarchal parametric parent child relationship when defining their native objects. For instance, using IFC does not mean you will achieve interoperability with another package. The only way to ensure correct translation of data and creation of application specific native objects is by using a tools API. Unfoetunately autodesk continue to go down the route of forcing people to stay in theiir ecosystem once you are in, you re locked in. 
Robot is a good altenativw to access the API and send data bidirectionally to revit.

• ▶ Reply

Permalink Reply by Jon Mirtschin on July 31, 2010 at 3:12am

Well a large part of the intention of the work I'm doing is primarily for exporting from Grasshopper. I see Grasshopper as a generative tools, and whilst there are means and ways of importing and adjusting existing data, I see typical work flows when concepts and early phases of projects are generated in Grasshopper, and then I think it's poor to start modelling from scratch again when you start to produce other digital models for drawings, schedules, programmes etc.

I have heard from various discussions that other software programs IFC exchange can be "restrictive", but the only means of pressuring change is for users and potential customers to express if the capability is not enabled for their needs. From what I've been told, some of my users utilize digital project with two way traffic, but this has been with SDNF (for steel frame models). But if objects are tagged with GUIDs, I would expect that DP should be able to replace existing objects.

I agree, I've found so far the robot API capable for exchange of data.

• ▶ Reply

Permalink Reply by Steve Lewis on July 31, 2010 at 4:52am

Maybe but programs like Catia/DP rely on native descriptions for objects that describe interrelationships between one object and another. Most non structural analysis programs like Rhino/GC/GH do not rely on interdependency between objects. Objects are treated explicitely and do not rely on connectiivty. Even REVIT considers a beam object to be explicit in that it looks at a beam in isolation with respect to other objects. The beam object has embedded properties which define its spatial postion - just like a rhino curve is drawn independantly of other objects. A GUID does not help describe the hierachal relationships in CATIA/DP and other programs. Here objects are defined in a specification tree, the name of the object/feature describes its position in this tree, where it sits in the part, and sometimes, where the part sits in an assembley/building. For instance a building may be composed of thousands of parts, where each part may be an "office space" that sits in a product where several products form the complete building. Furthermore, the naming convention of the object, specification tree, part and document are often specified by the client to enable accurate tracking of the BIM object throughout the process of design and construction. A GUID simply wont cut it in such situations.

A parametric line feature in digital project/CATIA can be constructued in almost 15 different ways - much like how a line can be constructed in Rhino. A GUID simply cant describe this. I agree that an SDNF file is a great way to start, collaborate and co-ordanate steel work.

I dont mean to rain on anyones parade, but speaking from experience, when you see it taking five days to "translate" a file in to DP/Catia to get well co-ordianted native objects, even when the file is in an "interoerable format" like IFC/SDNF, I think its importnat to manage peoples expectations, and make the distinction that you will not necessarily get well co-ordinated native objects in your application from such "interoperable" file formats, unless you use a tools api to create native objects from such data.

Ok, rant over, having said that, Jon, you work is awesome!

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page