al other things:1. the minimum and maximum spacing between points (a certain 'x' and 'y');2. the jump between two next points - let's say it is always 2. So if a minimum possible spacing is 'x' (pt.1) then the next one would be x+2, then x+4, x+6 etc. until it gets to x+n=y (the maximum);3. how many maximum/minimum points there are in a row - when a division reaches the minimum 'x' or maximum 'y distance I want it to stay there for a while (e.g. [...] x+(n-2), x+n=y, y, y, y, y, x+(n-2), x+(n-4)...) Therefore, what I want to get after dividing the base curve are curve pieces of following lenghts/points on the curve with following distances between them (for example):x, x, x, x+2, x+4, x+8 . . . x+n, y, y, y, y, y, x+n . . . x+4, x+2, x, x, x, x, x, x, x, x+2, x+4 . . . x+n, y, y, y, x+n . . . x-2, x, x, x, x, x-2 . . . and so on and on.As you can see the amounts of x's and y's in a row changes (Rule no.3).I've tried this with graphs and attractor points and got nowhere in almost 2 weeks (though I'm a beginner).. Perhaps someone here will have an idea :)I'm attaching a picture of what I have in mind (may be easier to understand than what I wrote for some people :))Cheers…
R_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh SET DOCKER_TLS_VERIFY=1&SET DOCKER_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh SET DOCKER_TLS_VERIFY=1&SET DOCKER_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh SET DOCKER_TLS_VERIFY=1&SET DOCKER_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh SET DOCKER_TLS_VERIFY=1&SET DOCKER_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh SET DOCKER_TLS_VERIFY=1&SET DOCKER_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh Butterfly is running blockMesh. PID: 1837 SET DOCKER_TLS_VERIFY=1&SET DOCKER_HOST=tcp://192.168.99.100:2376&SET DOCKER_CERT_PATH=C:\Users\akiwya\.docker\machine\machines\default&SET DOCKER_MACHINE_NAME=default&docker exec -i 4c9bb2f7444b pgrep snappyHexMesh
/*---------------------------------------------------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: v1612+ | | \\ / A nd | Web: www.OpenFOAM.com | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ Build : v1612+ Exec : blockMesh Date : May 22 2017 Time : 08:51:50 Host : "default" PID : 1837 Case : /home/ofuser/workingDir/butterfly/outdoor_airflow nProcs : 1 sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE). fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10) allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time
Creating block mesh from "/home/ofuser/workingDir/butterfly/outdoor_airflow/system/blockMeshDict" Creating block edges No non-planar block faces defined Creating topology blocks Creating topology patches
Creating block mesh topology
Check topology
Basic statistics Number of internal faces : 0 Number of boundary faces : 6 Number of defined boundary faces : 6 Number of undefined boundary faces : 0 Checking patch -> block consistency
Creating block offsets Creating merge list .
Creating polyMesh from blockMesh Creating patches Creating cells new cannot satisfy memory request. This does not necessarily mean you have run out of virtual memory. It could be due to a stack violation caused by e.g. bad use of pointers or an out of date shared library Runtime error (PythonException):
Butterfly failed to run OpenFOAM command! new cannot satisfy memory request. This does not necessarily mean you have run out of virtual memory. It could be due to a stack violation caused by e.g. bad use of pointers or an out of date shared library Traceback: line 51, in script
I don't really have any knowledge in CFD simulation and only watched the tutorials and managed to get the sample files to work. So this time, I replaced the starting geometry my building which is a curve building, I wonder if that is the issue that caused this problem. Can anyone enlighten me on the issue?
Warm regards,
Annie…
.
If the above are correct then I am afraid there is no solid answer, data matching (how to modify 2 groups of data so that they work together) can be done in many ways and no one is suitable for every case.
For example in the [move] component in your definition you have the G input receiving 27 lists with 54 lines each (1458 lines) and you want to move these lines in Z direction. Depending on how you want to move them it could make sense to have T input receiving:
a. One vector (this would move all the lines by this vector)
b. 54 vectors (this would move the first line of each list by the first vector, the second line of each list by the second vector, ...... , the last line of each list by the last vector)
c. 27 vectors grafted so that the paths match (this would move the first list of lines by the first vector, the second list of lines by the second vector, ...... , the last list of lines by the last vector)
d. 27 lists with 54 vectors each (1458 vectors). This way each line will move by the corresponding vector.
So, as you can see there is not a global solution.
In order to be able to decide how to format your data you must always be aware of what your existing data structure means. For example, in the above case, you have your lines in the format {A;B;}N. Now A has 6 values (0 to 5) which is the number of your original surfaces. B has various values because it is the number of edges that each surface had(deconstruct Brep component). Finally N (the number of items in each list) is 54 because you offseted each edge 54 times (offset component).
So in order to decide which of the above cases suits you best you must have these things in mind.
In general some useful components for data matching are: [tree statistics] [list length] [repeat data] [graft] [simplify] and [flatten] and of course many more, depending on the case...
But in order to use these properly you must first study about data trees and how they work.....
Hope this helped a bit and please post back if you need some help into a specific part of your definition.…
ocessed once Grasshopper is done with whatever it's doing now.
3) Grasshopper tells the Slider object that the mouse moved and the slider works out the new value as implied by the new cursor position.
4) The slider then expires itself and its dependencies ([VB Step 1] in this case, but there can be any number of dependent objects).
5) When [VB Step 1] is expired by the slider, it will in turn expire its dependencies (VB Step 2), and so on, recursively until all indirect dependencies of the slider have been expired.
6) When the expiration shockwave has subsided, runtime control is returned to the slider object, which tells the parent document that stuff has changed and that a new solution is much sought after.
7) The Document class then iterates over all its objects (they are stored in View order, not from left to right), solving each one in turn. (Assuming the object needs solving, but since in your example ALL objects will be expired by a slider change, I shall assume that here).
8) It's hard to tell which object will get triggered first. You'd have to superimpose them in order to see which one is visually the bottom-most object, but let's assume for purposes of completeness that it's the [VB Step 1] object which is solved first.
9) [VB Step 1] is triggered by the document, which causes it to collect all the input data.
10) The input parameter [x] is asked to collect all its data, which in turn will trigger the Slider to solve itself (it got expired in step 4 remember?). This is not a tricky operation, it merely copies the slider value into the slider data structure and shouts "DONE!".
11) [x] then collects the number, stores it into its own data structure and returns priority to the [VB Step 1] object.
12) [VB Step 1] now has sufficient data to get started, so it will trigger the script inside of it. When the script completes, the component is all ready and it will tell the parent document it can move on to the next object (the iteration loop from step 7).
13) Let us assume that the slider object is next on the list, but since it has already been solved (it was solved because [VB Step 1] needed the value) it can be skipped right away, which leaves us with the last object in the document which is still unsolved.
14) [VB Step 2] will be triggered by the document in very much the same way as [VB Step 1] was triggered in step 9. It will also start by collecting all input data.
15) Since all the input data for [VB Step 2] is either defined locally or provided by an object which has already been solved, this process is now swift and simple.
16) Upon collecting all data and running the user script, the component will surrender priority and the document becomes active again.
17) The document triggers a redraw of the Grasshopper Canvas and the Rhino viewports and then surrenders priority again and so on and so forth all the way up the hierarchy until Grasshopper becomes idle again.
[end boring]
Pretty involved for a small 3-component setup, but there you have it.
To answer somewhat more directly your questions:
- The order in which objects are solved is the same as the order in which they are drawn. This is only the case at present, this behaviour may change in the future.
- Adding a delay will not solve anything, since the execution of all components is serial, not parallel. Adding a delay simply means putting everything on hold for N milliseconds.
- [VB Step 1] MUST be solved prior to [VB Step 2] because otherwise there'd be no data to travel from [GO] to [Activate]. The only tricky part here is that sometimes [VB Step 1] will be solved as part of the process of [VB Step 2], while at other times it may be solved purely on its own merits. This should not make a difference to you as it does not affect the order in which your scripts are called.
--
The Man from Scene 24…
Added by David Rutten at 4:43pm on December 10, 2009
ou will see all of the available components on a ribbon at once so there is no need to keep clicking drop down menus.
It's all about discoverability with GH. What if you're a beginner and don't know about the Create Facility (dbl click canvas) how can you find Extr?
Even if you hover over every component or use the drop down lists you will not see the name Extr appear anywhere.
Sure it makes sense that Extr is short for Extrude but it's also the Nick Name of Extrude to Point component
So you can easily miss the fact that one has a Distance Input verses a Point Input.
I think I made the move to Icons around about the move from version 0.5 to 0.6, possibly before. I initially thought that I would go back to text because I loved the mono chromatic look of the text but I soon realised that Icons were the way forward. The greatest benefit is speed. You don't need to digest and decipher every component (which is written 90 degrees to the norm).
I'm not saying you should move to Icons forthwith but at least consider that once you have a better knowledge and understanding of GH, Icons will set you free.
My top ten tips that I would highly recommend to anyone wanting to better themselves with GH.
1) Turn on Draw Icons
2) Turn on Draw Fancy Wires
3) Turn on Obscure Components
4) Use the Create Facility like a Command Line eg "Slider=-1<0.75<2" or "Shiftlist=-1"
5) Use Component Aliases to customise your use of the Create Facility eg giving the Point XYZ component an alias of XYZ will bring it up as the first option on the Create Facility as opposed to the other possibilities.
6) Try to answer other people's questions even if it's not relevant to your own area. By looking into solving a problem outside of your comfort zone and then posting your results it is very rewarding but it also lets you see the other approaches that get posted in a new light.
7) Take the time to understand Data/Path structures.
8) Buy a second monitor - There is nothing that can compare to real estate when working in Grasshopper.
9) Read Rajaa Issa's Essential Mathematics
10) Pick a panel in a tab on the ribbon and get to know every component inside and out and then move on. Start with the Sets Tab > List Panel…
http://www.pilkington.com/) dominates the planar market. Charges "around" 1K Euros per m2 for a "plain" system. Personally in bespoke projects I design my own stuff but due to economies of scale ... they cost a bit more (but they look far more sexier, he he) . On the other hand only in a bespoke project I could dare to suggest such a solution (for a large scale building we are talking lots and lots of dollars).
3. Several scales below (aesthetics) you can find static alu systems (either structural or semi-structural):
Or hinged systems (either structural or semi-structural) capable to adapt in contemporary double curvature facades/roofs/envelopes/cats/dogs etc etc ... pioneered worldwide many years ago by my best friend Stefanos Tampakakis (everybody in UAE knows that genius man: http://www.alustet.gr/company.html):
4. With the exception of some paranoid things that Guru Stefanos does for Zaha these days we are talking about planar "facets" (obviously a triangle is such a planar facet). The current trend is: the more edges the better (humans excel in vanity matters). But achieving planarity in, say, quads (like yours) it adds another "restriction" on what you are doing. Until recently Evolute Tools Pro was the only answer. But right now ... well let's say that in short time you'll be greatly surprised by some WOW things in this Noble Forum, he he.
5. MERO (and obviously custom systems) can adapt (at almost no extra charge) in anything imaginable. But in a bespoke building ... well.. you know ultra rich people: they don't want MERO anymore since "everybody" does MERO solutions. Vanity, what else?
6. Smart Glass would become a must in the years to come: Eco-Architecture MUST dominate everything you do. On the other hand spending millions to do some extra WOW stuff (Vanity) ... it doesn't look to me very Eco-Friendly/Whatever ... but let's pretend so, he he.
7. I'm Architect but a bit different from the norm: for instance I smoke cigars (highly politically incorrect stuff) I always talk openly (ditto) and I ride lethal bikes (ditto).
may the Force (as always the Dark Option) be with you: go out there and kill them all.
best, Peter
…
Ladybug + Honeybee:
(Follow steps 0-4 for basic functionality and 0-9 for full functionality)
0. If you have an old version of LB+HB, download the file here (https://app.box.com/s/ds96em9l6stxpcw8kgtf)
and open it in Grasshopper to remove your old Ladybug and Honeybee version.
1. Make sure that you have a working copy of both Rhino and Grasshopper installed.
2. Open Rhino and type "Grasshopper" into the command line (without quotations). Wait for grasshopper to load.
3. Install GHPython 0.6.0.3 by downloading the file at this link (http://www.food4rhino.com/project/ghpython?ufh) and
drag the .gha file onto the Grasshopper canvas.
4. Select and drag all of the userObject files (downloaded with this instructions file) onto your Grasshopper canvas.
You should see Ladybug and Honeybee appear as tabs on the grasshopper tool bar.
(If you are reading this instruction on github you can download them from http://www.food4rhino.com/project/ladybug-honeybee)
5. Restart Rhino and Grasshopper. You now have a fully-functioning Ladybug. For Honeybee, continue to the following:
6. Install Radiance to C:\Radiance by downloading it from this link (https://github.com/NREL/Radiance/releases/download/4.2.2/radiance-4.2.2-win32.exe) and running the exe.
7. Install Daysim 4.0 for Windows to C:\DAYSIM by downloading it at this link (http://daysim.ning.com/page/download) and running the exe.
8. Install EnergyPlus 8.1 to C:\EnergyPlusV8-1-0 by going to the DOE website (http://apps1.eere.energy.gov/buildings/energyplus/energyplus_download.cfm), making an account, going to "download older
versions of EnergyPlus, selecting 8.1 and running the exe.
9. Copy falsecolor2.exe (http://pyrat.googlecode.com/files/falsecolor2.exe) and evalglare.exe (http://www.ise.fraunhofer.de/en/downloads-englisch/software/evalglare_windows.zip/at_download/file) to C:\Radiance\bin
10. You now have a fully-working version of Ladybug + Honeybee. Get started visualizing weather data with these video tutorials (https://www.youtube.com/playlist?list=PLruLh1AdY-Sj_XGz3kzHUoWmpWDXNep1O).
After I've done all the above I followed this video
https://vimeo.com/96155674
And everything works well.
…
nted" in space (at instance definition creation phase): indicates the obvious fact that if garbage in > garbage out (try it).
2. Load the GH thing. Task for you: Using Named Views locate the points of interest as described further and make a suitable view. That way you can navigate rather easily around (hope dies last).
3. Your attractors are controlled from here:
The slider in blue picks some attractor to play with. You can use this while the K2 is running.
4. Don't change anything here (think of it as a black box: who cares how it works? nobody actually):
5. Enable the other "black box": job done your real-life stuff is placed:
6. Enable the solver: your "real-life" things start to bounce around:
7. Go there are play with the slider. A different attractor yields an other solution:
8. With real-life things in place if you disable the C# ... they are instantly deleted and you are back in lines/points and the likes:
9. Either with instance definitions or Lines/points change ... er ... hmm ... these "simple" parameters and discover the truth out there:
10. Since these are a "few" and they affect the simulation with a variety of ways ... we need a "self calibrating" system: some mini big Brother that does the job for us. Kinda like applying safely the brakes when it rains (I hate ABS mind).
NOTE: the rod with springs requires some additional code ,more (that deals with NESTED instance definitions) in order to (b) bounce as a whole and at the same time (b) elongates or shrinks a bit.
More soon.
…
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