ike using something like the Z vector, but technically you can use any vector you want. This vector will actually determine the static rotatation of all the planes, so you can control that here if you like. One important thing that I've noticed is that the closer the vector is to the plane of the curve or if its too similar to one of the tangent vectors, the more likely you'll have "flipping"
2) Take the cross product between the tangent and the static vector. This will be your first perpendicular vector, which you can use for the X component of the plane.
3) Take the cross product between the tangent and the result of the previous cross product. Use this result as the Y component of the plane. All three components (X, Y, and Z (which is the tangent vector)) are all perpendicular to each other now.
After you've done that you should have planes that decrease twisting. If your curve is not planar, then there will always be some twisting in the frames, but it will be minimal enough to use them effectively.
There also may be "flipping" within the frames, which means one (or both) of two things. First, you could have planes that have reversed their vectors, so the X vector is properly oriented, but pointing down when it should be pointing up. Second, the X and Y vectors could have potentially swapped, so that Y "should" be X and X "should" be Y. In order to check these things, you'll need to do a few tests. The first one is find out whether the vector (X or Y) of the plane your testing is pointing in the opposite direction of previous vector. The second test is to find out whether the vector (X or Y) of the plane your testing is perpendicular to the previous vector. In both cases, an angle test between the two vectors will be able to tell you what you need to know, but you will likely NEVER get exactly 180 for an opposite test or 90 for a perpendicular test. That means that you have to choose a range with which to determine that a given vector is opposite or perpendicular.
You should start testing the X vector to see if anything is wrong. If you find that the X vector is fine, then just move on because Rhino will only allow you to create right handed planes, and the Z vector (the tangent) will always be the same.
I don't believe that there's a native function within the old dotNET SDK for calculating angles, so use the example at the link below. It basically takes the arcCosine of the Dot Product of the two vectors your testing to return the angle in Radians. I'm not sure if this function is included in RhinoCommon or not....
http://wiki.mcneel.com/developer/sdksamples/anglebetweenvectors…
ed when membrane cones are invited to the party (then mesh (via Starling is the best way) the brep and send data to Kangaroo : the easiest thing to do). But patch doesn't trim the inner Loops and ... well initially I thought to find this in SDK and do the job:
Well... I confess that I can't get the gist of the Brep.Trim (as explained in SDK).
Thus go to plan B: having already the closed breps (the "cones") as cutters ... attempt a Boolean difference
but this does that (this looks to me a bit paranoid, but some reason must exist):
What I want is this:
the code that mess things is (open the script inside definition attached):
BTW: where in SDK is that DeBrep thing?
BTW: Delaunay GH syntax is still cryptic to me (but this is not an issue anymore)
I would greatly appreciate any help on that final step (to greatness).
The full working definition soon (v5: with 90% of components replaced by C# stuff).
best, Peter
…
bout angle since the exact same wires can suddenly start working fine later! Just adding new items to Rhino and then using undo to get back to your failing geometry will fix it sometimes?! Flipping the pair of curves' directions, either one or both, fixes it. It's just black box broken. It happens for really boring angles near 90 degrees.
Rotating the entire pair in space has no effect.
Rescaling the lines from their joint point has no effect.
Simply cutting and pasting the lines out of Rhino back in *sometimes* fixes it, so it's angle and something else that makes certain lines "toxic."
Duplicating the pair of failed lines via alt-dragging the Rhino gumball fails to fix it.
Running the "line-like curves" through a Line component to give "lines" doesn't fix it.
Re-creating the lines by extracting endpoints fails to fix it.
Each line, if separated from each other works fine.
Grafting makes each line into its own little cylinder minus a hub.
The error is the boilerplate "Object reference not set to an instance of an object."
Once the pair spontaneously starts working I cannot reproduce the error with that pair again, though sometimes Rhino undo will get me back to failing.
CAN ANYBODY REPRODUCE THIS WITH MY FILE? If so I can submit a bug report.
Exoskeleton is here: http://www.grasshopper3d.com/group/exoskeleton
Source code is here but it's for compiling, not something I can just test in a C# component out of the box:
https://github.com/davestasiuk/Exoskeleton2/commit/f63c4aa691a7f26b...
…
s is like flattening your data PARTIALLY - chopping an index off the end of the branch paths without obliterating the tree entirely. When working with one "set" of input data, a flatten works to get these lists to match up - but when working with multiple sets, we need to be careful to preserve the original branch indices that keep all four of your original regions separate. As a rule, whenever you're feeding two data trees into any component, they should have the same number of branches. (or one should have branches and the other should be a flat list, in other cases).
The rule of thumb I tend to teach is this:
In 90% of cases...
For lists, all your inputs should either have 1 item or N items. That is to say, if you're feeding 4 items into one input and 9 items into another, something is probably wrong.
For trees, all your inputs should have either 1 branch or M branches. That is to say, if you're feeding a tree w/ branches {0;0} to {0;3} into one input, and a tree w branches {0;0;0} to {0;3;8} into the other input, something is probably wrong.
Grasshopper essentially matches up branches first, then lists second. By "matching" I mean it processes them together. Simple example of the Line component - it will match the first branch of points in the A input to the first branch of points in the B input, creating lines between those points, then match the second branches, the third branches, etc. THEN, it applies the same logic to the level of the list (with a pair of matched branches {0;2}, match all the items in those branches to each other - first item in one branch to the first item in the other branch, etc.)
This is a tricky concept but it seems like you're already well on your way to understanding it from your definition - "PShift" is a critical tool in your path management arsenal. I hope this (overly long) response helps clear things up for you!
…
he TOF and TSRF indices. They show, how "distant" is your _PV_SWHsurface from the optimal _PV_SWHsurface surface in terms of tilt and azimuth angles.However, in your case we are not interested in TOF and TSRF indices. We would just like to know what are the _PV_SWHsurface optimal tilt and azimuth angles, regardless of the supplied _PV_SWHsurface.
So the circular surface supplied to the "TOF" component's _PV_SWHsurface input is irrelevant. It can be of any area, and any tilt/azimuth angle.The PV_SWHsurfacesArea output of the "PV SWH system size" component depends on a couple of factors:moduleActiveAreaPercent_ (leave it at 90%).
moduleEfficiency_,
systemSize_.Calculation of systemSize_ depends on your electricity demand, cost of the PV system, type of the object, country, local regulations etc. This is something that an engineer needs to determine.For example, in USA for a residential house in the Sunbelt, depending on finances, a household would try to cover 100% of its annual electricity needs with their PV system. Which means that the systemSize_ you chose needs to cover the annual electricity consumption. You can perform EnergyPlus simulation or use any other way to get the annual electricity consumption.
Ladybug "Photovoltaics Performance" component can calculate the optimal systemSize_ by given the annual electricity consumption.However the component is made to address fixed tilt and azimuth PV systems only.An approximate way to overcome this is to calculate the optimal systemSize_ for fixed tilt and azimuth PV system, and then multiply it with the "difference in %s" panel at the very right of the fixed_vs_tracker_PV2.gh file. Again, this is not what Ladybug "Photovoltaics Performance" component is made to do, but it will probably get you in a ball park.
Inputted 32 degrees for north_ direction is actually 328 degrees.This is due to Ladybug Photovoltaics being based on NREL model which uses clockwise angles convention. This convention is also most commonly used in solar radiation analysis.
Dubai weather data files are uploaded in here.
…
:
______________________________________________________________________
As most of you know by now, Grasshopper will be included in Rhino 6 for Windows. We are almost finished with the Grasshopper in Rhino 6 development and you are invited to try it.
There are many enhancements, including:
High DPI displays are now supported.
Compatible with existing Grasshopper plug-ins.
New components including Make2D, Bend, Flow, Maelstrom, Splop, Splorph, Stretch, Taper, and Twist...
GhPython is now included. It features its own GHA compiler and a major node-in-code speed up.
Stable development target: Your plug-ins continue to work each minor Grasshopper upgrade.
RhinoCommon enhanced: More Rhino core functionality is accessible from within Grasshopper.
Developer documentation is online with guides and API references.
Now:
Download the current Rhino WIP for Windows
Try all your existing Grasshopper definitions
Report any problems you find here...
We want to make sure this new Grasshopper works for you. If you have any issues, David needs to hear from you very soon.
Thank you,
- Bob
Visit Grasshopper at: http://www.grasshopper3d.com/?xg_source=msg_mes_network
______________________________________________________________________
So...
Any news about OS X version? Many of us won't use Parallels or whatever win emulator or have a win machine nearby.
Hope you are working at it.
Cheers
gbrl
…
Added by Gabriel Netto at 3:44pm on October 29, 2016
o Common - just like C#. But Rhino Python has a "Scripting Language Wrapper" which breaks commonly used taks down to simpler functions.
Here's a general Example:
Take a look at the code on this website http://wiki.mcneel.com/developer/rhinocommonsamples/addline). Generally it's Rhino Common code in three language to create a line. They look equally difficult.
But if you use Rhino Python Scripting you can use an simplified syntax to get the same result. It's very similar to Rhino Script.
The code would be:
import rhinoscriptsyntax as rsstart_point = rs.GetPoint("Get start point")end_point = rs.GetPoint("Get end point")line_id = rs.AddLine(start_point, end_point)
OK - No Error Tracking here, but still you can see that the syntax is much simpler. (And in the end you just have less lines of code you have to debug.
And the good thing about Rhino Python is, that you can mix these approaches. Once you reach a level where Rhino Python Script doesn't get you there, which by the way happens very rarely, you can still use the Rhino Common methods.
Also, in Python Sycripting 99% of what you probably would like to do is available as a "wrapped" script function.
Rhino Python Script is currently also better documented than Rhino Common for C# and VB.Net. If you have used Rhino VB Script before, these functions will be very familar to you.
I'm not sure, why it's currently a separate plug-in. I belive the reason is that Rhino 4 (which is supported by GH) doesn't support Rhino Python. Also it's currently WIP, so it needed to be updated more frequently than GH itself. In the long run (I believe) it might be integrated into GH as a general component
- Martin
P.S.: To use Rhino Python within GH is a little more tricky than my example - but nothing compared to developing C#
P.S.2 Here's the code with Error Tracking:
import rhinoscriptsyntax as rsdef AddLine(): start_point = rs.GetPoint("Get start point") if start_point is None: print "No start point was selected" return end_point = rs.GetPoint("Get end point") if end_point is None: print "No end point was selected" return line_id = rs.AddLine(start_point, end_point) return line_idAddLine()
…
(1) I have been exporting small sections of a larger model into Maya from Rhino as FBX. In Maya I rotate and scale the models (-90 in X, Scale XYZ 0.001). The Named Views are being saved, but do not have a successful import into the Maya model. They do not appear as in Rhino, and the problem is not solved by scaling or rotating the cameras.
(2) If I try going the other direction, the cameras exported from Maya as FBX are also not aligning with the model in Rhino as they are in Maya.. I will do my best to post some images of the problem and hope you can help.
error !!
This is what the named views look like
here I am trying to the other way with a good view from Maya
strange placement..
This is the best result I can achieve, after I scale the camera by 1000
Any Advice???
Thanks, Robert.
…
ysim.ning.com/
When you run the simualtion you will notice on the batch terminal that Daysim is also being called, so you may want to consider how Daysim uses Radiance files & data.
Regarding your current problem, I think you stumbled onto something weird and interesting.
Interior and exterior readings appear to differ by 40 in the best case scenarios. Even setting the transmittance to 1 yields similar results. I tried changing from cummulative sky to climate sky and got similar values. Changing the test points did nothing either.
I think, (yet I'm too lazy to prove this) that the difference in values stems from diffuse radiation over the sky dome.
If you delete everything except the glass you'll notice that interior values are like 80-90% of the exterior values (this seems like the expected behaviour with a transmittance of 1). So, if we consider that a vertical window, part of an opaque box, is receiving radiation from 25% of a sphere, as you start to inset the interior test points the radiation they receive will be a fraction of the 25%.
Let me try to explain this better...The exterior surface receives radiation from a section of a sphere calculated by 180degrees on the xy plane (let’s call this angle theta) and by 90degrees (let’s call this angle phi) in azimuthal elevation. If you integrate this over spherical coordinates (theta from 0 to pi; phi from 0 to pi/2) you will find that it comes to a quarter of a sphere. By comparison, the interior surface will not integrate theta from 0 to 180degrees,nor phi from 0 to 90degrees, instead it will be the subtended angle from the exterior surface as a function of their separation; the farther in you go the smaller the view of the outside.
If my hypothesis is correct there shouldn't be that much difference since the separation is only 10cms...the subtended angle would be like 170 instead of 180 for theta and 85 instead of 90 for phi...overall if you integrate both spherical areas there should only by a difference of 10%.
In conclusion, I believe the unexpected behaviour stems from the previous subtended angle thing. If direct radiation was the only factor the difference would be the aforementioned 10%, which suggests that an additional source of energy is also affected by this. Perhaps indirect and diffuse radiation from other areas of the sky dome.
I’m definitely intrigued on why this is happening. Please post if you figure it out.
Regards,
Mauricio
…
TB of RAM. I think I'm going to start a GoFundMe campaign to buy one for myself :)
2- The server's cost is about $13 an hour. I get free access to supercomputer through my university and xsede.org because I earned an NSF Honorable mention last March, however, the supercomputers available through both resources are a little complicated for me to use, as opposed to the one available from amazon that has Microsoft server 2012 already installed.
3- I wanted to run 400 annual glare simulations for 400 different views.
4- I tried a to perform annual glare simulation for one view on my Dell XPS that has Intel Core i7-6700HQ processor and 16GB of system memory. The simulation took 2 hours to complete. Radiance parameter ab was set to 6.
5- I wanted to obtain the batch file for each view so I can run them on the server. So I used the fly component to run all 400 simulations and closed the cmd windows, that wasn't bad ( for me at least) because I asked my son to this job for me, he was just glad to help me :)
6- I created one batch file using this cmd command:
dir /s /b *.bat > runall.bat
This created a file with the path to each .bat file. I edited this file in Notepad++ to include the word "start" at the beginning of each line. This was done using the "find and replace" dialogue box.
7- I split my newly created batch file into 3 batch files, each one has about 130 file names and " start" before the file names.
8- installed radiance on my server
9- Ran the first batch file on the server, this started 130 cmd windows performing my simulations, CPU usage was anywhere between 90% to 100% and about 105 GB of RAMs were used.
10. It took about 5 hours to complete all 130 simulations, I expected to run all in 2 hours but can't complain because this would've taken about 260 hours to run on my laptop. After the simulations done I ran the second and then the third batch files ( total of about 15 hours).
11. I got 400 valid dgb files. Couldn't be happier!
…