f geometry in the scene, everything still runs fairly seamlessly (I built my computer with top-of-the-line specs -- back in 2010 -- so any computer with competent hardware should run this just fine).
In addition to improved flying controls, I implemented a script that lets the user select geometry on the screen just by pointing (1:16). The geometry gets highlighted via Grasshopper first, and then after a certain amount of time it gets selected in the Rhino window (with a little help from a custom script by Andrew Heumann). The camera then resizes to fit the selected geometry.
Haven't quite decided where I want to take this, but now that it's cleaned up it should be easy to implement other gestural controls. Think I might just play around with other Leap apps to see which set of controls I like best...Suggestions are welcome. =)
Again, couldn't have done it without Andy Payne's Firefly components and Jacek Markusiewicz's Horster Camera Control.…
Added by Scott Penman at 12:41am on December 20, 2013
o: http://github.com/HeinzBenjamin/FlexCLI/issues
Download
You can find FlexHopper here:
http://www.food4rhino.com/app/flexhopper
and here:
https://github.com/HeinzBenjamin/FlexCLI
Info
FlexHopper offers physics computation in Grasshopper. It is GPU-based and therefor very fast. Currently supported modes of simulation are: free particles, fluids, rigid bodies, soft bodies, tensile structures and cloth, custom constraints.
FlexHopper is a Grasshopper plugin built on top of FlexCLI - Flex Common Language Interface. FlexCLI is built against NVidia Flex release 1.1.0. NVidia Flex is patented property of NVidia. FlexCLI and FlexHopper are openly accessible under the GNU License through my Github account. (Link above)
For more information on NVidia Flex go here: https://developer.nvidia.com/flex and https://developer.nvidia.com/nvidia-flex-110-released
FlexCLI runs on x64 architectures only. It was built against .Net 4.5.2
FlexHopper was tested with Rhino5 64bit and Grasshopper 0.9.0076 WIP
Requirements
Windows 7, 8, 8.1 or 10 64bit
NVidia or AMD Graphics Card
NVIDIA: GeForce Game Ready Driver 372.90 or above
AMD: Radeon Software Version 16.9.1 or above…
he model (or more accurately: some "variant" of the model) and the validation.
Additionally IF the "variant" consists from real-life 3d components (say: real nodes, rods, connecting plates, nuts, bolts etc etc) ... well this IS not an easy-busy thing and NOT a task for a beginner in scripting.
Additionally IF the "variant" consists from real-life parametric 3d components (i.e. feature driven as is the norm in real-life AEC cases) ... well ... you are looking at the entirely wrong apps (GH/Rhino).
Hard to recommend where to start: too many topics to cover ... the "least" important of them is been expert in, say, C# (avoid Python on these matters especially having in mind the available resources in C#).
Anyway post some sketch outlining the thing that you have in mind (is it abstract? [lines, points etc]), has some "real-life" 3d geometry AND components? is it structured the proper way? [assembly/component disciplines and the likes]). And given the immediate future (look what happens in UK [BIM becomes obligatory] for example): do you have some BIM umbrella in mind for the whole project?
BTW: Light-weight optimization using Galapagos? In what sense? You mean Kangaroo I do hope.…
ess more memory on 64 bits. So you can load larger files and generate more data.
Every time you store something in memory it has to be stored at a specific location. We call this location an address. The first thing you store can be stored at address 0*. If that thing requires a total of 18 bytes, then addresses 0 through 17 are used up. The next thing you store can then be stored at address 18. And so on and so forth. At some point you run out of addresses and when that happens there is no more room to store any new data and there is thus nothing more that your app can do and that's usually when Windows shoots the application in the head and buries the remains behind the chemical sheds.
The total number of unique addresses that can be represented by a 32-bit integer is 4,294,967,295 (4 GigaByte). However Windows only allows a 32-bit app to access 2GB, or potentially 3GB if a special switch is set. A 64-bit application is allowed to use 64-bit integers to identify memory addresses, which means the highest possible address is now 18,446,744,073,709,551,616 (or 18.45 ExaBytes). Basically, as long as you have RAM to back you up, a 64-bit application will not run out of memory. Of course it may still become prohibitively slow as a lot of data requires a lot of computation and 64-bitness does absolutely nothing to make things go faster.
--
David Rutten
david@mcneel.com
Vienna, Austria
* Not true in reality, Windows will already use up some of the available memory just to load the application.…
Added by David Rutten at 1:39pm on November 2, 2012
->Components Folder" folder.
In that case download it from food4rhino.
OR
2) There is, but it has been blocked.
In that case:Right click on the ghpython.gha file, and choose "Properties". If there is an "Unblock" button click on it, and then click on "OK". If there is no "Unblock" button, just click on "OK".
After completion of either of these two steps, close Rhino and Grasshopper, and run them again.
Let us know if worked.
On creation of buildings: Gismo will generate 3d buildings by extracting the height or number of stories data from .osm file.
The user itself does not need to do this manually.…
Added by djordje to Gismo at 12:56pm on February 7, 2018
basic code:
Rhino5Application rhino_app = new Rhino5Application(); rhino_app.Visible = 1; rhino_app.RunScript("_Grasshopper", 0); dynamic grasshopper = rhino_app.GetPlugInObject("b45a29b1-4343-4035-989e-044e8580d9cf", "00000000-0000-0000-0000-000000000000") as dynamic; grasshopper.OpenDocument(@"C:\Temp\test1.ghx"); bool asignRes = grasshopper.AssignDataToParameter("Num", (Object)0.5); grasshopper.RunSolver(true);
On the 0.9.0006 version the asignRes gets "false" (and does not change the param of-course) while on 0.8.0066 asignRes gets "true" and everything works fine.
Am I doing something wrong? Did GH automation change? Is it a bug in 0.9.0006 ?
I added the file test1.ghx but its really trivial :)…
rella - Revit/AECOSim etc etc) then scripting is the only way to do business. In fact Dynamo/Generative Components would be your main parametric app ... but GH can offer a thing or two as well.
Other than that here's a very brief explanation upon the "steps":
1. Using connectivity trees (faces to edges, edges to faces, faces to faces) ...
2. ... Find the "internal" edges (meaning edges that are connected to more than ONE face) and store them in a tree. Doing this find the smallest edge as well (for defining the "module" of the pts divisions minus the start/end offset). Used an object type tree since I store the indices of the adjacent faces as well (an object type is a "general" container that can hold cats, dogs, numbers, bananas etc etc ... with the cost of un-boxing when an item is to be used [Note: un-boxing costs time but in this very simple case we can afford the "luxury"]).
NOTE: if you observe the paths on that tree you'll notice that they correspond 1:1 to the indices of the related edges in the EList List (of type Curve).
3. Loop withing the "interior" edges and define the coplanar vectors per edge related with the 2 adjacent faces. These vectors are the Cross Product (Google that) between the edge direction and the normal per face (at u/v: 0,0). Divide the edge (taking into account the start offset AND the ratio of the edge length/ minEdge [as derived from phase 2 as above]). Using these points create a "zing-zag" polyline and store it in the same path as the OEM edge.
NOTE: The polyline is not planar since each teeth is laying to the corresponding adjacent face plane (if the Brep Faces are not planar more "smart" stuff is required).
From this point (not included in V1):
4. Using Face to Edge connectivity data: IF a path exists (in the polyline tree as in 3 above) with the given index sample this polyline as Curve ... if not get the OEM Curve (case: "boundary"/perimeter Brep Faces). Join the Curves (take provision to report failures) and project them to the corresponding Brep Face plane (case: planar face) or ... to some suitable "mean" plane. Define a planar Brep out of the newly created closed planar Curve and extrude it (actually the Brep Face of it) both sides at once for doing a "solid". If Brep Faces are not planar ... well things are a bit more complicated (not nuclear science ... just another approach is required).
In fact ... is a bit more challenging than that since there's assembly tolerance AND clash issues around ... but this is the "general" idea anyway. …
ave the bytes available, they also need to be adjacent. All 4 frikkin trillion of them (assuming you need a million 1000x1000 pixel tiles). That's just not going to happen.
It could be that Photoshop has very clever memory management that allows it to store image data in non-consecutive chunks, but .NET does not allow this.
In fact this can be a real problem with much smaller images as well. In 32-bit Windows you're allowed 2GB of memory per application (sometimes 3). If Rhino+Grasshopper are already using up 1.5GB it's not like you can fit in an extra 0.5GB image before running into problems. Memory is almost never used in a consecutive fashion.
Rhino uses a clever memory manager (not the default Windows one) that results in less memory fragmentation and Grasshopper uses the .NET memory allocator and garbage collector which is capable of defragmenting memory usage. But even with these two optimizations memory fragmentation will occur (and the longer Rhino runs the worse it will get) making it less and less likely that you'll be able to find large consecutive areas of free memory.
The Grasshopper hi-res image exporter creates image tiles of 1000x1000 pixels and saves these files immediately. So it never requires more than 4MB while running. Once it's done making the images, it will start a different application that will stitch these images together. That's what the GrasshopperImageStitcher.exe in your screenshot is. Since this is a new app, it has 2GB of absolutely pristine memory to play with so it's a lot longer before it runs into problems. And when it does run into memory problems it won't bring down Rhino with it.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
cle
the 'Shape' is copied to all points
shapes are rotated randomly, plus or minus 'Angle' maximum
'Shape In Brep (ShapeIn)' is used to cull shapes that aren't within the circle
'Fast Loop' begins using 'MCX' (Multiple Curves Intersection)
first shape is added to 'D1' output and shapes intersecting it are culled
results minus first shape are passed to 'D0' of 'FastLoopEnd'
loop repeats until 'D0' list is empty
'D1' results are scaled down slightly (0.75) to leave more space around them
'Explode' results and return only the curved part, ignoring the base line that closes the shape
…
Added by Joseph Oster at 11:01pm on March 17, 2017
which almost works...
I have 5 integer values in one string:
- When my input is the string "(25,0,0,0,175)" it is not assigned at all
- when my input is the string "25,0,0,0,175" it is assigned as 25000175 :)
- when my input is the string "25|0|0|0|175" it is assigned as 191 which is completely confusing :)
Can anyone point me into correct syntax of input string to be correctly parsed as a set of integers? I'm accessing Rhino+GH from external app so I can format the input in any appropriate way, yet I cannot directly modify the GH script that uses these Integer Parameters as a way to handle input.
Regards,
Boris…