algorithmic modeling for Rhino
Minor but important update to 0.8.0008. This release fixes three bugs, two of them rather serious:
Download the new release from the usual place.
If you didn't see the What's New list for 0.8.0008 you can read it on this post.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
Tags:
I plan to catch up real soon...
--
David Rutten
david@mcneel.com
Poprad, Slovakia
Apart from Centroid converts the closed planar curve into a surface first, which is slower.
And Area won't work on an open Curve where as Polygon Centre will
No, polygon centroid is merely the average of all the polygon points (not counting the seam point twice if the polygon is closed). So it's great for finding centroids of clean data such as squares, rectangles, triangles, but it will work really shitty for complicated polylines.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
Thank you David!
I will need considerably more time to understand the new release better...
But there's one thing in it which I don't find elegantly solved: The new ToRadians Component.
As less as a serious Power-User I never even came remotely close to situations where using Radians was useful. I vaguely remember that you once explained why Radians are the superior concept...
Excuse my Ignorance but I've still never use them.
Instead (and I can't count how many times) I took expressions to remap the respective Slots. I found this tedious and wished for long already to at least be able to store the my Degree-Preference as a Preset.
Either globally or inside the Component types.
With the last release Ignorants like me, building Defintions with Degrees can choose between two solutions which both cause work. I the case of the newly added Component however even the file gets bloated.
So while I don't like entering the expression too I will probably go on doing this as I still prefer this over a needlessly large Definiton. I'm sure that has been discussed before but still:
Couldn't the repective Components get toogled to certain Preset-States like Pocket-Calculators?
Or would it be possible to globally invert the User Preference somewhere in Settings?
Both would save me work.
Hi Holger,
radians is the de facto standard in mathematics and all programming languages I know. The only exception to this rule is the GDI part of .NET, which insists on using degrees to indicate arc segments, and clockwise degrees at that.
I agree that radians are a lot harder to look at, when I see 1.6345 I have no idea what sort of angle to visualize with that. The problem is that I build Grasshopper on top of existing languages, and going for Radians is the only way to keep the thing uniformly consistent.
I concede that might not be a good enough reason to use this somewhat arcane system. But I don't really know a good alternative either. Switching some parts of Grasshopper to degrees is liable to cause as much confusion as it solves.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
I can say that radians are really better than degrees, far more elegant.
i.e.:
http://en.wikipedia.org/wiki/Gradian
as you can see gradian is :
pi/200 radian
9/10 degree
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson. Powered by