Welcome to the Grasshopper to Revit Forum

Welcome to the Grasshopper to Revit Forum.

Please post any questions or examples you have here.

Replies to This Discussion

Permalink Reply by Nathan Miller on May 12, 2012 at 12:41am

Great initiative, Scott!

There seems to be a recent increase in activity in this area with investigations popping up in the GH and Revit communities. Good to see a Grasshopper group here taking the lead on this...

In particular, Revit API add-ins seem to be growing in popularity for the 'targeted' rebuilding of geometry using Grasshopper-created data. More often than not, these tools use some kind of 'middle-man' file in the form of csv, text file, Excel, database system, or other. The Geometry Gym's IFC tools focus on importing/exporting through an industry standard which also shows much promise.

In all cases, it's cool to see the community come around these new workflows... Things are really progressing past of the usual method of  bringing 'dead' Rhino geometry into Revit as a background reference.

More to come...

-Nathan

Permalink Reply by Scott Davidson on May 14, 2012 at 12:56pm

I agree with you that creating native Revit geomtry and objects is important.

We are seeing the development of two methods. The industry standard format for exchange is one. The other is an unresolved middle man format with a plugins on both sides to manage the exchange and workflow. Both of these approaches have their advantages and disadvantages.

I believe a discussion of this middle man format might be useful. TXT, XML? What data needs to be transfered.....

Perhaps we will see a hybrid approach? It is not clear.

Permalink Reply by Jon Mirtschin on May 15, 2012 at 5:23am

I also think a strong discussion of the "exchange" data is a good idea.

Of course I am a strong advocate of the IFC format (having invested significant time into developing access within Rhino/Grasshopper). It is a comprehensive, neutral and open BIM exchange specification. It's been developed by some very clever people with input from all sorts of industry experts. I welcome discussion of perceived inadequacies and disadvantages. I've enabled means now to exchange pretty sophisticated models from GH to Revit and so far the limitations have primarily been in Revit capability rather than IFC.

Also one of the reasons for IFC not reaching it's full potential is many others deciding they can do a "better job". Surely it's better to devote efforts to improving any flaws or deficiencies in a standard than trying to compete with it? Else surely it's better to research a way for Revit to control Rhino/Grasshopper (or vice versa) using the APIs directly.

My 2 cents.

Cheers,

Jon

Permalink Reply by Hiroshi Jacobs on May 15, 2012 at 6:17pm

I'm a believer that a middle man format is not absolutely necessary. The API's can speak directly to each other through binary data, which is what Chameleon is doing. That isn't to say that middle-man formats like XML, IFC, or TXT aren't valuable in many cases.

As far as what data needs to be transferred, I believe that we can create tools that specifically address this as the problems are encountered. The important thing is that the data can be transferred. Once we run up against a problem where we need to transfer a specific kind of data hopefully the API's are robust enough to be able to do it.

Permalink Reply by Scott Davidson on May 16, 2012 at 12:30pm

Are you passing values between the plug-ins using temp binary files? Named pipes? Do you have a simple example?

Permalink Reply by Hiroshi Jacobs on May 16, 2012 at 3:58pm

Yes, using named pipes. Here's some code for the sending side. There would be corresponding receiving code on the receiver side.

using

(NamedPipeServerStream pipeServer =

new NamedPipeServerStream("gh2Revit", PipeDirection.Out))

{

// Wait for a client to connect

pipeServer.WaitForConnection();

try

{

BinaryFormatter f0 = new BinaryFormatter();

f0.Serialize(pipeServer, mPointsRevit);

BinaryFormatter f1 = new BinaryFormatter();

f1.Serialize(pipeServer, mParams);

}

catch (IOException e)

{

Console.WriteLine("ERROR: {0}", e.Message);

}

Permalink Reply by Scott Davidson on June 7, 2012 at 2:06pm

Dale Fugier created a sample project on Github to show how he would setup Microsoft WCF (Windows Communication Foundation) from Rhino to Revit using RhinoCommon:

https://github.com/dalefugier/Sockeye

Currently the two products simply ping each other.

Withing this simple program we should be able to implement a data contract between the two applications so that they can share class members when exchanging data.

We hope the code is helpful.

Permalink Reply by Hiroshi Jacobs on May 16, 2012 at 4:05pm

Receiving code:

using (NamedPipeClientStream pipeClient =
new NamedPipeClientStream(".", "gh2Revit", PipeDirection.In))
{

// Connect to the pipe or wait until the pipe is available.
pipeClient.Connect();

BinaryFormatter f0 = new BinaryFormatter();
List<List<double[]>> pointsPipe = (List<List<double[]>>)f0.Deserialize(pipeClient);
BinaryFormatter f1 = new BinaryFormatter();
List<List<double>> paramValuesPipe = (List<List<double>>)f1.Deserialize(pipeClient);
BinaryFormatter f2 = new BinaryFormatter();
}

Permalink Reply by Nathan Miller on May 21, 2012 at 1:21am

Hey, nice one, Hiroshi! Something new :)

-Nathan

Permalink Reply by Luis Fraguada on May 12, 2012 at 2:28am

Thanks for starting a group, my original discussion got buried in the forum! While I am not a big user of this interop, I certainly see it as an important one to cover. In that respect, I would propose it to be called

GH >> Revit

As it should be a bidirectional development...

Permalink Reply by Luis Fraguada on May 15, 2012 at 2:26am

oops, I meant GH>>Revit! It does not let me write it!