Grasshopper

algorithmic modeling for Rhino

Hi David,

Will GH be able to talk to the new LEDAS' plugin?

I think the plan is that there will be Rhino elements / subelements that will be driven by 'driving dimensions'. It would be good if GH can interact intelligently with these elements.

LEDAS is also providing constraint solving. It would be great if GH can react to or even incorporate the constrained geometry sets as part of the definition.

Views: 1901

Replies to This Discussion

I requested we (mcneel) purchase a basic constraint solver and incorporate it into the SDK. Even if we do not use it directly in Rhino it would still be useful to many plugin developers. As always, anybody who is selling constraint solvers has either outrageous or very expensive licensing.

Ledas is more than welcome to develop their own component(s) for grasshopper, but I have no plans to do this myself.

--
David Rutten
david@mcneel.com
Poprad, Slovakia
What about making associative links to Rhino elements driven by LEDAS or in their assemblies? I suppose this would depend on LEDAS exposing their data / API.

The constraints solving, history tree working that LEDAS could provide a beefed up version of Rhino's implicit history that would equal or better Solidthinking / Think3. Are LEDAS using implicit history to string their dependencies together ?

Throwing GH into the mix would give Rhino users even more flexibility.
David,

Have you looked into this?

SolveSpace
Yes, actually that's where I started. Someone pointed me towards SolveSpace and I began thinking about how cool it would be to have this functionality inside Grasshopper. Unfortunately Jonathan and Bob were unable to come to a mutually satisfactory license agreement. I believe Jonathan even went to the Seattle office once.

Steve Baer (our DotNET SDK wizard) even got pretty far with making a wrapper sdk for SolveSpace so I could use it from DotNET, but then the whole licensing thing went south and the last I heard was that Dale would try and write a solver himself. This was months ago.

--
David Rutten
david@mcneel.com
Poprad, Slovakia
What a Bummer!
Solvespace looks amazing...
I really hoped that it made it into Rhino in some way.

Holger
I think it is really amazing too, and far more useful than LEDAS's reverse kinematics in my opinion.
In days where AutoCad and even some of it's clones have sketch constraints, I think it's really time for Rhino to catch up.
That was the step they should have taken BEFORE History because
it is far more useful / fundamental as a design helper in my opinion.

Olivier
I hope there is a way to keep pressing this issue. Constraint solvers would be an incredible addition to GH.

This brings up a general question that I wonder about often. What are the things on the horizon for GH. Where is the effort focused for the future development of the product. I am a great fan of GH and have a great thirst to hear about what might be in the works or what we can hope for in GH. Would love to hear some of the visioning discussions taking place.

Stan Carroll, AIA
That's a shame.

I'm sure you guys could cook up something internally that would be better anyway.

Good on Bob for standing his ground on whatever it was that made it fall through though.
Ryan
I'm not so sure. First of all I'm wondering if we'll get around to it at all. We also don't have any experience with this, whereas Jonathan does.

Who knows, maybe things will change and maybe we can come to a mutually satisfactory agreement in a while.

Here are some of the problems we always face when trying to incorporate some 3rd party library into Rhino:

1) Must be available as both 32 and 64 bit dlls. The only reason why it took us so long to finally come up with a 64 bit Rhino was because the library we use for image reading/saving wasn't available for 64 bit systems.

2) Must run on both Windows and MacOS. Or, failing that, we must get access to the full source code so we can compile for both platforms.

3) The running cost of the license plus the investments on our end to integrate the library must be less than the additional income we can expect from this. Now, this is a very spongy topic, as no one really knows what the additional income might be, but often enough it's clear that the initial costs are just too high.

4) Once we put something into the SDK we cannot remove it without breaking all plugins. Thus, any update to the library must also be non-breaking before we can fold it into the SDK. Can we trust someone we don't know to make sure they won't break our SDK?

5) The license agreement must stipulate that RMA is allowed to use a library forever, without massive running cost changes. We had a very bad experience with a certain library that was bought by another company who subsequently refused to renew our license. Suddenly we had to drop everything we were doing for months at a time and write our own code that did the same thing, because we weren't allowed to sell any Rhino's that still used that library.


Incorporating 3rd party code into your project might sound like a quick and easy way to gain a lot of functionality, but it is a very thorny path indeed.

--
David Rutten
david@mcneel.com
Poprad, Slovakia
I knew a lot went into licensing 3rd party code into a program was usually tough and extensive but that just sounds like hell for a developer with the "mantra" that you guys have.

A while back when I brought up the program in the newsgroup on how someone could take the GPL'ed 2dSolver, make a function that opens up up a window that you could make a sketch in with constraints and then press a button to import it into Rhino. I ended up making a button that runs 2dSolver, it opens up, I can make a 2d sketch in it, save it to a default directory. Close out of it and then right click the button to import the dxf file.

It has always been a request of mine to have some sort of constraint/dimension driven ability in Rhino but sounds like it might be best to leave it to a plugin developer to take the risk. On the other hand I would gladly pay extra for the ability natively. What kind of price increase are you talking about $500? I'm sure people wouldn't snub their nose at that as right Rhino off their list of software to purchase.

On the bright side, we have you working on Grasshopper which has made a lot of things easier, controllable, and repeatable.

Thanks,
Ryan
The way Rhino is currently priced means that a lot of employees have a relatively easy time purchasing a copy. As soon as we overstep the 1000 (dollar/euro) boundary, suddenly a lot of managers get involved since it has just shown up on the corporate 'radar'.

Realistically we cannot raise the price of default Rhino without losing an awful lot of business. So the income has to come from new copies we otherwise wouldn't have sold, or it needs to come from selling some sort of McNeel plugin to existing users (a la Flamingo, Bongo, Penguin).

I'm not trying to sound all bitchy about it, but the fact of the matter is that this is a really complicated situation. A situation which we have screwed up in the past to the detriment of both ourselves and our customers. Perhaps we are too cautious because of this.

At any rate, I'll keep pressing for this to happen because I see the potential big benefits of a native constraint solver, but the only person who can decide on this subject is Bob.

--
David Rutten
david@mcneel.com
Poprad, Slovakia
You don't sound bitchy at all, it's the nature of the beast. (no pun intended) I'm glad that there is internal interest in a constraint solver. But your statement about Rhino going over the $1000 dollar mark and then getting targeted by management is true. (sheesh another pun is in that one too) Even when I worked at a place that had licenses of ACAD and Solidworks, everyone had Rhino because of it's "Swiss Knife" abilities.

It'll come one day I'm sure, I just hope it is atleast a plugin built "in house" and not a 3rd party. I want to pay the bill's for you guys not someone else.

Ryan

RSS

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service