Grasshopper 1.0 Beta 4 available for download

A minor upgrade is available that fixes a few serious bugs. The internal version of this release is 0.9.0069 and it can be downloaded from the usual location.

Fixed bugs:

Cull Duplicates would fail if the first two points in the list were coincident within tolerance, this is fixed.
Enabling Cluster Content Preview would not take affect until after the next solution, this is fixed.
Adjust Seam component would result in awkward curve domains, this is fixed.
Local parameter expression replacement was case-sensitive, this is fixed.

David Rutten

david@mcneel.com

Replies to This Discussion

Permalink Reply by David Rutten on February 15, 2014 at 4:16am

I got it down to this for single list L inputs. But the code is horribly complex so it needs a lot of testing. I also think the output may be slightly different* now if there's more than one output parameter and the index oversteps the list boundaries.

* better different, nulls are maintained

David Rutten

david@mcneel.com

Permalink Reply by Vicente Soler on February 15, 2014 at 5:10am

Thanks, I thought using the parent class instead of the actual class would have a performance cost (I got the "boxing" terms from the system.object documentation) but I guess if there is any, is probably unnoticeable compared to the rest.

Another performance issue (the reason my scripted component now takes longer than the new list index component) is that it takes really long for scripting components to convert to and from GH_* data types. To solve the output problem is easy (just output directly a GH_* data type). To solve the input lag I've had to do things like converting a list of points to a mesh with no faces and input that (I could've probably also used a group).

Permalink Reply by David Rutten on February 15, 2014 at 5:20am

Boxing happens when a value type is assigned to an Object variable. IGH_Goo data are all reference types, not value types.

David Rutten

david@mcneel.com

Permalink Reply by Vicente Soler on February 15, 2014 at 6:27am

Would've assumed things like numbers and points are value types. I don't know much about GH_Goo derived data since 90% of what I've coded on GH is inside scripting components.

What about adding a GH_Goo type hint in the scripting component to solve the delay problem?

Permalink Reply by David Rutten on February 15, 2014 at 6:52am

All goo need to be able to assume a null value which is why they are all reference types. Classes like GH_Number and GH_Integer wrap System.Double and System.Int32 (which are value types) but the goo itself is a class.

The reason why goo isn't directly available to scripting components is because goo instances are potentially shared amongst many components and I just don't trust VB/C# script component programmers to know how to handle it properly so they won't screw up data that doesn't belong to them. I don't mean to be rude about it but given that a lot people writing code inside those components often don't know the difference between an interface and a class, don't know what a constructor is for, don't know the difference between array accessors and a function call, I'd rather not give them easy access to vulnerable data.

I'd add some sort of secret hint or something but unfortunately the data is already stored inside the input parameter as a safe instance and changing that would mean ripping apart of a lot of code. This is done ahead of time to reduce the number of times that vulnerable IGH_Goo data needs to convert itself into safe types. For things like integers and doubles it wouldn't matter much, but Breps and Meshes are always duplicated and that can take a lot of time. You don't want that to happen on every call to RunScript(). If only .NET had something akin to the const keyword this could be solved easily, but unfortunately MS didn't see fit to include that.

I think for GH2 I can probably come up with a solution to this, but until then you're stuck with low performance.

David Rutten

david@mcneel.com

Permalink Reply by Vicente Soler on February 15, 2014 at 7:36am

Ah, those scripting component noobs. *snicker*

Permalink Reply by David Rutten on February 15, 2014 at 5:29am

Got it down a bit more by caching wrapping values so they can be looked up quicker. I'm now handling tree special cases:

One list of items (L) but many lists of indices (i).
Many lists of items (L) but only one list of indices(i).
Equal numbers of lists of items and indices.

Which I think probably covers 99% of usage. However for the optimizations to kick in the wrap input has to be either 1 value, or a single list of values, or equally many lists of values as the i input.

I can't just upload the maths.gha file for you to test as this optimization required a change in grasshopper.dll (I needed a way to inform the component base class to stop to try and solve it for every item in (i) whenever I treat the (i) input as a datatree. I can send you an official installer later though (after lots and lots of internal testing) so you can see if it works for you.

David Rutten

david@mcneel.com

Permalink Reply by Vicente Soler on February 15, 2014 at 5:44am

OK. I don't need it asap (I can use the scripted component for now) but I can test it if you like.