to run at full screen. I've gone as far as using an iPad to use as the second monitor via AirDisplay (which actually works really well) but have never been satisfied with any setup that required you to look back and forth as if at a tennis match all day long.
Not long after first using Grasshopper 3+ years ago I've had the desire for a "Live Viewport" component that would allow a live image of the 3d geometry being generated directly in the canvas. Every once in a while I search the forums with the hope of finding a solution, but always come up empty handed. Someday this might exist although for now I have found what might be the next best thing to a native "Live Viewport" component and its enabled with a small app named Sticky Previews. This app uses the task bar preview feature within Windows 7's aero interface to create custom, floating preview windows from any open window currently running. I've only just discovered the app, but it seems to do the trick and has been stable and problem free so far. -- I will post an update if I find out that I might have spoken too soon. The install allows for a 30 day trial and is $15 bucks to purchase. I just found the app and don't know anything about this group that created the app. If you happen to know of them, Id be curious to find out more.
divided windows, cramped and slow;
unified window with floating rhino model preview;
link to the apps webpage;
http://www.ntwind.com/software/sticky-previews.html
Also works with other apps;
and the about me page screen shot;
…
Added by Tyler Selby at 11:25pm on November 26, 2012
rring to the above image)
Area
effective
effective
Second
Elastic
Elastic
Plastic
Radius
Second
Elastic
Plastic
Radius
of
Vy shear
Vz shear
Moment
Modulus
Modulus
Modulus
of
Moment
Modulus
Modulus
of
Section
Area
Area
of Area
upper
lower
Gyration
of Area
Gyration
(strong axis)
(strong axis)
(strong axis)
(strong axis)
(strong axis)
(weak axis)
(weak axis)
(weak axis)
(weak axis)
A
Ay
Az
Iy
Wy
Wy
Wply
i_y
Iz
Wz
Wplz
i_z
cm2
cm2
cm2
cm4
cm3
cm3
cm3
cm
cm4
cm3
cm3
cm
I have a very similar table which I could import to the Karamba table. But I have i_v or i_u values as well as radius of inertia for instance.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
dimensjon
Masse
Areal
akse
Ix
Wpx
ix
akse
Iy
Wpy
iy
akse
Iv
Wpv
iv
Width
Thickness
Radius R
[kg/m]
[mm2]
[mm4]
[mm3]
[mm]
[mm4]
[mm3]
[mm]
[mm4]
[mm3]
[mm]
[mm]
[mm]
[mm]
L 20x3
0.89
113
x-x
4,000
290
5.9
y-y
4,000
290
5.9
v-v
1,700
200
3.9
20
3
4
L 20x4
1.15
146
x-x
5,000
360
5.8
y-y
5,000
360
5.8
v-v
2,200
240
3.8
20
4
4
L 25x3
1.12
143
x-x
8,200
460
7.6
y-y
8,200
460
7.6
v-v
3,400
330
4.9
25
3
4
L 25x4
1.46
186
x-x
10,300
590
7.4
y-y
10,300
590
7.4
v-v
4,300
400
4.8
25
4
4
L 30x3
1.37
175
x-x
14,600
680
9.1
y-y
14,600
680
9.1
v-v
6,100
510
5.9
30
3
5
L 30x4
1.79
228
x-x
18,400
870
9.0
y-y
18,400
870
9.0
v-v
7,700
620
5.8
30
4
5
L 36x3
1.66
211
x-x
25,800
990
11.1
y-y
25,800
990
11.1
v-v
10,700
760
7.1
36
3
5
L 36x4
2.16
276
x-x
32,900
1,280
10.9
y-y
32,900
1,280
10.9
v-v
13,700
930
7.0
36
4
5
L 36x5
2.65
338
x-x
39,500
1,560
10.8
y-y
39,500
1,560
10.8
v-v
16,500
1,090
7.0
36
5
5
I have diagonals (bracings) which can buckle in these "non-regular" directions too, and they do. If I could add those values then in the Karamba model I could assign specific buckling scenarios..... I can see another challenge which will be at the ModifyElement component, I will not be able to choose these buckling lengths, in these directions.
Do you think this functionality can be added within short, or should I try to find another way to model these members?
Br, Balazs
…
used of 180 being for the northern hemisphere and 0 for the southern hemisphere.For the optimal tilt, to my knowledge, they are mostly based on correcting location's latitude through a single formula.TOF component is more sophisticated. It essentially replicates the Solmetric's Annual Insolation Lookup tool.What it does is that it creates a grid of points. Each point represents the calculated annual insolation on the surface (PV module, SWH collector, facade, any kind of surface) for a single tilt and azimuth angle.Each point is then elevated according to the annual insolation values. The mesh is created from that grid of points. The portion of the mesh which is the highest, represents the optimal tilt and azimuth angles. So the higher your "precision_" input is, the more points in a mesh you'll have - thus the more precise final optimal tilt and azimuth will be.For the diffuse component of the annual incident solar radiation for each point the Perez 1990 modified model is used. Direct is from classical cosine law, and Ground reflected component from Liu and Jordan (1963).So TOF component calculates the optimal tilt and azimuth based on annual incident solar radiation, not AC energy....…
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…
y working on is a tensegrity structure that uses cables and a tensile fabric to apply traction. The basic cell of the structure is a sail with two parallel rods.
The easy one was the fabric anchored to the extremes of the rod. I got great results with the tensegrity model , very similar to physical models that I was working on.
But then I tried the same thing with the fabric anchored all along the rods, but it proved to be hard (read all the "rod discussion"). I tried the bending force, but was too unstable. The best model I got was by applying different stiffness to the mesh, specifically, to the lines that coincide with the anchors.
It's by no means the solution that I had in mind, but the next days I'll be testing it with the structure. I came across with the next thing to my ideal solution, Daniel's boat (https://vimeo.com/30128894), but I couldn't replicate it. Anyone has some idea of a different, more rigid solution? Even in K2, which I really don't understand yet, but any clue would be helpful.
Aside of that, I was also having trouble applying real values of stiffness. The third archive has the same definition that the first, but with real stiff values (the rods are wood, k=10^7 N/m, cables are nylon k=2x10^5 N/m). I adjusted the timestep and the subiterations, but it doesn't work as stable and smooth as the whatever-stiffness-sail. I don't know if isn't correctly calibrated, or my computer its too old (it pretty old and slow) or simply isn't a good definition.
If anyone has any idea it would be very much appreciated!
Antonio…
into one file is a good poor-man's way to look at both at once. Good thought.
I really like your approach to pushing the four separate colours of line into separate branches of a single tree and then sorting it out at the end with a tree of materials. This is definitely the 'Grasshopper way'! Nice. I kept them separate because visualizing one at a time helped debugging and baking.
You are right about the three extra weave bumps. This was deliberate, but technically wrong. They are mostly invisible under the overpass thread.
I should explain the early stages.
I was initially not thinking at all about the box-morph thing, but was aiming to create a simple plane. This was the cause of later problems, but more of that below.
The initial approach is to make a 6x6 grid of points and then to shift these points up and down in the z axis to define the different levels in the weave. If you look at the Z-vector inputs to the weave, you will see that the values are actually an array of 36 values, between -5 and +5. I should have 'extracted parameter' to make this more clear. There are six possible levels: two for each basic weave and two more for the overpass threads.
The lines themselves run between pairs of points. The magic here is also rather disguised. In the 'lines' group, the Index input to the List Item sector is actually an array of 26 indexes. Again, I should have 'extracted parameter' here.
These 26 lines are orthogonal to the axes, but I actually need four sets of threads all at angle to one another. 0.197396 is arctan 1/5, in radians.
The resulting pattern has a ragged edge, but working in a plane, this is fine; the pattern tiles properly. I used the pattern to sweep out an ellipse and it printed nicely. I attach a photo of a Shapeways print.
I then started to have ambitions to make a proper surface, using a Box Morph to distribute the tiles. At this point the fact that my basic tile had ragged edges started to matter. I wasted a lot of time trying to make the same tiling within a square boundary and then it dawned on me that if I simply doubled up the pattern to give a 2x2 shape and then clipped the middle out of it with a square boundary, that would be the pattern I needed. I failed to spot the "Trim with Brep", which is where this thread began.
The trimmed pattern now reaches its bounding box faces correctly and can be used for the Box Morph.
As to the stool, yes, I did that myself. It is the same weaving, but it had to be made by threading each string in from the ends, round the bar and back into the pattern again. Because the threads go in four directions, you cannot use a traditional weaving technique - you need a needle to thread the string. There are only 10 pieces of string. Tedious stuff! I was stuck in Bruxelles for a year in 1985, working for SHAPE, and needed some mental relaxation in the evenings to keep my sanity!
Best wishes,
Bob
…
Added by Bob Mackay at 12:20pm on November 22, 2015
Permalink Reply by Manuel Rodriguez 6 hours ago
Delete
yes!perfect! It has been a good example! The only thing that I would like to change is, that, instead of deform that following the control points on the surface's perimeter, I would like to deform all, with points in the shapes (in the middle of the circle for example). It is because I want, for example, the biggest circle in point 2, and the smaller circle in point 7. So, is it possible to do?
Summing up, is do the same, but changing the control points, putting them on the shapes (circles) instead the perimeter.
Thank you very much Danny and Chris, you are being really useful for me!
Thanks! Manuel
…
t defined from the discussion of radiation exchange between urban surfaces and the sky in urban heat island research (See Oke's literature list below). It will be affected by the proportion of sky visible from a given calculation point on a surface (vertical or horizontal) as a result of the obstruction of urban geometry, but it is not entirely associated with the solid angle subtended by the visible sky patch/patches.
So, I think using "geometry way" to approximate Sky View Factor is not correct. Sky View Factor calculation shall be based on the first principle defining the concept: radiation exchange between urban surface and sky hemisphere:
(image extracted from Johnson, G. T., & Watson, 1984)
Therefore, I always refer to the following "theoretical" Sky View Factors calculated at the centre of an infinitely long street canyon with different Height-to-width ratios in Oke's original paper (1981) as the ultimate benchmark to validate different methods to calculate SVF:
So, I agree with Compagnon (2004) on the method he used to calculate SVF: a simple radiation (or illuminance) simulation using a uniform sky.
The following images are the results of the workflow I built in the procedural modeling software Houdini (using its python library) according to this principle by calling Radiance to do the simulation and calculation, and the SVF values calculated for different canyon H/W ratios (shown at the bottom of each image) are very close to the values shown in Oke's paper.
H/W=0.25, SVF=0.895
H/W=1, SVF=0.447
H/W=2, SVF=0.246
It seems that the Sky View Factor calculated from the viewAnalysis component in Ladybug is not aligned with Oke's result for a given H/W ration: (GH file attached)
According to the definition shown in this component, I assume the value calculated is the percentage of visible sky which is a geometric calculation (shooting evenly distributed rays from sensor point to the sky and calculate the ratio of rays not blocked by urban geometry?), i.e solid angle subtended by visible sky patches, and it is not aligned with the original radiation exchange definition of Sky View Factor.
I'd suggest to call this geometrically calculated ratio of visible sky "Sky Exposure Factor" which is "true" to its definition and way of calculation (see the paper on Sky Exposure Factor below) so as to avoid confusion with "The Sky View Factor based on radiation exchange" as discussed in urban climate literature.
Appreciate your comments and advice!
References:
SVF: definition based on first principle
Oke, T. R. (1981). Canyon geometry and the nocturnal urban heat island: comparison of scale model and field observations. Journal of Climatology, 1(3), 237-254.
Oke, T. R. (1987). Boundary layer climates (2nd ed.). London ; New York: Methuen.
Johnson, G. T., & Watson, I. D. (1984). The Determination of View-Factors in Urban Canyons. Journal of American Meteorological Society, 23, 329-335.
Watson, I. D., & Johnson, G. T. (1987). Graphical estimation of sky view-factors in urban environments. INTERNATIONAL JOURNAL OF CLIMATOLOGY, 7(2), 193-197. doi: 10.1002/joc.3370070210
Papers on SVF calculation:
Brown, M. J., Grimmond, S., & Ratti, C. (2001). Comparison of Methodologies for Computing Sky View Factor in Urban Environments. Los Alamos, New Mexico, USA: Los Alamos National Laboratory.
SVF calculation based on first principle:
Compagnon, R. (2004). Solar and daylight availability in the urban fabric. Energy and Buildings, 36(4), 321-328.
paper on Sky Exposure Factor:
Zhang, J., Heng, C. K., Malone-Lee, L. C., Hii, D. J. C., Janssen, P., Leung, K. S., & Tan, B. K. (2012). Evaluating environmental implications of density: A comparative case study on the relationship between density, urban block typology and sky exposure. Automation in Construction, 22, 90-101. doi: 10.1016/j.autcon.2011.06.011
…