ign to every location in the space is the result of the fall-off equation. F/D² in the Metaball componenty, where D is the distance from the point to the location you're measuring and F is the scaling factor:
3) You repeat this for all the points, giving you a collection of revolved hyperbola:
4) Add the elevations for all hyperbolas together, just a simple A+B+C process:
5) You intersect this final landscape with a horizontal plane. The elevation of this plane corresponds with the iso-surface value. If we do it for a bunch of planes, you get the following result:
6) The interior of each slice represents the metaball, or rather the boundary of each slice:
That is the theory anyway, in order to actually get a speedy result the algorithm approaches the problem from a very different angle, but the result should be the same shape.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Rhino plugins to work in the mac version. As I understand it, what is holding up the GH making it over (fully) to the mac version is its dependence on the graphics libraries for Windows. There is no easy direct translation here, so, this is still under development. There is info spotted around the forum, you just need to dig deep enough to find it, and see that there is development of GH for Mac, but still, we should not hold our breath as there are significant hurdles to overcome. These hurdles are just technical, and should have a solution. Below are some references that point to the graphics issue I am discussing as well as a list from David where he does state that he is working on the Mac version.
Another positive note is that in Rhino 6, GH will be along for the ride...meaning (as I understand it) that we will not need to download GH after installation, it will be part of the Rhino install. I think this is a positive note as it means that GH will be more associated with the default Rhino experience, an experience which should carry over to the Mac version.
So, to sum up:
1. GH for Mac will probably happen.
2. Seems all of the code that does not depend on the graphic part (the logic in the components, Rhinocommon) already works in the mac.
3. Other Rhino plugins are already making their way to the Mac.
4. GH is becoming part of the default Rhino experience, and should probably carry over to the Mac experience.
5. Don't hold your breath. When it will happen is not under anyone's control necessarily. The solution needs to be practical in order for it to be rolled out.
My $0.02.
References:
http://www.grasshopper3d.com/forum/topics/partial-developer-absence?commentId=2985220%3AComment%3A929795&xg_source=activity
http://www.grasshopper3d.com/forum/topics/grasshopper-for-mac-update?xg_source=activity…
th a graphic editor (GH) hosted in a CAD app that has primitive assembly/component capabilities and/or feature driven ops (Rhino). Did I've mentioned that Rhino is a surface modeler? (meaning the obvious).
3. Imagine a "seed" collection of assemblies related with various membrane components made in SW. Say: geometry (prior solid ops) and parameters (the feature driven part of the equation, in most of cases managed with some RDBMS). You should port these to GH (a variety of ways exist for that) and create the bare minimum of "solids" in GH as instance definitions. There's 2 main reasons to do that: (a) effectively communicating back on an assemply/component schema (via STEP) and ... (b) achieving manageable collections when in GH. These are critical for clash detection (when outlining some topology in GH, therefore NEVER work just with "curves") and "variation" control of some sort (up to a point). Of course for high class designs (where the devil hides in the details) this is NOT the best imaginable solution ... you'll need CATIA for such an integrated (all in one) procedure. On the other hand many could (wrongly) argue that CATIA is expensive (rather naive argument if a company has a certain turnover).
4. So, in general I would strongly suggest to use instance definitions of items in some sort of "intermediate state" of detail (an 100% undoable task without code) structured in such a way (classic assembly/component MCAD mentality blah, blah) that SW could take benefit of a possible modified "base topology" and proceed by finishing variations of the given assembly (feature driven stuff as usual).
5. Then export (STEP 214) back portions of the assemblies (and parameters used) to R/GH if and when this is required (for instance for BIM disciplines ... but Rhino is not a BIM app, nor it would ever be).
6. If you are familiar with code matters ... start thinking the whole puzzle that way, if not my advise is to find someone to design such a "procedure" (say an "app") using solely code, but this is not a task for the inexperienced by any means.
best, Peter…
release.
2. Of course, I agree the support is woeful for this at present. Find attached an example of trying to find a completely new definition for a target geometry. Using galapagos with these inputs help the machine get quite close. Obviously, its a combinatorial problem so bloat is an issue.
3. It's a great idea, and a thought I've had on the todo list. It's trickier than you think though due to the way you have to instantiate a component on the canvas. In addition, persistent data in the ingredient components that exists in the generated ones is possible.
4. Again, yes options for the inputs is a good idea and one I'm working on.
5. Indeed. Ideally, you should be able to put clusters in the ingredients. This is where things start to get very tricky without the help of David :) . If I can get user objects to work, then that's a step in the right direction. At present, you need to compile new components to get Embryo to include them.
6. Because it was the easiest to implement with the gene pools. Revising this to make it more efficient is a good idea, because at the moment it aint.
7. Good idea. I can include that in the options component.
Finally, just to say implementation in Grasshopper has its pros and cons, it's obviously not built for this kind of thing. In the future, I'd like to build an independent plug-in for Rhino that will handle GP better.
Anyway, thanks for having a go! I still intend to make the repository public.
As to what I do, I used to lead the Ramboll Computational Design team in London but we've all gone our separate ways now. I'm now a lecturer in Computational Design at the University of West of England (UWE) in the UK.
…
file. A TSpline made thing in fact.
2. This atroci ... er ... hmm ... I mean unspeakable beauty uses an exo-skeletal load bearing structure hence is THAT big (BTW: Apparently nobody knows what thermal bridge is nor thermal expansion nor vapor condensation ... but these are "minor" details these holly blob days, he he).
3. 2 means that some nodes of that "grid" MUST "meet" floors in order to support them and (hopefully) withstand some seismic forces. BTW: A Richter scale 9 (for an hour) is all what this building actually needs (that's acid "humor").
4. The "smarter" way to do this is to spread "some" (i.e a lot) random points (Note: David's algo yields "evenly-spaced-points" within the limits of the possible) on the guide blob (a polysurface in fact).
5. Then ... you need some algo that tests proximity AND "adjusts" the Z in order to have some node points "co-planar" (Z) with the floors.
6. Then you triangulate all that stuff (the points, that is) using some decent Ball Pivot Algorithm (NOT Delauney) and you get a triangulated mesh that "engulfs" the guide blob. If you want some quads (as shown) this is also possible.
7. So you have edges ... i.e poly lines (per mesh face) and if you offset them ... you have "drilling" profiles that you must use against a second guide "thickened" blob for creating a continuously smooth exo-skeletal LBS (as shown). Of course Rhino (being a surface modeller) could require years to do this solid difference opp (or an eternity).
8. Rounding the "lips" of that LBS Brep is out of question with Rhino or GH (but it can been done very easily using other apps). Then you must "split" the Brep (in modules? in nodes + "rodes"? you tell me) in order to make it in real-life (what about forgetting all that?, he he).
9. Then, there's the glazing thingy that is made via quads meaning planarity. This is achievable with Kangaroo2 but is a bit tricky.
Moral: WHAT a gigantic pile of worms is this thread of yours...
more soon.
…
rights to register the "mapwingis.ocx" file.Francesco, would you be patient just a tiny little bit, so that we could try something else? I would be grateful if you could.
1) Close Grasshopper and Rhino2) Run the Revo Uninstaller Pro and uninstall your MapWinGIS application along with removing all the leftovers from the registry.3) Restart your PC, and once it boots again, make sure that you are logged in as an Adminstrator.4) In your Start menu's search box type: "UAC", which will find your User Account Control Settings. Click on it, and a new window will open. Set the bar on the left to "Never notify".5) Turn off your Antivirus, which ever it is.6) Download the 64 bit version of v4.9.4.2 MapWinGIS.7) Right click on downloaded MapWinGIS-only-v4.9.4.2-x64.exe file, and choose "Properties". If there is "Unblock" button click on it, and then click on "OK". If there is no "Unblock" button, just click on "OK".8) Left double click on MapWinGIS-only-v4.9.4.2-x64.exe file and install it to "C:\dev\MapWinGIS" folder. Choose "Full installation" during installation process!9) In your Start menu's search box type: "CMD". Once the "Command prompt" appears do not left click on it! Instead right click on it, and choose "Run as Administrator".10) A command prompt window will open. Type the following command:
"your_regsvr32_folder_path\regsvr32.exe" /u /s c:\dev\mapwingis\mapwingis.ocx
If command does not result in an error message, then type this one afterwards:
"your_regsvr32_folder_path\regsvr32.exe" /s c:\dev\mapwingis\mapwingis.ocx
11) If no error appeared again, then open your Rhino and Grasshopper and check what Gismo_Gismo component prints from its "readMe!" output.If errors appeared, it would be nice if you could post their screenshots.…
Added by djordje to Gismo at 5:46am on March 27, 2017
of similar/WOW buildings that failed (or leaked) including a very famous one.
2. You must use instance definitions for the truss parts (sleeves, cones, rods and the likes) otherwise the whole thing could become an unworkable nightmare.
3. You must address clash issues otherwise doing it is out of question. These affect the skin parts as well (but as I said: this is 100% pro territory).
4. Your structural analysis (in order to make any sense) must deal with real life components either commercially available or bespoke things designed for the specific project.
5. Wind/Seismic effects can cause skin component issues/failures/leaks as it happened ... well ... in a variety of contemporary famous buildings.
6. Vapor condensation yields (in most of similar cases) buildings that "rain from the inside" - nothing serious, mind: just have an umbrella ready.
…
n #, row #, seat #, various value metrics, etc.).
I can also use Elefront to bring this data back in along with the geometry, but the geometry comes in flat. Normally I would grab a corresponding tree structure from somewhere upstream in the definition or internalize the structure if I'm starting a new definition and then apply this to an unflatten component to restructure the geometry.
However, I got to wondering if I could use the flattened row and seating data from my object's user dictionary to reconstruct a tree. To keep things simple, I start the numbering at 0 instead of 1 to match the way Grasshopper indices work.
If I have 2 sections, each with 3 rows, and the rows have 4, 5, and 6 seats respectively, my seat data per seat would look like this (spaces are for pattern clarity):
0123 01234 012345 0123 01234 012345
And my row data per seat would look like this:
0000 11111 222222 0000 11111 222222
I was able to use these two numerical patterns alone to reconstruct the tree but I suspect my solution is inefficient. I'm including images and the definition itself in case anyone wants to take a stab at it.
…
ight. Note that i added the Ladybug component to simplify the inputs...
Here are some functions i'd love to see:
1. Ability to cull down to a partial year / date range AND hours range. Currently the DSchedule component can only truncate time of day. But if for example i want to look at averages just during the summer months between 9am - 6pm, i have to do that in the excel .ill file. It seems that the components may allow this already, just not sure which settings need to be set (seems that the reporting frequency has something to do with this...)
2. I'd also like to be able to look at a subset of the points to look at averages in a part of the grid. The easiest i presume would be just to pull item #s; maybe there's a way to add visual identifiers to the selection option? Again, have been doing this in the .ill file.
3. Provide, as an alternative to the .pts file, the option to input the point geometry directly from the rhino file - maybe this would help with #2?
4. I read up on your explanation on showing point-in-time values but can't seem to get that working. Would love to be able to do slider animations of the point-in-time calcs over a day like the bottom right of this (here i used Ladybug but the DA output would be more accurate).
5. Visualization Bounds doesn't seem to work on the daylighting side - would like to be able to manually change.
6. Showing the peaks is a fantastic addition! But all that information is bundled in the python script - would love a way to parse it out to just show the peak numbers for example.
7. Similarly to how DIVA shows data, it'd be great to add a component that visualizes the simulation parameters and color scale in the Rhino viewport...:)
i'm sure there's more as i continue to use it...
great script.
dan
…
o far (abstracted for brevity) have been: 1) decompose the brep to extract the faces for each cardinal orientation 2) Extract the corner points of these faces (my script here is a little rough - would appreciate feedback) 3) Draw lines from these corner points to a curve that represents the sidewalk on the other side of the street 4) intersect these lines with a plane 5) draw a Polyline through these intersection points (using a clever bit of VB written by David Rutten) 6) Make a surface from this polyline that represents the perceived building mass as seen from the sidewalk on the other side of the street. This seems like it should be simple, but I'm struggling to make it work for every facade of the building, and for any geometry I throw at it.
So far I've been successful for one facade of the building, but my script breaks down for the other facades. I think the breakdown lies in drawing the polyline between the intersection points - though I may have created this problem earlier in the script in my corner point extraction strategy.
Working Script:
Broken Script:
I'm writing this script to allow me to analyze many building massing options in a short amount of time. I'm trying to make it work universally for a large range of geometries. Any help you can provide would be awesome!
I've attached the script and the rhino model. I've done my best to annotate the script and highlight the area that I believe to be broken.
Thanks,
Matt
…