ng/702/30
EDIT: DK2 works, not with positional tracking yet (14/09/15)
Source is here:
https://github.com/provolot/RhinoRift
Steps:
1) Download these files (also attached below):
https://github.com/provolot/oculus-grasshopper/raw/master/oculus-grasshopper_v0.4.ghx
https://github.com/provolot/oculus-grasshopper/raw/master/OpenTrackRiftGrasshopperUDP.ini
https://github.com/provolot/oculus-grasshopper/raw/master/oculus-grasshopper-test_v0.1.3dm
2) Download OpenTrack - http://ananke.laggy.pk/opentrack/, and setup/install. Once installed, double-click to open.
3) In OpenTrack, load the 'OpenTrackRiftGrasshopperUDP.ini' profile. Click the 'Start' button and move your Rift around - make sure that it looks like the Yaw/Pitch/Roll data is being sent. TX/TY/TZ will all be 0, as Oculus doesn't have absolute positioning data.
4) In Rhino, open the test 3dm. You'll notice that there are two viewports - called 'LeftEye' and 'RightEye'. These have been placed to mimic where the screens should be for the Oculus Rift --- but only when Rhino is in fullscreen mode, with the command 'Fullscreen'. The placement needs to be tweaked, but should work.
If you want to use your own model, you can load your own .3dm file in Rhino, then you can right-click on the viewport name, and go to Viewport Layout > Read from File. If you then load my test file, Rhino should open my two viewports, sized correctly, onto your model.
The placement of these viewports need to be tweaked; if you find a better viewport layout, upload an empty Rhino file with your viewports, and we can share eye-layout 'templates'!
5) In Grasshopper, open the .ghx definition. Everything that is multiple-grouped is a value that can be changed. Two things here:
- IPD: Set this and convert it to the proper units for your model.
- Left/right viewport names. In this case, leave this as-is, since you're using my example file.
6) Turn on the Grasshopper Timer, if it isn't on already.
7) In the GH definition, toggle 'SyncEyes' to be True. Then, in the left viewport, try orbiting around with the mouse. The 'RightEye' viewport should move around as well, pretty much simultaneously.
8) In OpenTrack, click 'Start', then toggle 'ReadUDP' to be True. You should see the 'OpenTrackInfo' panel fill with data that's constantly changing.
9) Move around the landscape with your camera, and when you set on a starting view that's ideal, click the triangle of the Data Dam component to 'store' the data.
10) Finally, toggle 'OculusMove' to be true. If all works correctly, both viewports should move based on the Rift's movement.
Let me know if you have any problems!
Cheers,
Dan…
Added by Dan Taeyoung at 11:47pm on December 10, 2013
. From the Thermal Comfort Indices component, Comfort Index 11 (TCI-11):MRT = f(Ta, Tground, Rprim, e)
with:- Ta = DryBulbTemperature coming from ImportEPW component- Tground = f(Ta, N) where N comes from totalSkyCover input. Tground influences the long-wave radiation emitted by the ground in the MRT calculation.- Rprim defined as solar radiation absorbed by nude man = f(Kglob, hS1, ac)- ac is the clothingAlbedo in % (bodyCharacteristics input)- I can't find any definition in the code of Kglob and hS1. Could you tell me please what are those values referencered to? --> probably the globalHorizontalRadiation but how?- e = vapour pressure calculated from Ta and Relative Humidity input
Do you agree that in this case the MRT does not depend on these inputs: location, meanRadiantTemperature, dewPointTemperature and wind speed?It does not depend neither on the other bodyCharacteristics like bodyPosture, age, sex, met, activityDuration...?
MRT calculated by the TCI-11 method is the mean radiant temperature of a vector pointing vertically with a sky view factor of 100%?For ParisOrly epw,
2. From the SolarAdjustedTemperature component (that seems to be more used for the UTCI calculation examples on Hydra compared to TCI-11).
In contrast to the TCI-11, this component distinguishes diffuse and direct radiation and contextualizes the calculation thanks to _ContextShading input, right? It can also be applied to a mannequin thanks to the CumSkyMatrix and thus evaluate the dishomogeneity of radiation exposure.This component seems not to consider the influence of vapour pressure on the result --> is it then more precise to put the MRT output (from the TCI) as an input of meanRadTemperature for SolarAdjustedTemperature?The default groundReflectivity is set to 0.25 --> is GroundReflectivity taken into account in the Tground or MRT calculation in the TCI component? If yes, what is the hypothesised groundReflectivity?The default clothing albedo of 37% (TCI-11 bodyCharacteristics) corresponds to Clothing Absorptivity of 63%?
If the CumSkyMatrix input is not supplied, I get 9 results for the mannequin --> where are those points/results coming from?
If the CumSkyMatrix input is supplied,I suppose the calculation of the 482 results correspond to a calculation method similar to the radiation analysis component that is averaged over the analysis period. Right?But I don't understand why the mannequin is composed of 481 faces and meshFaceResult gives 482 results.
Finally, what is the link between the MESH results, the solarAdjustedMRT and the Effective Radiant field ? Is there a paper to have a detailed explanation of the method?
3. Here are some results for the ParisOrly energyplus weather data. You can find here attached the grasshopper definition.There is no shading in this simulation and the result coming from the ThermalComfort indices for MRT is very different compared to the solar adjusted MRT.Why such a big difference and which of the result should be plugged into the UTCI calculation component?
Results for ParisOrly.epwM,D,H:1,1,12
Ta : 6.5°Crh: 100%globalHorizontalRadiation: 54 Wh/m2totalSkyCover: 10MRT (TCI-11): 1.2°C
_CumSkyMtxOrDirNormRad = directNormalRadiation : 0 Wh/m2diffuseHorizontalRad: 54 Wh/m2_meanRadTemp = TasolarAdjustedMRT: 10.64°CMRTDelta: 4.14°C
_CumSkyMtxOrDirNormRad = CumulativeSkyMtxdiffuseHorizontalRad: 54 Wh/m2_meanRadTemp = TasolarAdjustedMRT: 10.47°CMRTDelta: 3.97°C
_CumSkyMtxOrDirNormRad = CumulativeSkyMtxdiffuseHorizontalRad: 54 Wh/m2_meanRadTemp = MRT (TCI-11)solarAdjustedMRT: 5.17°CMRTDelta: 3.97°C
Thanks a lot for your helpRegards,
Aymeric
…
what they really mean by that, as in what buttons to push, so I assume it's a Windows Path entry?
2.) Modify PATH
Add the install location on the path, this is usually: C:\Program File\IronPython 2.7
But on 64-bit Windows systems it is: C:\Program File (x86)\IronPython 2.7
As a check, open a Windows command prompt and go to a directory (which is not the above) and type:
> ipy -V PythonContext 2.7.0.40 on .NET 4.0.30319.225
Tutorial on setting a Windows environmental variable (path):
http://www.computerhope.com/issues/ch000549.htm
But this fails to point out that path contains many entries already separated by semicolons so if I merely add a new variable called "path" it's likely that I will destroy existing program function. There's no info on how to just tack on another entry, and the Windows 7 edit box doesn't even show the whole collection, but one item (!), so I copied the existing path into a text editor to see the whole collection successfully and added the C:\Program Files (x86)\IronPython 2.7 entry after an added semicolon, correcting for an Enthought page typo of no 's' on the end of "Program Files". I also checked the others and many pointed to old missing directories so I deleted those entries.
...and the test fails and "ipy" is not recognized as a command, even though the path now shows up using "path" in the Windows CMD window, that is if I copy all by right clicking and pasting the stuff into a text editor to really view it all. I can run it from the source directory just fine.
The rabbit hole was indeed deep. Using the Task Manager (control-alt-delete) to kill Explorer and then Run in the menu to restart "Explorer," along with restarting the Windows CMD window however, worked. I can now invoke Iron Python ("ipy") via command line from any directory. For the "path" I edited path in the System Variables and not the User Variables. No, you don't have to type that whole crazy line above just to test the path variable, just "ipy" (and control-Z to quite IronPython) in the CMD window invoked by typing "cmd" into the Start menu search box.
From the CMD line this step did work fine:
3.) ironpkg
Bootstrap ironpkg, which is a package install manager for binary (egg based) Python packages. Download ironpkg-1.0.0.py and type:
> ipy ironpkg-1.0.0.py --install
Now the ironpkg command should be available:
> ironpkg -h(some useful help text is displayed here)
But of course Step 4 fails, giving pages of what seem to be error messages;
C:\Users\Nik>ironpkg scipy
Traceback (most recent call last):
File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\enstaller\utils.
py", line 92, in write_data_from_url
File "C:\Program Files (x86)\IronPython 2.7\Lib\urllib2.py", line 126, in urlo
pen
File "C:\Program Files (x86)\IronPython 2.7\Lib\urllib2.py", line 397, in open
File "C:\Program Files (x86)\IronPython 2.7\Lib\urllib2.py", line 509, in http
_response
...
Why can't I just download Numpy as a normal file and thus also have it easy for other users to install it when they use my scripts? This is just crazy and lazy. The Enthought developer has turned this into a computer game, with a missing registration link and then the last step spits out errors with utterly no information on how to fix it manually.
This Step 4 error is covered here:
http://discourse.mcneel.com/t/trying-to-import-numpy-in-rhino-python-but-im-getting-this-error-cannot-import-multiarray-from-numpy-core/12912/16…
Added by Nik Willmore at 2:36pm on October 11, 2015
he example file to this file so you can give it a try with any version of Honeybee that you're already using. The only requirement is to have OpenStudio installed as the component is using OpenStudio libraries to parse gbXML files. If you're using the latest version available on github the component is also available under WIP tab.
Why?
The main purpose of developing this component is to save time and effort for importing Revit models for energy and daylight analysis. It bothers me to see a lot of smart people spend a lot of time to just come up with solutions just to get the geometry from Revit to Honeybee for analysis. This component is not solving all the issue but is a first step forward. In an ideal world, the future version of Honeybee, which works both under DynamoBIM and Grasshopper should address this issue but that can take some time to be fully ready!
How?
To use this component you need to Export your Revit model as gbXML and then use the file path to load the file into Grasshopper. There are several resources available online on how to prepare the analytical model in Revit and export the gbXML file. Here is an image for importing the Revit 2017 sample model using the default settings. As you can see the model will be just as good as what your original gbXML file from Revit is.
What can be improved?
Well, there are several items that can be improved and they are mostly not on us. To get it started I add what I think are the 3 main shortcomings and my thoughts on how they can be addressed in the future. Feel free to add what you think needs to be added to this list in the comments section.
1. Revit analytical models and as the results gbXML files, by design, are not intended to be clean. Watch this presentation from the Autodesk University to see the logic behind this approach which in short is it doesn't matter for a large scale early stage energy model. Well, This will be quite a problem for studies that you can do with Honeybee. Included but not limited to daylight and comfort analysis.
The best solution that I can think of, until Autodesk fixes their exporter, is to use Revit Rooms and Spaces and generate a clean model from the scratch. We have already tried this approach in Revit but since the Revit API doesn't provide access to Room openings we had a very hard time to get it to work.
That's why that I opened an idea on Revit ideas to get over this issue. With your support we already have 81 votes, but it hasn't been enough to make them to consider the idea for an official review. If you haven't voted already and you think this will be a helpful feature take a moment and vote so we can have it implemented at some point in the future.
2. There is no way (that I know) to export only part of the model. The way export gbXML is set up in Revit is to export the whole model once together. As a result, if you have a huge model with 100 rooms and you want to get one of the rooms into Honeybee using this component you have to export the whole model, which can take some time, and then import them all back into Grasshopper. To partially address this issue I added an input to the component that allows you input a list of names for rooms that you're interested to be loaded into Grasshopper. You can use the name of the room/space in Revit as an input for the component.
3. The component doesn't import adjacencies, loads, schedules and HVAC systems. I wasn't able to export a gbXML file from Revit with any of this data except for the adjacency, but even if you can do that, the component currently can only import geometries and constructions. I hope we get access to 1 and so we don't have to use the xml file approach at all, but if that takes a very long time then we will add these features to the component.
Happy 2017!
Mostapha…
le and grasshopper timer to simplify simulation control. Double click the main Kangaroo component to open this remote. There are buttons for Stop(reset), Play, Pause, and Step (moves the simulation forward one iteration).
Line-line force - allows interaction between line segments - they are treated as rigid cylinders. As with springs, there are settings for offset and rest distance, so this can be used to simulate colliding rods, and also for keeping cylinders tangent to one another (can be used for reciprocal structures).
Gear simulator - collision between curves in a plane, can be used for various mechanical simulations - cams, gears, rack and pinions etc.
Developablize force - adjusts vertices of a mesh locally, to make angles around each interior vertex sum to 2*Pi, so the mesh can be unfolded to a flat sheet without stretching.
Volume dependent pressure force - allows you to set a rest volume for a mesh instead of just a fixed pressure. When combined with Laplacian smoothing for area minimization, this can be used to optimize for CMC (constant-mean-curvature) surfaces. It will also work on open meshes.
Translation lock - maintains a fixed relationship between a pair of points. This can be used to enforce periodic boundary conditions for TPMS.
Equalize angles force - given a set of angles (defined by 3 points each), this tries to adjust them all to become equal.
Mirror symmetry force - can be used to minimize curvature variation, and optimize for higher order curve continuity. It can also be used for simulating torsional resistance in curved rods.
True minimal surface relaxation - Laplacian smoothing force now includes an option for cotangent weighting, which optimizes for zero mean curvature, unlike spring based methods, or uniform weighted Laplacian smoothing which only roughly approximate this.
Fast sphere collide - allows much faster collision detection between large numbers of spheres. By placing these spheres at the vertices, this can also be used for collision between meshes.
Force-density element - an experimental one, more on this later
Projected-force - adjusts its strength so the component of the force in a given direction stays constant.
New mesh tools:
WarpWeft - sorts the edges of a quad mesh into warp and weft directions. This can be used to assign them different stiffness in fabric form-finding.
Checkerboard - sort the faces of a mesh into 2 lists so that 2 faces of the same colour are never adjacent.
MeshDirection - sorts the vertices of a quad mesh to give it a sort of u-v directionality
Refine Strips - subdivision in one direction only - can be used to generate developable strips
Stripper - separates out the strips of quads from a larger mesh
Unroller - unfolds a quad strip to flat without stretching
MeshMap - maps points from one mesh to another (can be used together with circle-packing to generate conformal mappings)
Reciprocal structure - generates starting geometry for a reciprocal structure from any input mesh (using the Plankton mesh library *Note* If you already have the Plankton components installed, you will need to update to version 0.3.0, which is available from here)
ReMesher - adjusts the connectivity of a mesh by flipping, splitting and collapsing edges to make all edge lengths closer to a target value
Diagonalize - creates a new face for every edge of the original mesh. Can be used on quad meshes to easily convert to a diagrid.
Refine - simple non-smoothing subdivision, splitting quads into 4 quads, and triangles into 4 triangles
QuadDivide - subdivide quads by any number squared, not just powers of 4
Corners - finds the corner vertices of a quad mesh
ByParent - simple quad subdivision, keeping the output grouped by parent face.
User objects:
The download comes with an increased collection of user objects to simplify setting up common simulation types - Including a simple to use origami simulator, a reciprocal structure generator, and a tool to generate compact circle packings from a CP mesh.
General:
Geometry input now accepts polylines and straight curves.
Hinges can now be fold completely flat in both directions.
Various other minor bug fixes and speed improvements (including much faster removeDuplicatePoints/Lines components)
*****
I've not yet updated all the documentation and example files to reflect this new version, but over time I will keep posting here with new demos and explanation of all these new features. I'll try and add a few new examples each week. Vote in the comments below if there is a feature mentioned above that you're particularly keen to hear more about soon.
No doubt there are still some bugs to be discovered. If something isn't working the way you expect or want it to, please post in this forum (ideally with a description or sketch of what you think should be happening, and a clear description of what happens instead and any error messages).
There are also some more new features that weren't quite ready to make it into this release, but are on the way shortly...
Kangaroo remains completely free, for personal, academic, and commercial use. I'm always interested to hear about projects done using it, and suggestions for improvements or additions.
Daniel
…
r." I'm sorry to hear that, I take the interface and ease-of-use rather seriously so this sounds like a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative."What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design."Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it."[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Visual Programming.I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
Context sensitivity."There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them."Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal this time around is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
Sliders."I think they should be optional."They are optional."The “N” should turn into the number if set."What if you assign more than one integer? I think I'd rather see a component with inputs 'N', 'P' and 'X' rather than '5', '8' and '35.7', but I concede that is a personal preference."But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly."Agreed.
Components."Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings."I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data."Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
Integration."Why isn't it just live geometry?"This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry."Maybe add more Rhino functionality to GH. GH has no 3D offset."That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
Documentation.Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
2D-ness."I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
Organisation.Agreed. We need to come up with better ways to organise, document, version, share and simplify GH files. GH1 UI is ok for small projects (<100 components) but can't handle more complexity.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
david@mcneel.com…
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
…
is also takes place in own system. However, this action can be also carried out successfully by a foreign reference, if this considers the focused system as own. Hence, these two criteria are considered in my reflexions, to make your criticism handier for me.
First the question must be put up, how is it in your case? Of friendly manner you answer this question perpetually with the statement that you are not a partial of the system of the architecture.
Furthermore the question would be appropriate, whether an external reference (eg CAD) determined architecture. This can be answered with no, because determining and influencing are different things.
Because you stress now your criticism as a foreign criticism, within the architecture the assuption must be put up, that this criticism is not unusual new on the one hand (because this condition were also in other times like that, and presumably also always so remain) and further more a lack of goodwill in your criticism comes to light, which perhaps distinguishes an external reference.
Based on your critique, it would be also desirable in the system of the architecture if the academic rules become satisfyingly followed, even if this is no guarantor for good academic works. Nevertheless, there is an aspect which at least tolerates the evident lack in the Interdiziplinarität of the architecture. This is the classical and still valid determination of the architecture, presumably regulates not only the actions of the architects, but also those who want to become it.
Many who stand in your criticism (the students, as well as the teachers, ... ), live in the awareness that architecture is a profession that combines as many areas around the topic of Building, and the architect is even only one dilettante among the external specialists. In this determination dilettantism is revalued rather positively, because this state the architects enables to assess the facets of a complicated building project better and to form thereby the whole result positively. To be a good architect, you should have circumspect specialists around yourself. And exactly this knows the system of the architecture, because "THE ARCHITECT" helps himself with the logic of other systems (to repair on the one hand his own deficits), and to create an artificial complexity, which ultimately aims to be the complexity of human beeing.
Here "THE ARCHITECTS" becomes a quality-spoken, which currently seems the external reference (CAD, BIM) would like to take claim for themselves.
........
If would not thought about it, this might be helpful:http://www.amazon.com/The-Alphabet-Algorithm-Writing-Architecture/dp/0262515806/ref=sr_1_1?ie=UTF8&qid=1376920450&sr=8-1&keywords=mario+carpo"Finally, I’d like to restate my criticisms in general terms. If we are serious about moving architecture and urbanism away from purely artistic considerations and into a more rational arena, there has never been a better time than now. All of us have access to immense computational power which can be applied to problems that have been —until quite recently— intractable. But of course the garbage-in-garbage-out adage holds true; computation can be used to generate large amounts of complexity, but complexity does not equal worth. The only time when it makes sense to invoke computation in the design process is when there is some relevant data that needs to be computed" (David Rutton)I want to make it short, and just ask a few questions, and hope that the following questions are relevant also for you, and not be considered outside your system. i think that the weighting to such questions seem to be more valuable, not for the architects.1. What is wrong from a pure artistic intention?2. What is any sense in purely architectural discourse?3. strictly looked, can be determined sense generally in a purely architectural discourse?4. What is purely architectural discourse?5. What is Funktionalismus or Rationalismus without philosophical support? 6. Would not be the pure functional fulfilment empty ? 7. Would be not a critical position on the promise of purely rational algorithms applied?…
ust assume this is really what is being imported with the standard import line I see in all the examples:
# scriptcontext moduleimport RhinoPython.Host as __host'''The Active Rhino document (Rhino.RhinoDoc in RhinoCommon) while a scriptis executing. This variable is set by Rhino before the exection of every script.'''doc = None'''Identifies how the script is currently executing1 = running as standard python script2 = running inside grasshopper component3... potential other locations where script could be running'''id = 1'''A dictionary of values that can be reused between execution of scripts'''sticky = dict()def escape_test( throw_exception=True, reset=False ): "Tests to see if the user has pressed the escape key" rc = __host.EscapePressed(reset) if rc and throw_exception: raise Exception('escape key pressed') return rc def errorhandler(): ''' The default error handler called by functions in the rhinoscript package. If you want to have your own predefined function called instead of errorhandler, replace the scriptcontext.errorhandler value ''' return None…
Added by Nik Willmore at 7:47pm on October 10, 2015
eather data so it cannot be easily compared to Archsim. My account of the differences between Honeybee and Archsim will be far from complete but here are the key ones that I am aware of:
1) This difference is a bit of a superficial one but points to a deeper thinking about how the software should be used. Honeybee has many more components than Archsim, which means that Honeybee has a steeper learning curve than Archsim and will take longer to master. Along with this, you may also encounter a general mentality in the Honeybee community that "you should not be running a certain type of simulation unless you know how it works" whereas I know that Archsim is a bit more amenable to making things fast and easy to set up even when you are not sure what is going on under the hood. However, as a result of the large number of components in Honeybee, it is more open-ended, customizable, and includes more freedom in terms of cases that you can run and the parameters of the energy simulation that you can change than Archsim. You will also notice that, while there is a general ethos in the Honeybee community that you should not be running certain simulations unless you know what you are doing, we try to provide you with many resources to educate yourself if you are motivated. For example, we have long component descriptions that we assemble into documentation books like this (https://www.gitbook.com/book/mostapharoudsari/honeybee-primer/details), hours of video tutorial playlist like this one (https://www.youtube.com/playlist?list=PLruLh1AdY-SgW4uDtNSMLeiUmA8YXEHT_), and many GH example files on a github-based file sharing system (https://hydrashare.github.io/hydra/index.html). Not to mention a community of people who would respond to discussions like this one.
2) Archsim as a standalone application will soon be no more and will be instead distributed with the DIVA daylight analysis tool (http://diva4rhino.com/). While I am unclear on the exact trajectory of DIVA, it currently has a price tag attached to it and so I would assume that the future of Archsim will also carry this price tag. On the other hand, Honeybee and any derivative software will forever be free and open source under the GPL licence (https://github.com/mostaphaRoudsari/Honeybee/blob/master/License_Honeybee_GPL.txt).
3) This third point is a bit of a reiteration of the last one but Honeybee is open source, meaning that, if you need a feature of EnergyPlus that is not yet implemented on either interface, you can usually add it in yourself with a few lines of python code in Honeybee. This type of workflow is not possible with Archsim since it is closed source and requires you to use EnergyPlus's text editor interface after Archsim has exported an IDF in order to implement any additional EnerygPlus features.
4) The libraries and templates for Honeybee come from OpenStudio - the open source interface for EnergyPlus (https://www.openstudio.net/), which is supported by the US Department of Energy (just like EnergyPlus). Since Honeybee is open source, it is able to make use of the large database of building type schedules/loads and constructions that have been assembled by the OpenStudio team over the last several years as well as OpenStudio's SDK. I can also say that almost all of the development efforts of the Honeybee team are now focused now on integrating efforts with OpenStudio, including an exporter from Honeybee to OpenStudio that should be fully functional for the next stable release. I am not certain of the current extent of Archsim's libraries but, last I had checked, the creator was pulling them from his own experience and, as such, only had a few libraries to choose from. For all of my knowledge, through, this may be changing with the integration of Archsim with DIVA.
Let me know if this is helpful and, if anyone has more up-to-date knowledge on Archsim than I, please post there.
-Chris…