Partial Developer Absence

Replies to This Discussion

Permalink Reply by Benjamin Felbrich on October 11, 2013 at 7:14am

I don't know if you ment this with "constraint engine implementation", but what do you think about implementing the Galapagos approach into single components (maybe as an option)... To make it possible to easily optimize solutions in any script iteratively with many variables without interrupting its work
or maybe a "Solver"-component that can be integrated like any other component while the script is running

Permalink Reply by David Rutten on October 11, 2013 at 8:19am

We've been fiddling with constraint engines for a few years and came very close at some point including Jonathan Westhues' SolveSpace engine as an SDK namespace. I would like RMA to reconsider adding a constraint engine to the SDK so that plugin developers (not just me) can solve constraint based diagrams.

The galapagos wish would be a small-time feature, that's nothing that needs to be discussed with the entire company.

--

David Rutten

david@mcneel.com

Tirol, Austria

Permalink Reply by michael sprinzl on November 10, 2013 at 10:13am

So the constained solver will be not as a sketcher in  Rhino in first place? Or will the Solver be a partial thing in Grasshopper. Will where be a kind of extra layer of interactivity between Grasshopper and Rhino3d for this with a kind of Custom Component storing the History and Grasshopper definition.... This would result in a big party at the workpreparation department. Maybe it would be also possible to get technical 2d drawings automated from this constraining.

Permalink Reply by Mateusz Zwierzycki on October 11, 2013 at 7:42am

Well, if you plan to make some major changes :

• Canvas sharing over network -> Ability to work in real-time on one definition with multiple users (think MMORPG)

• The display problem -> This is the problem with Rhino display which is the bottleneck for some iterative definitions (I already wrote about that, but it will be more convinient for you to have it here)

• Convinient coding -> Ability to run the debug while writing components in Visual Studio/other IDEs

• Multi-threading -> Please, if that gonna happen, give us the ability to set how many cores are running the grasshopper. For instance - rendering in 3ds max with mental ray consumes all the cpu (therefor user can't even run a calculator or notepad), while using vray is much more pleasuring (you can specify the task priority and use your pc in a normal way).

• Localization -> Please don't localize the error messages. It's the worst idea ever.

• Grasshopper web browser app -> I know that this would be a huge effort, but it would be awesome to be able to build grasshopper def just like we can do that with processing.

That's all for now, can't think about anything else at the moment.

Permalink Reply by David Rutten on October 11, 2013 at 8:29am

Canvas Sharing. Interesting project. It's come up before a few times. I'll definitely add it to the list of discussions.

Debugging. That should be possible already, provided you're using Visual Studio. Being able to debug VB/C#/Python component code is already part of the list. In my opinion the VB/C# editor is one of the weakest parts of GH1.

Localized error messages. Don't worry, not gonna happen. 

Grasshopper web browser app. Like, have an actual functioning GH file run in a browser? Or exporting a GH file as a webpage with a bunch of pre-rendered images representing different slider layouts?

--

David Rutten

david@mcneel.com

Tirol, Austria

Permalink Reply by Igor on October 11, 2013 at 7:32pm

"Grasshopper web browser app."

Very good thought. It is desirable as a full-function file with possibility of influence of the end user of web page on control elements (sliders, switches, a colour choice) and possibility of preservation the result either in the form of model or in the form of a code with possibility of the further transferring to environment of Rhino or GH. Visualisation by means of OpenGL. It would add more interactivities and much more would increase popularity GH and Rhino.

Permalink Reply by David Rutten on October 12, 2013 at 2:09am

Well, that will not happen. Grasshopper requires Rhino to be up and running in order to perform its calculations and there's no way you're going to be able to run Rhino inside a webpage. Apart from the technical considerations (which are substantial) there's the licensing issue.

--

David Rutten

david@mcneel.com

Tirol, Austria

Permalink Reply by Mateusz Zwierzycki on October 12, 2013 at 5:15am

Grasshopper web browser app -> I know that this would be a huge effort, but it would be awesome to be able to build grasshopper def just like we can do that with processing.

I had probably the same idea on my mind as Igor. 

Also, another idea-> Can you provide some more help about how to modify the definition with code ? I mean adding/removing components, obtaining informations about connections, creating new connections. I found that the easiest way to add slider is to just paste the xml. I also tried to add a slider with the code, but all I got is some odd control in the 0,0 point of the canvas (probably a default control, with no graphics painted). Can we have some simple namespace like Grasshopper.ModifyCanvas with all that functionality ? (don't have a better name right now).

EDIT

...and another one is to have multiple grasshoppers running.

Permalink Reply by Mateusz Zwierzycki on October 12, 2013 at 5:41am

But maybe... well, I'm just thinking about finding some option to share the gh definition with the customer without teaching him how to use Rhino and Grasshopper (install rhino, install grasshopper, run rhino, type grasshopper, open definition in grasshopper, find the slider called "x" and please don't change anything else).

So the only reasonable(?) idea for me (as obviously we can't run rhino in the browser) is to make a freeware Rhinoviewer with an integrated Grasshopper. What the customer has to do is to download and install it, then she/he only has to double click the .gh file*. What happens next - Rhinoviewer opens up (this is just a window with one viewport and open/save buttons, no controls, no tooltabs, no direct editing (in rhino I can specify which viewport I want customer to see). Then grasshopper working in a background displays predefined (by me) remote panel and uses the rhinoviewer to display geometry.

* I almost forgot - double click .gh file runs rhino and opens up grasshopper with the .gh file definition... that's the next idea which was appearing on the forum few times.

Permalink Reply by Mostapha Sadeghipour Roudsari on October 14, 2013 at 8:40am

Freeware RhinoViewer similar to this one (http://www.rhino3d.com/ios) with an integrated Grasshopper sounds like a great idea to me.

Permalink Reply by Miguel Villegas on October 15, 2013 at 9:05am

This feature would be awesome.
I'm starting to do some professional consulting for fellow architects and they don't want and shouldn't need how to tweak the controls in a GH definition.
Having a standalone viewer in which we could set the controls we (as computational designers) want available for the "end user" would be a great tool when working as freelance consultant.

Permalink Reply by David Rutten on October 12, 2013 at 11:55am

Hi Mateusz,

I can certainly add some easy to use top-level functions to the SDK. We may even do this for GH1 as the current RhinoScript interface for GH is pretty lame.

It should not be particularly difficult to add a new slider to a document, you can call GH_Canvas.InstantiateNewComponent(id, pt)

So all you need to know is the ID of a slider object. 

--

David Rutten

david@mcneel.com

München, Germany

• ‹ Previous
• 1
• 2
• 3
• 4
• …
• 12
• Next ›
• Page