algorithmic modeling for Rhino
During a workshop in Hamburg I briefly attended a couple of months ago, I noticed a lot of people have trouble with basic trigonometry. Figuring out angles and length of triangles. Added two components to help with this (one for right-angle triangles, one for generic triangles). Input all the values you know, and it will compute all possible missing ones.
Tags:
Comment
Hmm, not sure I like that. First of all it would have to be clear which (+) symbol refers to which variable, which is currently not possible in the ZUI framework.
Secondly I'd have to provide 6 (+) symbols without any inputs already there, which is currently not possible in the ZUI framework.
Thirdly it prevents people from using the same component with streams of data, some of which may be nulls. Perhaps you want to use the object to solve 1000 triangles, 400 of which have only 2 known edges, and 600 of which have 2 known angles. If the component can only handle either of these cases at the same time, you'd have to split up 500 lists of data into two separate streams, use two trig components and then fold it all back together again. This is probably a very rare case, but it sounds like an unnecessary limitation.
The angles are defined as standard angle parameters, so rounding to 0.1 degrees isn't any good if you're using Radians. Plus 0.1 degrees is pretty coarse, one can do a lot better with 64-bit floating point numbers.
I think my initial solution will be to simply add a warning to the component if you supply more values than needed.
@David: Nope.
There is only one component (the upper one). When created it doesn't have any inputs, just all outputs.
Here are few scenarios :
1.Triangle with A,B and P
2. Triangle with P,Q,R
3.Triangle with P,Q and C
To make it all easier, disable the possibility to internalize the data.
Tolerance issue... Maybe round the angles always to floor , with 0.1 precision ?
@Mateusz. Are we talking about the same thing? I mean that all inputs are optional, and it's thus possible to 'provide' values that cannot possibly represent a valid triangle. For example two angles can be given as 88° and 95°. All three angles must sum up to 180, and we're already 3 degrees over balance. Or maybe the user specifies three edge-lengths: 21, 12 and 8. 21 is bigger than 12+8, so even if the triangle was stretched flat, the two short edges cannot reach the ends of the long edge. The above is easy to test for and I add errors to the component if an invalid triangle is provided. However there are also many angle+edge length combinations which result in invalid triangles.
I could of course test for these as well, but the problem is now tolerance. What if the user specifies a redundant angle of 54.7°, whereas the mathematics tell us that the actual angle is 54.7002°. Is that an error? If so, is the angle wrong or is perhaps one of the edges wrong? Or has the triangle simply been over-constrained? Is there a mathematically robust way of dealing with this? And if so, would that also be the most user-friendly way of dealing with it?
I'm not really after the idea to create those components (learn trig), but I think that this problem
It is still somewhat problematic at the moment if too many values are user-specified. I performsome checking to see if the data represents a valid triangle, but there are still plenty of impossible combinations that aren't caught.
Can be very nicely solved with ZUI.
A general rule at the moment is if you can see it it is GH1.0. Look out for them in the next release I would guess.
Cool, I can't wait for the GH2!
Is it trivial to have an output for the equation(s) being used?
© 2021 Created by Scott Davidson. Powered by
You need to be a member of Grasshopper to add comments!
Join Grasshopper