o it would cause troubles with unfolding and fabricating... that's why I used Extrude point component- it will give you similar result, but all surfaces are planar.. you can control extrusion direction with a tip point in rhino...
2)I changed tagging so every tube has 8 points form list A and 8 points from list B... first number of tag is a number of point within one tube... last number of the tag is order of tubes (I draw a little picture in GH, hope you'll understand)...I think original way of tagging wasn't really usefull.. but you can change tagging by yourself...
3) the definition is really messy, sorry about that, but it's just quite complicated task...
4)if you find some incorrect order of tagging, use the slider that controls Shift List component ... it will shift tagging..
5) if you won't be using this definition or find some better way, pleeeease don't tell me - I'll jump out the window :D ... it took me whole day to make it work :D
6)I can't guarantee you anything- I hope it works, but if not - at least I tried... so check everything (especially order of tags and points) twice before you fabricate it.. or print few tubes and make them paper first..
7)there is a part of original definition, that is not useful anymore.. I left it there, but you can delete it (I called it "UNUSED PARTS OF ORIGINAL FILE")
..good luck
Dimitri…
ou mean by 'Activate Direct Rhino Modifying'. Perhaps you could expand?
I like the idea of mixing and matching script and 'direct' modeling. There seems to be a lot of potential platforms for this:
1. Implict History: Is there a way for GH to read the direct modifications (with History activated) and translate this as a component (or cluster of components?)? IH seems to record the UI events and the associated elements. GH would need to write as well as read the IH info, in order to preserve as much flexibility downstream as possible. You mentioned Houdini. H seems to record all 'implicit' or direct mods, done via the CAD mouse-based UI, in its network graph. Maybe, this should be captured in the IH cluster/component mentioned above.
2. RhinoParametrics: RP has done a lot of work to intercept and translate Rhino commands into its version of Implicit History. Seems to be centred on points, which makes sense as so much of the traditional 'dumb' way of inputing CAD info is based on mouse clicks on screen (points) predicated by commands, active locks, workplanes etc.
3. Gumball: Rubberduck's use of the new Gumball tool to capture 'direct' modeling inputs thru the Gumball points to a good source for capturing this kind or input, that is related to the 'macro recorder' approach taken by RP and IH.
4. The new Geom Cache component seems to be able to preserve a lot of info about the baked object. There may be even a way to read tagged info generated both GH baked with the "reference" object, and external to GH (by IH, the gumball or even third party apps like RP).
Would be interesting to know what kind of info is 'preserved'. Houdini seems to have a pretty consistent approach to geometric data, that seems to allow parallel NURBS/subD/mesh versions of the geometry. It also seems to have a coherent heirarchical approach to vertices/edges/loops/faces etc that allows the subelements to be arbitarily grouped for 'direct' modeling, and still be part of a procedural script.
I guess the polygon / mesh approach to geometry lends itself to this. If all the procedural commands/components all understand mesh geometry in either vertex, edge, face format, then combining direct and script modeling is doable in transparent way?
In your example above, the Geo Cache node 'flattens' the object to dumb geometry which is manipulated using Rhino, then used as a Reference object, in the next section of the graph. I guess there is nothing to stop the follow on components reading the precedenting graph for parameters, for additional intelligence?
Does GH 'get' or 'put' parameter data?
…
ctor. I do not dispose of any IGH_Goo instances, mostly because I have no idea when an instance is truly no longer needed. If any of your fields need to be disposed, you may have to implement a destructor, but I have no experience with this.
2) should I pass those classes to other parameters by DA(0, MotherClass.Duplicate?) or it is already there by GH_Goo ?
IGH_Goo is not duplicated by default. If you use DA.GetData() and ask for IGH_Goo types, you'll get a reference to the same instance as exists. Thus, if you take in an instance of your type, modify and output it, you should duplicate it yourself. But you only need to do this if you change the state of an instance.
MyGooType data = null;
if (!DA.GetData(0, ref data)) return;
data = data.Duplicate() as MyGooType;
data.Property = newValue;
DA.SetData(0, data);
3) should I create ChildClass and MotherClass in SolveInstance, or create it once as a component's field and then change theirs properties and pass it to DA (as duplicate ?)....
It's almost always better to use variables with the lowest possible scope. So method variables are preferred to class variables, class variables are preferred to static variables.
4) if I create those classes in SolveInstance, is it necessary to Dispose them there ?
NO! Do not dispose of instances that are passed on to output parameters. Disposing objects typically makes them invalid, so if you share instances with anyone else, you should not dispose them or the other code may well crash. However I don't think your types need to be disposable so this is a moot point now.
In general, if you're dealing with disposable types, and the instances aren't shared, then you dispose them as quickly as possible. But if they are shared it's a lot more complicated.
5) finally - maybe it would be better if MotherClass inherits the ChildClass ?
Maybe. Not necessarily. Depends on the classes. …
Added by David Rutten at 12:08pm on December 31, 2014
ight be able to provide more insight). Whenever you run a new simulation in Radiance, it is not always necessary to re-write all of the initial simulation files from scratch. These initial simulation files include both a .rad geometry file as well as a separate .pts file that contains the test point locations. If all that you are changing in a given parametric run is the locations of the test points (like your case), it is not necessary to re-write (or reinterpret) the entire .rad geometry file. My guess is that there is some type of check for this built into either code Mostapha wrote or radiance functions that Mostapha is calling. As such, it seems that the rad geometry file is not being re-written (or re-interpreted by radiance) completely when all that you change is the test points and this actually seems to be saving you an extra 10 seconds each time that you run the component without changing the materials or the building geometry. Other times (like when you plug in custom radParameters), it seems that it re-writes (or re-interprets) the .rad geometry file from scratch since this file is probably affected by customized rad parameters.
So far, if this explanation is holding, it seems like there would be no concern on your end but I also recognize that the difference between these long and short simulations is giving you radiation results that are ever so slightly different from each other (by my estimates, they differ by about 0.2%). Compared to the other types of assumptions that the radiance model is making, though, these are mere rounding errors that probably originate from the number of decimal places in the vertices of the rad geometry file. Rather than worrying about whether your simulations are giving you the right rounding errors to give you matching results, I would encourage you to instead contemplate how much your radiance results are matching reality given all of the assumptions that you are making about the climate (with the epw file for a "typical" year) and with the number of light bounces in the radiance simulation. To give you an example, I ran your model with a higher quality of simulation type (3 ambient bounces) and this gives you results that differ by 1.1% from the original simulation that you were running with only 2 ambient bounces (this is practically an order of magnitude larger than 0.2%).
To address your unease I will say that, for a long time, I also felt uneasy any time that I encountered something that seemed unpredictable in software that I was using. Once I started coding my own stuff, though, I realized quickly that unpredictable behavior is an unavoidable aspect of all software. There is always a tradeoff between accurate results and the time it takes to get them, which produces a multitude of possible ways to arrive at a solution. Add into this complex situation the fact that you might have an almost infinite number of possible inputs to a given set of code.
Because of the unpredictable multitude of cases, there is no application that is completely free from limitations and assumptions. In this light, what ends up being more important than the actual calculation method used is the social infrastructure that is in place to help understand what is being run under the hood, hence why both Radiance and Honeybee are open source and why we try to build a robust community of support through forums like this one!
-Chris…
size component supported only ground PV panels and angled roof PV panels.
Download the newest PV SWH system size component from here (Click on "View Raw" to download it. Then move the downloaded .ghuser file to File->Special Folders->User Objects Folder, an confirm to overwrite it with previously located one).
Just a few opinions on the project you are currently working on:This kind of fixed, non-transparent (overhang) PV panels attached to a building facade are vert convenient for locations with higher latitudes.The reason for this is because they (fixed overhang PV panels) are dimensioned according to the sun position at summer solstice. Elevation angles on summer solstice at higher latitude locations are lower, than those of lower latitude locations.Due to Incheon's low latitude (37), you will get rather short length of the PV panels* : less than 10 centimeters (0.097 meters in the attached .gh file below). As you have mentioned, Galapagos needs to be used too.I will just mention some of the good and bad ways in which the upper issue could be somewhat avoided:1) Increasing the vertical distance between PV panels (PV panels appear above every second window).2) Increase the tilt angle. This will increase the length of PV panels also, but will decrease the final annual AC energy output.An example of this solution has been applied at FKI building in Seoul (latitude: 37N):I already did some tests (with tilt angles: 40, 45, 55) and this does not seem like a good solution, though.3) Shrinking the "sun window" by using the minimalSpacingPeriod_ input. In Photovoltaics, a planner is suppose to make the 9h to 15h part of the sun window free of any obstructions. If you try to decrease the "sun window" to 10 to 14h, the length of your PV panels will increase. You can try to experiment a little bit with this (set your minimalSpacingPeriod_ to 21th of June 10 to 14hours). In general, shrinking the sun window on summer solstice is not a good principle during planning.4) Using tracking PV panels, not fixed ones. But Ladybug Photovoltaics components do not support this kind of PV systems. They only support fixed ones.I would personally go with the first option. You can also experiment with the second and third one.Comment back if you have any other questions.-----------------------* By "length of the PV panels" I mean the: tiltedArrayHeight_ input of the PV SWH system size component.…
e point in each pair that has the lowest Z value (then later the highest Z)... The problem is the intersections are not returned sorted by Z, sometimes the lower point is first in the list, sometimes last. So I need to sort those pairs of points by Z value.I noticed the sort points component does not have any inputs for sort criteria... RhinoScript SortPoints allows you to sort by:
blnOrder
Optional. Number. The component sort order, where:
Value
Component Sort Order
0 (default)
X, Y, Z
1
X, Z, Y
2
Y, X, Z
3
Y, Z, X
4
Z, X, Y
5
Z, Y, X
Will we get something like this in GH? For now I think I can manage to analyze the Z for each and re-order the points, but a more comprehensive point sorting tool might be nice... no? Or did I miss something obvious? --Thx, --Mitch…
works joyfully if you want to change parameters and generate screen captures and planning to do a lot of them. You can of course generate the file name dynamically referring to the parameters you gave to the script, so that you have meaningful file names.
The example below will generate two captures at J:\Temp\001_top,jpg and J:\Temp\001_front,jpg both at 600X600 px in ghosted mode.
The instructions are as follows: (if you open the VB code by double clicking you will see it)
' Note1: The script is actually calling Rhino commands.
' Note2: Remember you have to draw something and is selectable for the script to function. The script uses _SelAll then _Zoom _Selected
' Note3: After you toggle blnSave to True, a new viewport will popup, be patient while Rhino work, and wait for that viewport to disappear befor clicking on anything.
' Note4: The component is not stable if you try to mouse click on anywhere while the saving process is running. Some stupid move may crash your programme, save RH and GH files before using this component.
' FileName : String Input = Supply with the path and file name without ".jpg" extension : e.g.: "C:\Temp\001" (Without the quotes)
' blnSave : Boolean Input = Saves when toggles to True (Remember to toggle back to False after use, otherwise the script will re-run itself during next update)
' Resolution_width : Integer Input = Resolution for the captured image
' Resolution_height : Integer Input = well...
' TopYea : Boolean Input = Toggles if the Top View is captured (Default is False if not connected)
' FrontYea : Boolean Input = Toggles if the Front View is captured (Default is False if not connected)
' ...Yea : Boolean Input = Toggles if the corresponding View is captured (Default is False if not connected)
' DisplayMode : Integer Input(0-4) = Sets the display Mode 0:Shaded 1:Wireframe 2:Rendered 3:Ghosted 4:XRay Default:Shaded
I remember I took some code from somewhere but I forgot exactly the source, (if someone could remind me I would love to cite) I rewrite most of them though. But the attribution header in the code still remains there and now it seems a bit interesting to see the family tree:
'////// Marc Hoppermann ///////////tweaked by Damien Almor ///////rewritten for curves by to]///////adapted by u]...www.utos.blogspot.com ///readapted by Victor Leung @ www.dreamationworks.com
Visit my blog if you have time: www.dreamationworks.com…
se (like in nature). the length of the sticks shall be controlled by the brightnessvalues of a picture. so the bend have to be controlled, too.
now we have several problems:
1. how can i map a hexgrid on a curved surface?
2. how can i adapt the grid to the dimensions of the surface (no overlap, no gaps to the bound)?
3. important
: to create the curved sticks, we use points on a line and we move some of them and then we want to connect the right points via interpolated curve to create each curved stick. now the problem is that the points have to been filtered in the right way. we know that we have to filter each list of points to the index values of the points. the number of index values is the number of hexgrid rows, so there are a lot and we can't use a list item for each one. it could be hundreds.
is there any opportunity to sort a list after the index values (first every index=0, then index=1, ...n)?
or is there any component which does a group of operations for n-times (n is the flexible number of index values) ?
4. how can i control the length and bend of the sticks via the brightnessvalues of a picture?
please help us. thanks.
german version:
In einem hexagonalen Raster soll sich senkrecht zu Oberfläche ein Stab im Mittelpunkt jedes Sechsecks befinden. Dieser soll sich ab einem gewissen (festgelegten) Punkt Richtung Boden biegen. Zusätzlich wird die Länge des Stabes zum Beispiel durch die Information eines Bildes gesteuert, so dass auch die Biegung, je nach Länge, geregelt werden muss.
Wir haben ein Hexagonales Grid (HexGrid) erzeugt und in jeden Mittelpunkt eine Linie senkrecht zum Grid erzeugt, aus der wir uns Punkte mit CurvePoint ausgeben lassen. Der letzte ist verschoben, um eine Biegung zu simulieren. Um die Punkte zu einer interpolierten Kurve zu verbinden, müssen sie nach dem Index sortiert werden. Gibt es eine andere Möglichkeit, als jeden einzelnen Indexwert über ein ListItem herauszufiltern (Da die Rasterung flexibel einstellbar sein soll, entstehen n Indexwerte)? Oder kann man eine Liste nach den Indexwerten, also nicht nach den Punkten, sortieren?
Und wie kann man über Bildhelligkeitswerte die Länge der Stäbe und damit auch die Biegung steuern (ein kurzer Stab biegt sich weniger als ein langer Stab)?
Gibt es die Möglichkeit ein hexagonales Raster auf eine gekrümmte Fläche zu mappen?
Und wie passt man ein solches Raster (HexGrid) in eine Fläche mit definierten Maßen ein, ohne dass das Raster an den Rändern übersteht oder die Fläche nicht vollkommen ausfüllt?
danke.…
Added by doro hamann at 7:34am on December 20, 2011
nition. Using RenderAnimation component from http://www.giuliopiacentino.com/grasshopper-tools/, I could do all of above except for the Toon material part.
I have found a post regarding same matter ( http://www.grasshopper3d.com/forum/topics/how-to-add-materials-to-material-table ), but since I am not very familiar with scripts, this is what I think his definition does. Correct me if I am wrong.
Since Rhino Vray only supports Toon environment per material (unlike Max Vray has global override feature),
1. import toon material from Rhino material editor
2. add colors to the toon material and make new toon materials with color (as many as needed)
3. import that new materials back into grasshopper
4. match them with designated geometries and render. (RenderAnimation component by Giulio does this job) Here is the final work he did : http://vimeo.com/34728433
Grasshopper + Vray from Marc Syp on Vimeo.
I am using rhino 4 with vray 1.5.
I have uploaded my definition, simple definition that transforms box height along with color as frame advances. The definition works but toon effect is not there.…