Grasshopper

algorithmic modeling for Rhino

Minor updates and bug fixes to 0.8.0002 available for download.

  ● Added proper tooltip formatting for Expression Variants.
  ● Added more icon feedback to preview modes.
  ○ Fixed flat Box to Brep conversions.
  ○ Fixed Nurbs Curve to GH_Curve conversions.
  ○ Fixed a bug with lingering previews on disabled objects.
  ○ Fixed yet another bug with Curve offsetting.
  ○ Layers in the undo stack would still show up in the Bake Dialog. This is now fixed.
  ○ Fixed a bug in Sweep2.

--
David Rutten
david@mcneel.com
Seattle, WA

Views: 1592

Reply to This

Replies to This Discussion

Hi David,

it feels funny responding to  a post back in 2010, but I had the same problem a few days ago, and coincidentally I just ran into this discussion and decided to respond. The attached file is a part of a larger script where I was filtering numbers < 950. The only number in the data set < 950 was 405.570893 and without  adding the rounding component before plugging in the data in the "smaller than component" the booleans yielded wrong results. It was quite annoying to understand why this "error" mas happening before I put the round component in. But it still dosent make any sense, 405.570893 will always be smaller than 950, or 950.0000000001. I eaven tried writing my own smaller than component in python and the output was the same. 

Is their a logical mathematic explanation for this? I did hear once that programing languages treat floats in different ways depending on the types of calculations they are used for, and thus can alter the results. But yet again... it still dosen`t make any sense to me.

Thank you

Nicholas

Attachments:

if you display the real values, all seems ok. As David said, Panel component rounds the value.

Were you saying you had some 405.xxx not < 950 ? I didnt see any in your example.

Being unreasonably nitpicky here, but just noticed that both "mesh union" and "mesh difference" are labeled "mesh union" in the menu.

Also, is it possible to make the tab scroll a little less sensitive? If my window is small enough that I have the option to scroll through the component categories, I frequently activate the scrolling when I meant to simply change tabs. I would think it would just be a matter of requiring a displacement of an additional pixel or two.

It seems like only yesterday that GH had no undo, and today all I can find to complain about are typos and differences of a pixel... keep up the amazing work!!!
Hi,

Is this a bug, or just me not getting it right?
The components giving me the right (expected) result, but then the cluster made of the same selection dose not... see image.

I tried to remodel your file but couldn't repeat the problem. Could you please post the 3dm and gh files so I can be sure I'm going down the right path?

--
David Rutten
david@mcneel.com
Seattle, WA
...sure, here you go.

//A
Attachments:
here is the result I'm reproducing... I hope it helps.


//A
It seems to be due to the same bug that causes the output sorting to fail, which is why I couldn't repeat it because it was already fixed :)

However I did find another bug with duplicated cluster outputs.

--
David Rutten
david@mcneel.com
Seattle, WA
Did This get fixed? Seemed to be a cluster issue with trees...it flattened them.
Not sure yet, I'll look into that next.

--
David Rutten
david@mcneel.com
Seattle, WA
...so look for the cluster sorting fix in 0.8.0004?
Hi David. Any chance of a "toy car" component in GH?
Or perhaps as a cluster? /Mårten

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2019   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service