2: https://vimeo.com/107502226
------------------------------------------------------------------------------------------------
Hi all,
1. Chris, Chien Si and I will present Ladybug and Honeybee at IBSA-USA NYC this Thursday (August 21st). The presentation will include some of the latest developments that we are working on. If you are interested to know more about some of the new developments and see some of the workflows and you are around New York then just stop by. If can't attend in person you can still watch the presentation online. Check the links below. (Make sure to register by Wednesday if you are attending in person.)
2. We would like to show some of the works that you have done with Honeybee and Ladybug during the presentation so if there is anything that you think is interesting and can be presented publicly send it to us at thisisladybug@gmail.com or just post it here. Make sure to let us know who do you want us to credit the image.
3. That's it for now. I copy the information about the presentation below and hope to see some of you there. Thanks for your help and support.
Cheers,
Mostapha
IBPSA-USA New York Regional Chapter presents:
Parametric Modeling Tools | Ladybug and Honeybee
Location: Thornton Tomasetti, 44 East 27th street (between Madison and Park)
Date & Time: Thursday, August 21, 2014 - 6:00-7:30 PM.
6:00-6:30 PM Networking
6:30-7:30 PM Ladybug and Honeybee
Mostapha Sadeghipour Roudsari, Thornton Tomasetti
Chris Mackey, MIT
Chien Si Harriman, Terabuild
7:30-7:45 PM Q & A
Click here to register**: https://attendee.gotowebinar.com/register/6507378565592582402
**Please register at least a day in advance if you wish to attend in person
Descriptions
Ladybug + Honeybee
Ladybug and Honeybee are open source environmental plugins for Grasshopper that help architects and engineers create an environmentally-conscious architectural design.
Ladybug imports standard EnergyPlus Weather files (.EPW) into Grasshopper and provides a variety of 3D interactive graphics to support the decision-making process during the initial stages of design. The plugin also provides further support for designers as they test their initial design options with radiation, sunlight-hour, and shading analyses. Integration with Grasshopper allows for an almost instantaneous feedback and, since the plugin runs within the design environment, the information and analyses are interactive.
Honeybee connects Grasshopper3D to EnergyPlus, Radiance, Daysim and OpenStudio for building energy and daylighting simulation. The Honeybee project intends to make many of the features of these simulation tools available in a parametric way. Just as users have made changes to geometry for years in Grasshopper, now users can parameterize system types, zoning schemes, schedules of operation, daylight sensor placement and controls - all of the “hardcore” simulation parameters that have never been exposed to parametric modeling tools.
https://www.facebook.com/LadyBugforGrasshopper http://www.grasshopper3d.com/group/ladybug
…
a given with the third set of information (at the 6th minute). From that, it will then match - for the same exact boats - the speed data given at the 4th minute. Finally it will do a matched subtraction of V(4th) from V(6th) for each boat. Those numbers - whether then scaled up / down or somehow manipulated - will act as the Z dimension which will create the topology. Since V2 - V1 can have a minus value, the overall topology will be a mix of mountains and icebergs this time.
Perhaps to be more accurate, we could divide V2-V1 by 120 and let the topology show the change in speed in a second within that two minutes; the XY coordinates belonging to the latter position of the ships, not the first.
Your definition as you say helps for the linear drawing as it continues from it's stopped. I used that in the current sketch as well for again doing the same thing.However when, I tried to use it for what I am trying to do with the acceleration thing, the result was different. I will try to explain this again;
Let's say that until this point 6 sets of data has arrived - so 12 minutes has passed -. Within that 6 sets, the number of of boats for each one differ as not all of them are able to send data every time. Let's assume in total there are 25 boats and 18 of them have always managed to send data in those 12 minutes. So 18 from the beginning until the end, and finally let's say the remaining 7 of them only could manage to come into the picture at the 4th set of data (so 4,5 and 6).
Now, if I were to build a topology of acceleration for the 6th minute which would mean that I would have to subtract V(4th minute) from V(6th minute) of all 18 vessels, I would need index 2 and 1 from all the branches. If I do this only after 6 minutes has passed from the beginning it would probably work, however if I do it later like at the 12th minute, it does not.
And the very reason for that is when the remaining 7 join the crowd at the 8th minute they obtain an index number of 0, and then 1, and then 2 - at the 12th minute. Because of that when I try to match the V2-V1s with Coordinates on the Unary Force component, while there are 18 sets of coordinates, there are 25 different speed values.
Of course this is quite a simplified scenario and perhaps your vessel matching could solve this specific one but there are cases where its more complicated and random.
I do still want to show vessels' position in a specific time with such pipes you have suggested, but I am trying to construct a collective model, in its simplest form being equal to pipes + topology
For the time thing, what I meant was in this version when you click play the mountains just keep on rising and the topology is constantly deformed. I was wondering if we can set up a timer so that it runs the physics engine for couple of seconds and then freezes the topology as it is. Otherwise I would have to press pause manually everytime, which is not that big of a deal tbh, just for the accuracy sake it would be good to run the engine for the same interval for each model.
All the best,
Levent…
rawing speed here depends mainly on the speed of a single processor. Get a faster processor, increase the redraw speed.
2) Geometry operations. Such as Piping, Lofting, Curve CP etc. These are all performed by the Rhino core so there's little to be done here. We're continuously working on speeding things up, but they're already pretty fast (considering the complexity of the tasks). Rhino 5 has got a few bits and pieces of multi-threaded code and once we're convinced they're working well we'll probably apply those newly won skills to other parts of the core. These operations are also dependent mainly on processor speed.
3) Autosave operations. Since these involve writing data to the disk, it's very hard to predict whether or not it will be a fast or slow operation.
4) Viewport previews. This code is actually pretty horrible, it could be much faster than it currently is. However, a good Graphics card will make a lot of difference both now and in the future.
The ideal spec for Grasshopper is the same as it is for Rhino:
A) Get a good graphics card. We no longer shun ATI since their latest cards are actually pretty good, so either get a high-end NVidia or ATI card. Good gaming cards are not necessarily good CAD cards. Gaming cards are optimized for triangles and sprites, they don't do particularly well with curves.
B) Memory is dirt cheap, get as much as you can. 4GB being the absolute minimum. But, be sure to get fast-access memory, makes a lot of difference.
C) Get a fast processor. Since neither Rhino nor Grasshopper very much use multi-threading it is important that every single core is fast. I.e., don't get fooled by vendors who add the core speeds together and present that as the processor speed. One core running at 4 GHz is better than 8 cores running at a combined 16GHz.
As for OS, I'd recommend XP Pro or Windows 7. Stay away from Vista if you can. Also, almost all the software and hardware problems I come across at workshops are happening on MacOS machines running some flavour of Windows. Be it parallels, Bootcamp or VMWare.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 11:33am on December 15, 2009
precise) that unfortunately has more than one staff. This means that I pay the bills (unfortunate to the max). Practice is vertical meaning no Structural/HVAC etc services.
2. AEC Projects are made by teams. Period.
3. Teams are organized with some sort of hierarchy. Period.
4. On each team there's always one leader. Teams can being sampled in group teams - call them clusters (kinda like a List of List of ...)
5. All cluster leaders report to the supreme human being (yours truly). Leader heads are always on my disposal (it's fun to decapitate someone: I do this every Monday).
6. AEC projects are made with 1% idea(s) and 99% of what we call "sludge" (this is not my job: I'm the One , he he).
7. You can't steer any boat if you don't know each @@$#@ nut and bold. In the past there was a naive approach on that matter (ruined automotive companies, potato chip makers, software vendors, political systems, secret service agencies ... etc etc).
8. Efficiency is above all (even above tax-free cash).
9, You can't do ANY AEC real-life thing with what GH has to offer (nor Rhino is an AEC BIM app - it would never be). You simply use GH as a supplement to Generative Components (and/or as stand alone because it's good fun). There's nothing that GH does (I'm speaking solely for AEC as always) that can't being done with Generative Components.
10. I've done so fat 257 projects (a "bit" bigger than a house, he he). Let's say about 51427 drawings (master, master details, details) and 78956 lines of text (specs, cost estimations, space schedules, supplier lists, contracts, cats and 1 dog).
If you combine all the above you'll have the answer (i.e. why I use solely - if possible - code and not GH components). If you can't combine them I'm sorry.
PS: C# is the absolute standard (never judge a language as a "stand-alone" thingy).
best, Peter (Prince of Cynics)
…
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.
…
is Radius = (size+40)/(2*Pi), where "size" is the value to give, it's usually used in countries like Spain, Italy, Netherlands, Switzerland... The next release will have 6 ways (5 regional system + diameter) to give it the size in different regional systems with just two clicks, in fact, the rings of the next release are already developed, but will have to wait...
Knowing that:
ISO (International Organization for Standardization). mm of internal circunference. Austria, France, Germany, Belgium, Scandinavia...
radii = Size / (2 * Math.PI)
European Size. Spain, Italy, Netherlands, Switzerland...radii = (Size + 40) / (2 * Math.PI)
British Size. United Kingdom, Ireland, Australia, New Zealand, South Africa...radii = ((Size * 0.4) + 11.5) / 2
American Size. United States, Canada, Mexico...radii = ((Size * 0.83) + 11.54) / 2
Japanese Size. Japan, China, India, South America...radii = ((Size / 3) + 12.67) / 2
Diameter Size. Many goldsmiths anywhere.
radii = Size / 2
Source: http://www.18carat.co.uk/ringsizes.html
and since this release are UserObject componentes, you can remplace if you want the Size component with one new. For example, right clicking size_param, going to Expresion and setting x*pi-40, the size input will be the diameter of the resulting circle, if you give it a value of 14, the circle will have a radius of 7. Then save the userobject (File>Create User Object) and remove the other.
Or create a new one, since this component is just a rotated circle and a cylinder.
Hope this helps.…
r is open, the memory use jump quickly and stay at high level, even if I didn't open any GH file:
3. once I close GH (with Rhino still running), the memory use drop a bit, and rise again, but not to the high level as before:
4. once I close Rhino, the memory use will drop to normal level:
5. the GH components I'm using are installed locally on my computer:
I'm not sure if this is a problem with my computer in particular, as this issue only happened a few days ago. I'm using Rhino 5 SR7 64bit in Windows 7 Pro and the latest version of GH on my computer for quite a while with no obvious speed issue, and I didn't upgrade them recently.
Hope you can kindly advise!
Thank you!
- Ji…
Added by Grasshope at 4:23am on September 13, 2016
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
achieving some preliminarily/conceptual Academic solution that "may" qualify as "realistic". I have several defs that do similar stuff ... but this is an Academic forum and as you can understand a real-life solution would never appear here.
But let's forget the W task (truss out of relaxed mesh with depth, known as W in our trade). See for instance a step prior the "thickness".
General guideline:
1. Create a boundary (a BrepFace) and attempt to do some "reasonable" Mesh via Mesh Machine.
2. Mastermind a policy to manage anchors (naked and/or clothed vertices). This appears easy but is impossible without code IF you want to do it interactively.
3. Separate naked edges from clothed ones (as we do in real-life in tensile membranes etc etc) in order to apply different goal parameters.
4. Relax the mesh (K231 engine).
5. Either work with a "geodesic" structure (W = 0) or make a truss out of the mesh in 4. In either case decide the real-life system in use (say a Mero KK or some other).
6. Check clash truss members issues and interactively vary vertices in order to resolve them.
7. Create all the required connectivity Trees (VV, VE, EV).
8. Mastermind the skin solution (only for experienced pros: avoid at any cost that one).
My advice? Unless you are very determined ... well ... what about choosing an easier design task?
…