Grasshopper 1.0 Beta 4 available for download

Replies to This Discussion

Permalink Reply by Danny Boyes on February 14, 2014 at 2:30am

Can there be an either or?

e.g. if you use the Param name the it works otherwise an "x" is sufficient

Permalink Reply by David Rutten on February 14, 2014 at 8:52am

I'm still fuzzy on what exactly the problem is with the new approach. Is it that the tooltip claims 'x' instead of 'A'?

Using the parameter name means the expression stops working when switching to Full Names mode, I found this to be an unacceptable state of affairs.

--

David Rutten

david@mcneel.com

Permalink Reply by Danny Boyes on February 14, 2014 at 9:58am

I can understand the complexity of having Full names as Parameter Expressions.

I just think that the previous method had more elegance. I could scribble on the canvas the expression used in the input and it was obvious which one it related to without having to be more specific.

Permalink Reply by Luis Fraguada on February 15, 2014 at 10:42am

I guess I imagined one day where one would be able to reference all of the input variables in a particular component expression.  Instead of just making expressions with the input variable, would be great to also reference other inputs in the expression.  This was just a wish I never made, and thought (read: ASSumed) and generalizing the variable name to X goes away from this false assumption. 

Permalink Reply by David Rutten on February 15, 2014 at 12:27pm

That's true, but I'm planning to not just allow input parameters to reference other input parameters on the same component in an expression, but to allow any expression anywhere to reference another parameter. First off it means that some objects (parameters, sliders, dials) have to be somehow marked as 'globals'. Then one could access these globals using -say- curly brackets or colons or something. So your parameter expression could look like:

(x - 1) * {DivisionCount} - {Offset}

where DivisionCount and Offset can be sliders somewhere else.

It's a bit tricky as this would make it possible to create cyclical graphs in non-visual ways as well, and expressions copy-pasted into another document may suddenly stop working, but it seems like a great way to reduce the number of components, and --more importantly-- the number of wires.

--

David Rutten

david@mcneel.com

Permalink Reply by Rémy Maurcot on February 14, 2014 at 2:40am

David, a major problem for me, all my definitions of components with expressions.
I must fully review my pluggin my examples and definitions.

You can not imagine there a script that automatically changes the name of the variable x.

Permalink Reply by David Rutten on February 14, 2014 at 8:49am

Loading old files will automatically repair these expressions.

--

David Rutten

david@mcneel.com

Permalink Reply by Rémy Maurcot on February 14, 2014 at 8:50am

Thanks a lot

Permalink Reply by Vicente Soler on February 14, 2014 at 2:35pm

I can't find any change log for the latest 0.9.0070. Is there anything new or did someone just complain about the number? (like with the duplicate component)

Permalink Reply by David Rutten on February 14, 2014 at 3:18pm

I didn't officially release it. The main problem it fixes is that on Internet Explorer the installer will now download as an RHI file instead of a ZIP file. I've been meaning to get together some fixes for 0.9.0071 and publicly release that, but so far I've been sidetracked. I suppose it deserves an official release soon...

Here's the list of fixes:

• Added Galapagos Fitness Function display component to Params.Util panel (unfinished).
• Polycurves would not automatically convert to arcs and circles, this is fixed.
• Align Planes did not gracefully handle null data in the input data, this is fixed.
• The 'S' input for the remap component was erroneously marked 'Optional', this is fixed.
• The [Evaluate Length] component would have confusing warning messages, this is fixed.

--

David Rutten

david@mcneel.com

Permalink Reply by Vicente Soler on February 14, 2014 at 4:04pm

Thanks.

I'd like to request an optimization to at least the list item component. It's really slow compared to a scripted equivalent. Short term I don't know if its worth it to release a version with the index input as tree rather than item, and be able to force a data type (with a right click menu maybe) to avoid the cost of "boxing and unboxing".

Permalink Reply by David Rutten on February 15, 2014 at 3:01am

It takes a long time because it calls SolveInstance for every index (like you said). I suppose there are some ways around that (if I detect that the L input is a single list and the W input is either a single value or is a datatree with the same layout as i) then I can accelerate the process by consuming the i as an entire tree. It's a big hack but probably works. Also if L and i have the same number of branches in the datatree it can be optimized given a lot of typing.

However I don't understand your "boxing and unboxing" suggestion. List Item operates on IGH_Goo directly and never converts the incoming values, they remain the same data. I don't see how there is a performance lag due to this, but I may confused.

--

David Rutten

david@mcneel.com

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page