most advanced thing I have touched so fare concerning Grasshopper on the web. Especially the update logic is nice, so it doesn’ reload the complete model but only the changes.

I am currently working with a designer for whom I develop GH defintions. Currently we are doing all the talking via skype and sharing screens when we talk about the project. It is rather simple, only some itterative shape finding (using Galapagos) with center of mass manipulation and an upfront aproximation of the resulting shape mass (using math.net dll)… .

Based on this project and after a very short visit some remarks (ordering withou importance):

1.) Plugins / dll / scripts
I know in the introduction it says that this is something that isn’t included but it would be nice to have. Not only plugins but dll’s as well. e.g Rhino provides some math but is bad when you want matrix/vector computation with more than 4/3 dimensions…

2.) predefined views

3.) predefined visibility controll throug e.g. naming of objects in gh definition

4.) The possiblity of multible users working on the same modell

5.) Not having to internalise all data but being able to load/save form/to different rhino files.

6.) Saving slider settings

7.) privacy controlls who can see the model.

8.) maybe a lock/recompute like in grasshopper for realy heavy modells …

9.) Titles in the Forum with less than 15 characters




Hi Richard,

I guess your message has escaped our attention, sorry for the response delay…
Thank you for your kind comments, your feedback is really appreciated!
I’ll try to address all your remarks as precisely as I can (I already forwarded the title problem 9) to our webmaster).

First of all, a few of the features you mention are already in our plans and should be implemented soon, 6) and 7) for instance. We will keep you updated about them.

Some other things will be easily added, say soon-ish, as they are not too much work, but we might have a forum discussion with the users about them regarding details. This is the case for 2), 3) and 8) for instance. In those cases, the question is whether most of the control should be confined to the grasshopper definition only (with eventual help from additional ShapeDiver components), or if the viewer should be able to define views, visibility or lock/recompute abilities regardless of the definition. We will start discussions in the forum, as users’ experience is key regarding these functionalities.

Many users already asked about plugins/dlls. This is more of a mid-term priority at the moment. Obviously, we have to test all plugins and dlls with our system before installing them on the Grasshopper servers. We have some work to do before iterative and/or recursive plugins like Galapagos or Anemone can be included, but overall we plan to enable some widely used plugins, as it is relevant for them to be included directly on the platform. Several of these are already being considered, and we welcome suggestions (math.net dll noted). For more confidential ones, it is likely that a future version of shapediver features professional accounts with dedicated servers allowing more customization (which will go far beyond custom plugins and dlls).

About internalising all data (item 5)), we would also have to start a discussion. Could you expand a little bit on what you mean? We will soon add the possibility to download CAD files for the models displayed in the viewer (3dm, dxf…), but I think you have a more general vision and it sounds very interesting.

Now for the last and most challenging piece: we have thought very early about sharing a session between several users (item 4)). I can say that it will be possible in the mid to long-term, but I can’t say when yet. This is a very exciting possibility and it would be a shame if ShapeDiver didn’t offer it. This is where we have a chance to take parametric modelling one step further. Once again, we will soon start a big discussion about this topic, and the way users would like this feature to work. Should only one user at a time be an “emitter” and the others “receivers”? In this case, should we lock the stream to the emitter’s view, or only broadcast the parameter changes? How should people collaborating on a model switch emitting control between each other?
This general topic goes hand in hand with a symmetrical feature we have thought about: the possibility of having co-dependent models that influence each other, or even meta-parameters sharing their influence to several models.

Here you have it, ShapeDiver’s future from the next, concrete steps to mid- and long-term dreams. This should give you an idea of where we stand and what our goals are.

We hope these possibilites can spark discussions, ideas and excitement for the future.




Hallo Mathieu,

what exactly I have in mind with point 5)…

There is a general problem with grasshopper, you can’t realy limit access to your algorithm you produce in Grasshopper unless you generate a plugin with a liciencing model. This again makes no sense for project work. So in the use case explained at the beginning, it would be create to actually not provide the client with the script but only with an access to the server. This can 1) gurantee that he doesn’t mess arround with things he shouldn’t change. and 2) the Grasshopper definition would not be exposed to the client but he still can use it.
In the given case the Grasshopper definition can operate on different modells, manipulating the center of mass, as long as they have the same layer structure (using gemoetry pipline to import the information form a rhino file). For the client to use the script the scenario would be:

a) upload a 3d modell (3dm) to the server
b) run the script online
c) download results as 3dm or maybe even send it to a server for automated ordering / production (webshop integration)

This way client can use it with a nice interface, I don’t have to worry on my code getting reused for what so ever by the client (as he is not paying for software development but only for consoltency).

getting to point 4)

Yes it is a tricky one. I have been developing a similar thing for VR walkthroughs and that was already tricky as you also have to take computation time of the grasshopper into account…

However I guess it will need some testing, what I could imaging is to not automaticly update the interaction by different people working on the same model but have a list of model states connected to a user with a timestamp so people could jump back and forward between different solutions while talking to each other via the phone. It would be nice to also including sorting these model states according to timestamp / to user / maybe clustering solutions based on some kind of similarity input (simple euclidian distance between the different slider settings) inputclutering/ sorting according to a value / a set of values (output-clustering) …

Or even displaying these modelstats in some kind of data grafik display through e.g. spectral graph drawing to show the similarities of different model states. (If you are planning to use spectral graph drawing … please contact me I am doing my PHD on this in connection with architecture and solution generation and would love to use it on some more examples).

Just spinning a view ideas but I am getting realy, realy exited here.



I just want to join the wish list and emphasize that

would be really fantastic. We are looking for possibilities to implement a kind of citizen design platform, where citizens may provide own design proposals for a specific area. Therefore a customization ShapeDiver would be ideal. Or at least the option to upload custom dlls that may change regularly during the development of such a platform.
Best regards


Hi Richard,

this is Mathias from ShapeDiver. First of all thanks for your very detailed feedback!
Just to make sure I am understanding your idea, when you say

you mean that there would already be a GH definition and dependencies such as dll’s on the ShapeDiver server (or a dedicated, customized copy of it which you license) and users could then upload 3dm files which would be processed by this definition to create the output that users see in the viewer. Correct?

I can see how this could be a very attractive way of creating GH-based web CAD applications, it’s a really exciting idea! I haven’t thought this through properly, but I think this is an extension which could fit quite naturally to our current setup.

At the moment we’re obviously quite busy preparing our current functionality to go public in a few weeks, but I’ll definitely get back to you about this.

On some of your other initial points (2,3,6,8) I’m quite confident that we’ll be able to get them done rather soon, we’ll keep you posted.


Hi Reinhard,

we are definitely planning to offer customized solutions based on the ShapeDiver technology to enable projects and applications like the one you describe. In fact, this is a main part of our vision for this tool and it’s great to see that there’s already ideas coming up while we’re still in closed beta mode!
Once we’ll have the core technology stable enough to go public (hopefully in a few weeks) we would be excited to get in touch and discuss if and how ShapeDiver could help in your endeavor.
Same goes obviously for @schaf82 as well!


I can certainly second Richard’s idea - It would not be an easy set of features to add, but it would add an incredible amount of value to the application.