Partial Developer Absence

Replies to This Discussion

Permalink Reply by Christian Schmidts on October 13, 2013 at 6:03am

I also saw Robert Aishs presentation about Design Script recently. Its for sure a interesting approach but it also looked quite "work in progress" to me and I'm not sure if it would be easy to implement on something that is already so complex like gh. But editable components is something that would definitively be interesting for long term development even with all the difficulties that it brings.

I want to also give thumbs up for Mateusz idea with the free viewer that it capable to read gh files and and provide the user with a kind of remote control for them. I think something as easy an area would be cool where you can drag and drop gh files onto and it shows you the remote control next to the geometry. There could be an option to the sliders, panels, booleans if they should be shown and in which order which is on default turned on.

Last I wanted to ask if the plan still exists to extend clusters in a way that data can run between different documents and also make a kind of loop possible without scripting in gh?

Permalink Reply by Silvan on October 14, 2013 at 5:41am

Hi David

What about an additional Python component that just loads a python textfile from the filesystem. In addition to that it checks if the file has been changed. If the file changed, the Python component reloads the Python file and recomputes the GH tree.

This would allow to use any external text editor and at the same time gives debug notes from the GH Python component.

I proposed a similar thing for the Python scripting in Rhino here. Steve wanted to consider it for V6.

Cheers,

Silvan

Permalink Reply by Daniel Davis on October 14, 2013 at 6:41am

Hi David,

Adding my vote for better C#/Python/VB IDE's -- interactive debugging would be particularly useful.

In addition:

• Colour coding the wires. Eg. Blue wires carry points, red wires carry curves, green surfaces, etc. In Grasshopper 1.0 it can be unclear to beginners that the wires carry different data types. I think if there was a visual reference then it would be much easier for them ('I need to link this blue wire into a blue input'). It could look ugly but I am sure in your hands it would be beautiful. 
• Lists: I have no idea what could be done to improve lists, but I think it is worth mentioning that in my experience lists are normally the acid test for people learning Grasshopper. They either get them and fall in love, or they find it too hard and give up.
• Structure: Grasshopper models have a tendency to quickly become complex. There is pretty good evidence that complexity becomes the limiting factor in model size, which in turn impacts the level of detail possible in a model. This is partly down to the users, but there are probably some things Grasshopper could do to help them. For instance: right clicking a wire might let you split the wire with a node in order to name it (the same as adding a point node in the middle of a wire currently); grouping nodes might organise all the inputs and outputs for the group automatically; clusters could be rethought to give better juxtaposability and visibility (see Green and Petre's research on visual programming). 
• Calculation feedback: At the moment it is hard to workout if Grasshopper has frozen or if it is solving a really difficult problem. It would be helpful to have a little bit of feedback about how far through the calculation Grasshopper is. Perhaps Grasshopper could say how many nodes had been calculated and how many remain. 

Permalink Reply by David Rutten on October 14, 2013 at 10:03am

Colour coding the wires.

There's lots of data types and adding a colour for each one seems like a bad idea. However tooltips for wires or even small icons when zoomed in could also be used. One problem however is that wires might connect two parameters of different type. It might be points on one end and planes on the other. What 'colour' should this wire have? Gradient?

Calculation feedback.

It's on the list already, but there's a big difference between progress feedback and keeping an interface alive. In most cases, the bulk of the time is spend on a single component which is performing a huge amount of complicated operations. If this component takes 2 minutes to solve, then having a message that says "solving component 16 of 39" for two minutes isn't helping either.

--

David Rutten

david@mcneel.com

Seattle, WA

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

Colour coding in wires could be an option, like displaying wires as normal, faint or hidden mode, also colours could be set

Permalink Reply by huaxiamengqing on October 27, 2013 at 11:38pm

Hi,david, about "Calculation feedback" I think you must make a Stop shortkeys or button to stop some seem endless calculation.We really don't want kill rhino process when come into this situation.

Permalink Reply by David Rutten on October 28, 2013 at 10:07am

Escape doesn't work? What sort of long process is this? Is it a lot of small calculations or a few very big ones?

--

David Rutten

david@mcneel.com

Seattle, WA

Permalink Reply by huaxiamengqing on October 28, 2013 at 6:15pm

Of course. Haven't you come into this? I can't imagine. It's a nightmare to us who handle the big model.For example,In one project, we need handle more than hundred thousand circle.we need group them,or find some of them in a assigned area ,some operates like this. gh always died in endless calculation and Escaspe is of course usless in much time! If we didn't save the gh file or rhino file,it's a disaster! the gh auto save function is worse --So please add an more powerful stop to the endless calculation! I will be appreciate it  with all my colleagues!

Permalink Reply by David Rutten on October 28, 2013 at 8:34pm

That's interesting because Escape is exactly supposed to be able to abort these kinds of operations. I know it doesn't work as quickly as it should, but it tends to terminate processes on my machine within a few seconds.

Escape will not be able to abort a single operation, but testing 100,000 circles for region inclusion is 100,000 individual operations (or are you doing all this in a single VB/C# method?)

--

David Rutten

david@mcneel.com

Seattle, WA

Permalink Reply by huaxiamengqing on October 28, 2013 at 10:52pm

Esc dosn't work in many situation. if I create a wrong tree that each banch has 100,000 * 100,000  cirlce, I connect  the tree to the sort commpont,this situation , esc  key really dosn't work. and as you say ,If I Calculation much things in a single commpont, it not work. See the attached file below! give the  slider a number bigger than 10, and I don't think you can esc with a few seconds--

Attachments:

• ESC.gh, 7 KB

Permalink Reply by David Rutten on October 30, 2013 at 6:53pm

Right, but that is a single operation that occurs entirely within a VB component. Like I said, Escape currently only works between operations.

I'd have to run the solution on a different thread in order to keep the UI alive and responsive all the time and not only are a lot of operations not threadsafe, a lot of them don't take kindly to being aborted in the middle either.

This is something that we'll try and improve upon for GH2 for sure.

--

David Rutten

david@mcneel.com

Seattle, WA

Permalink Reply by huaxiamengqing on October 30, 2013 at 6:02pm

Have you test it?

• ‹ Previous
• 1
• …
• 4
• 5
• 6
• 7
• 8
• …
• 12
• Next ›
• Page