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…
or create a form through code.
2) Add a public function to your component that displays this form, I recommend you use form.ShowDialog() for now to avoid weird conditions with non-modal forms.
3) Override the method Menu_AppendCustomComponentItems() on your Component and add an extra menu item that will show the form (i.e. when clicked, it will call the function defined in step [2].
4) Create a new class and derive it from Grasshopper.Kernel.Attributes.GH_ComponentAttributes. (if you don't want to offer double-click functionality, you can skip steps 4 to 6)
5) Override the RespondToMouseDoubleClick() method on the new attributes and also call the function defined in step [2]
6) Override the CreateAttributes() method on your Component class and construct an instance of the custom attributes defined in step [4] instead.
7) Once you've shown the form and the user has clicked OK, you need to assign values and invalidate the Component, then start a new Solution.
Here's some code:
Public Class MySpecialComponentAttributes
Inherits GH_ComponentAttributes
Public Sub New(ByVal comp As MySpecialComponent)
MyBase.New(comp)
End Sub
Public Overrides Function RespondToMouseDoubleClick( _
ByVal sender As GH_Canvas, _
ByVal e As GH_CanvasMouseEvent) As GH_ObjectResponse
DirectCast(Me.Owner, MySpecialComponent).DisplayForm()
Return Canvas.GH_ObjectResponse.Handled
End Function
End Class
Public Class MySpecialComponent
Inherits GH_Component
.....
.....
Protected Overrides Sub Menu_AppendCustomComponentItems( _
ByVal iMenu As ToolStripDropDown)
Menu_AppendGenericMenuItem(iMenu, "Set Values", AddressOf Menu_SetValues)
End Sub
Private Sub Menu_SetValues(ByVal sender As Object, ByVal e As EventArgs)
DisplayForm()
End Sub
Public Sub DisplayForm()
Dim frm As New MySpecialForm()
Grasshopper.GUI.GH_WindowsFormUtil.CenterFormOnCursor(frm, True)
If (frm.ShowDialog() = DialogResult.OK) Then
'Harvest values from form and assign them to local variables
Me.ExpireSolution(True)
End If
End Sub
End Class
--
David Rutten
david@mcneel.com
Turku, Finland…
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
rk and I will just clarify some of the details. I will also note that I do not know what the shadings output of the decomposeByType component is supposed to do as Mostapha put it there a long time ago and I was not sure what his intentions were. Going down a list of clarification points:
1) You are right that you should either connect up the shade breps to the EPContext component or just plug the HBObjwShades into the RunSimulation component (never do both). However, connecting the breps to the EPContext component is greatly undesirable for two reasons: It will make the simulation run much longer and the energyPlus calculation will not account for the surface temperatures of the blinds (it will assume they are the same temperature as the outdoor air, which is very wrong in a lot of cases). When you connect up the HBObjwShades to run the simulation, EnergyPlus will understand the blinds as abstract objects defined only by a numeric parameterization and not as actual geometry. This enables the calculation to run fast and is also enough of a description that E+ can calculate the temperature of the blinds, thereby accounting for the heat that can be re-radiated from the blinds to the indoors when they get hot in the sun. This more desirable way of running the blinds was how I imagined the component being run most of the time and I mostly included the shadeBreps so that you have a visual of what you are simulating.
2) When you use the more desirable HBObjWShades to approximate your blinds, you should use the blindsSchedule input in order to tell E+ when the shades are pulled (this is instead of the transShcedule on the EPContext component).
3) The zoneData inputs on the EPWindowShade component are meant to help in an entirely different workflow, which evaluates shade benefit based on energy simulation results. I apologize if it seems confusing to have two major uses of the component in one but we have so many Honeybee components right now and I did not want to make 2 separate ones when they seemed so similar. See this example file to see how to do energy shade benefit (https://app.box.com/s/oi64zoj5u1slz494grzhgmdkx7yie9jo).
Ok. I think that clears up everything that I know. Now to the part that I do not. As I said, Mostapha put in the shadings input there a long time ago and I do not know what his intentions were. Abraham, as you know, I am about to do a major revision of the EPWindowShade component to make it compatible with OpenStudio, include drapes/generic shades in addition to blinds, and I also should figure out how to do electrochromic glazing. I can easily include all of the visualized shades as output from the decomposeByType component when I do this. However, I do not want to interfere with other intentions Mostapha had when he put the input in. If he could confirm that this was in-line with his vision for the shadings output, I will implement it soon.
-Chris
…
On the other hand ... well ... we can pretend that this could be some sort of add-on dedicated for broken pieces, (and nerves if loops = a big number) he he.
Anyway:
1. If you enable the history (the yellow things) you can watch the recursion working: get a donor box and "slice" it in 2 (either via an "orthogonal" plane [the fast boxes] or a random one [the slow breps]). Then get each one and repeat until the desired "depth" of "slices" is achieved (the loops, that is). Pure recursion in terms of programming (a function does something, yields results and then calls itself to further process each result).
Double click on the C# to see the code (but don't change anything). For the record this is the function that does the main job (spot the fact that if it's not terminated it calls itself [last line]):
2. The x, xy, xyz options restrict the random plane (actually in the boxes case there's another technique used (Intervals) but never mind). For instance (case random breps) the slicing plane is defined at the brep center and using a random direction:
Vector3d dir = new Vector3d(rand.NextDouble(-1,1), rand.NextDouble(-1,1), rand.NextDouble(-1,1));
If the 3rd value is 0 then the plane's YAxis is parallel to Plane.WorldXY.ZAxis.
3. Now if the "slicing" thing was a random polyline at a random plane the pieces could be far more "elaborated" (and/or "naturally looking") ... but the thing with programming is to know(?) where/when to stop.
4. This approach could use any donor Brep (a blob for instance) or a Brep List. Notify if you want to add such an option.
5. Added some lines more for an option that allows to sample the pieces (due to the last loop) in an automated flat "layout" (it's a bit more complex than it appears on first sight).
6. The x,y restriction mode now affects the random slices as well. See what I mean:
and the same restriction using boxes:
Truth is that all that freaky stuff could be helpful for you if you had serious plans to learn C# (not something achievable without pain and tears aplenty).
best…
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…
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.…
case for sure (started by Giorgio a couple of days before). Ive got involved because I exploit ways to "relax" shapes on nurbs (say patterns created by Lunchbox or "manually) without using any kind of mesh (more explanations soon).
Here's 5 test cases (SDK appears that doesn't have some "thicken surface" thing ... thus the algo that finds the "whole" shapes is rather naive) VS 2 Kangaroo "methods" and the why bother (he he) option as well.
If the goal is to "fit" these shapes within the nurbs ... does it work so far? No I'm afraid (appears that "springs" used are not the proper ones - or [Kangaroo1 option] the lines that pull should been originated from valance 2 points only)
Tricky points:
1. Internalize appears having a variety of serious issues (see Input inside definition) - Load Rhino file first (but even so ...).
2. Pull to surface is deactivated - this is not the issue here (and it's very slow).
3. Since Starling/WB alter the "curves - points" related order
the issue here (Pull points to curves) is to correspond apples to apples:
and that's what Anemone does:
From chaos :
to order:
this means that prior activating Kangaroo you should double click to the Anemone start component in order to "sort" properly the curves.
But .. fact is that results are pathetic:
more soon
best, Peter…