for metadata on the Grasshopper installation but can't seem to find a reliable way to do this.
Issue #1 - Checking for an installation of Grasshopper
a) I can check to see if Grasshopper has been installed by searching the Windows registry, but it's not reliable. It seems that Grasshopper no longer has an individual uninstall package (can't find in Add/Remove...), and rather is uninstalled if you uninstall Rhino. However, the registry keys for Grasshopper do not appear to be cleaned on a Rhino uninstall, so my installer can get spoofed into thinking that there is a Grasshopper installed when it's not.
b) It appears that not every Grasshopper install creates a registry entry in HKEY_LOCAL_MACHINE. On my machine, for instance, I can search for the Grasshopper key and return the directory of the .rhp file, and then verify that the file does in fact exist. On other machines, however, I have found that there is no key in the HKEY_LOCAL_MACHINE, and the registry entry in HKEY_CURRENT_USER does not include the path to the .rhp file, so I can't verify whether it does in fact exist or if the registry is out of date.
c) I could brute-force search for the .rhp file, but I haven't found the most reliable parent director(ies) to search in order to be exhaustive and accurate.
Issue #2 -- Checking the Grasshopper Version
I would like to be able to trigger an update programmatically to a network installer (firm-sanctioned GH version) if the existing version is older than specified.
In some cases, if I can find the rhp through the HKEY_LOCAL_MACHINE key, I could theoretically parse the file path, which appears to contain the text representing the version. This seems hacky, though, and I have to learn Gentee programming language to do it (trying to avoid that). Also, as I said before, I am not guaranteed to have this path location if I am only able to find the HKEY_CURRENT_USER key. Perhaps if I could reliably find the .rhp through a brute force file search, this would be my best option.
Just thought I would put this out there to see if you have any thoughts (David?). :) If I don't hear anything from the community, I'm going to try to do the brute force search and parsing method...
Thanks,
Marc
…
s in Python:
...and if I print ghc.CullDuplicates(curve_points) I see the actual names of the outputs in the Python editor:
...so I can either do:
a,b,c = ghc.CullDuplicates(curve_points)
...or:
a = ghc.CullDuplicates(curve_points)[0]
b = ghc.CullDuplicates(curve_points)[1]
c = ghc.CullDuplicates(curve_points)[2]
...or even:
a = ghc.CullDuplicates(curve_points).points
b = ghc.CullDuplicates(curve_points).indices
c = ghc.CullDuplicates(curve_points).valence
And multiple inputs are just separated by commas within the parenthesis.
But the component is defaulting to Average instead of Leave One, which doesn't give me much useful. I'm trying to remove duplicate lines quickly, of 25K lines, and this is the fastest component in Grasshopper I've found to do that, by finding the line midpoint then getting the indices output from CullDuplicates to find out which are keepers.
There's no documentation about what Average even means, and it spits out a bunch of -1s, with the resulting lines culled by index of the good numbers being rather odd compared to Leave One, which just works naturally, like a human being would want it to.
Is it possible to change the component mode from Average to Leave One from Python?
Rhinocommon seems to lack a cull duplicate lines/curves command, so I'm hoping Grasshopper components will be faster than raw interpreted (uncompiled) Python.
…
Added by Nik Willmore at 11:22am on February 11, 2016
I have the IES files from the manufacturers. I am able to get the IES files to load and run in Honeybee. However the light levels being produced are low and very localized to the light source. I am trying to determine if it’s some scaling, etc that needs to be modified. Within Honeybee there is a “CandelaMultiplier” which allows me to increase the values, but I don’t want to do it arbitrarily nor am I sure this is truly solving my problem.
If anyone has any insight as to importing IES files into Honeybee and things that need to be factored and considered that would be appreciated. I'm experiencing the situation with other IES files as well.
Thank you!
Screenshots: 1 candela multiplier, 5 candela multiplier, 5 candela multiplier 2 lum web, legend and screenshot of grasshopper interface:
Files attached: SunCentral IES file, Rhino, and Grasshopper
…
s: the nut's width is divided in equal segments resulting in queal spacing from string center to string center but the spacing bewteen the top strings is smaller than between the lower strings. It's not very comfortable to play, on bass guitar it's really awkward
2. equal spaces: the nut is divided so that the spacing between the outer edges of all 6 strings is the same. Since eachstring has a different width (gauge) this requires some calculations but is much more comfortable to play
i have attached my pathetic simple attempt at creating this. It works for 'equal centres' but i can't really figure out several things:
A. how to use a table or list of values as an input for the string gauges. Ideally i would like to select from different 'sets' of strings so that i can create different nut templates for different thickness strings easily. So ideally i would like to select a preset like: 'light', 'ultra light', 'medium', 'light top heavy bottom' and then it would adjust everything according to the different string gauges defined in those sets/lists.
B. how to use metric units for the spacing of the top and bottom strings to the fretboard/neck edge. I have tried to do it by eyeballing it with the 'point on curve' element which i'm pretty sure is not the way to do it properly. I want to be able to simply input this in mm, so for example a 4mm distance from the strings to the fretboard edge.
C. how to figure out the 'equal spaces' and divide the bridge and nut curves accordingly so that the distance from the outside edge of the top and bottom strings to the fretboard is equal, and the spacing between the strings outer edges (not the centres) is equal.
would really appreciate any help or tips to point me into the right direction :)
…
, Arq. Daniel Gelardi
Año: 2013
Memoria Descriptiva
La primera etapa del proyecto final se enfocó en la participación del concurso International Velux Award 2012: Concurso que anima y desafía a los estudiantes de arquitectura a ‘explorar el tema de la luz del día en su sentido más amplio’. Se adoptó una postura centrada en el manejo de la luz natural en el espacio interior, pero aplicada específicamente para el contexto natural y cultural de la provincia de Mendoza - Argentina.
El proyecto enviado al concurso se enfoca en tomar la luz natural del medio, como elemento protagonista dentro del espacio de uso múltiple y social diseñado y configurado para el desierto de Mendoza. En la cubierta se desarrolla una ‘piel responsiva’ que varía según los cambios climáticos de temperatura: la cubierta se divide en diversas piezas que evocan a la piel porosa de un cactus: cuando la radiación solar es alta o baja, estas piezas empiezan a adquirir movimiento, tamizando o dejando pasar la luz del sol.
La idea del proyecto, después de un extenso proceso de investigación, evolucionó para convertirse en una ‘Reserva Genética de Vegetación’ que toma como inspiración los factores naturales del medio local: el desierto; sustentados por la identidad cultural de nuestra ciudad oasis.
En la Reserva Genética de Vegetación se pretende realizar dos actividades principales que tienen el fin de aportar a nuestra provincia aquello que la destaca culturalmente como un Oasis :
1. Centro especializado de cultivo, donde se producen una cantidad ilimitada de especies vegetales (técnica de Cultivo In-Vitro) para forestar lugares de la provincia donde se necesite urbanizar.
2. Centro de investigación y experimentación de la flora autóctona xerófila, que pretende incorporarla como potenciales especies para forestación y uso público: Como ya sabemos, estas plantas son las que más se adaptan a nuestro medio.
La reserva genética pretende ser el exponente de una arquitectura que toma parámetros concretos del medio y su cultura, para así prestar un servicio que forma parte de la escencia de nuestra ciudad de Mendoza: el cultivo vinculado con la forestación.…
mbre de 9:00 am a 8:00 pm Este taller está dirigido principalmente a arquitectos y diseñadores interesados en el aprendizaje del diseño paramétrico y generativo aplicados a la generación y racionalización de geometrías complejas para su implementación en diferentes procesos de diseño. En el curso se abordarán los conceptos básicos y metodología para hacer frente a diversas problemáticas del diseño mediante el desarrollo de herramientas algorítmicas a través de un lenguaje de programación visual y el desarrollo de esquemas de fabricación digital. No se requieren conocimientos previos de Rhinoceros 3D ni de programación, conocimientos previos de CAD deseables. Estudiantes: 2,500 MXN Profesionales: 3,000 MXN
CONCURSO DE RENDERS - BECA DEL 100% - Parametric & Generative Architecture & Design Grasshopper Workshop.
- Publica tu render en www.facebook.com/3dmetrica - El render con más likes será el ganador. - Fecha límite de votaciones 15 de septiembre del 2012.
Informes e Inscripciones: workshop@3dmetrica.com 04455 28790084 www.3dmetrica.com www.facebook.com/3dmetrica
…
e display pipeline @ xx:xx:xx(xxxms)
iThe DrawViewportWires only when loaded!
The DrawViewportMeshes always when the viewport is refreshed!
Any Idea?
Public Overrides Sub DrawViewportWires(ByVal args As Grasshopper.Kernel.IGH_PreviewArgs) ' MyBase.DrawViewportWires(args)-> Disabled because nothing to Display If (Hidden) Then Return
For Each item As Rhino.Geometry.Circle In Circle args.Display.DrawCircle(item, GC, 3) Next
For Each item As Rhino.Display.Text3d In txt
args.Display.Draw3dText(item, GC) Next
End Sub
Public Overrides Sub DrawViewportMeshes(ByVal args As Grasshopper.Kernel.IGH_PreviewArgs) ' MyBase.DrawViewportMeshes(args) -> Disabled because nothing to Display If (Hidden) Then Return
Dim Brep As Rhino.Geometry.Brep Dim M As Rhino.Display.DisplayMaterial
For i As Integer = 0 To Circle.Count Brep = Rhino.Geometry.Brep.CreatePlanarBreps(Circle.Item(i).ToNurbsCurve())(0) M = New Rhino.Display.DisplayMaterial(VC.Item(Math.Min(i, VC.Count - 1))) args.Display.DrawBrepShaded(Brep, M) Next
End Sub
…
y anyway ;))
Since 2014 i begun to get back into the construction biz for some dozen main reasons, one of them being the highly increased availability of this kind of software "power", and robotics.
first project ended by 1stQ 2015 was focused on the development of a parametric block for construction. (almost sure the first parametric product designed in Uruguay, and probably one of the few first of this kind globally...)
Far from being a complicated model. In fact the standard model is extremely simple, key thing is that is fully parametric...
dimensions, materials, textures, colors... and so on
second key thing is that the main common component of the blocks (an EPS core) is robotically machined...
the blocks are the base of a construction system (oriented mainly - though not restricted only - to residential buildings) that
- is based on digital models, tendentially to be used in parametric models of buidings
- lab tested to prove to be 1.5 times as compression resistant than traditional bricks and blocks. (autoportability up to two stories buildings)
- has recently proved (due to size) to be 300% more efficient than the classic and 200% more efficient than steel frame in (our country official figures)
check it out here
--
https://drive.google.com/file/d/0B1TRxxgF_sEnQnZrTkZGbUx3cmM/view
--
- and it's aimed to be mass produced and handled by robots...
this project ended on 1H 2016
and i filed 4 patents in the process.
3 of them of mechanical devices designed as extensions for a cnc machine i own
and the fourth (
the patent related specifically with the blocks ) included a dozen of innovations (believe me...i have almost 15 yrs in the biz, and are coool stuff...)
along the project I've been working with inventor, even knowing in advance it will lack the kind of features I wanted to program many things... (lisp, VB, etc.... all same species of -prehistoric - animals) to leverage the tool to the sky - and far beyond... -
but was an alternative valid by that time because it allows the implementation of some form of parametric models, had a local representative and some supposedly skilled guys in the neibourhood....
but life is hard... and none of the latter two rendered me any significant help
so I had to take the tour myself...
- mind i never regret to do things that others cant -
and finish what i start
this one was a great project for many figures... and ended with more results than the ones commited to accomplish...
... some more history here ....
then because of a customer who brought a ZHA project ! to quote..., I crossed with rhino, and then met GH again to notice to my great joy and pleasure, in what kind of animal it had developed...
since money talks I'm investing hard on getting up to the expectations, and beyond as i usually do...
and thats how we met..
2017-2018 it's the time frame to build two robots. first one is a prototype to handle the k-nano blocks in the production process, delivery AND at the construction site ( a "smart crane" we nicknamed...)
the other one is the first prototype of robot to assist in the fabrication (smart blocker we called it to be creative ! ;))
then by 2018-2019 i'll be making a "kinda contour crafter" machine to complete the pie :) (you'll be interested on this..)
i guess you already know what all this has to do with GH...
i already have all the components i can imagine to do almost all i ever wanted to do in relation to this set of projects
but in almost a single tool !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
i can design, animate, render, optimize, simulate and even robotic simulate..
so, i have to ask...
is there a chance you might be interested in helping us in some projects we are starting on march and june 2017 (8 and no more than 18 months of duration respectively) ?
sent you a friend request, for the case you might be interested to continue by e-mail...
in any case many thanks for your help and inspiration !
best regards !
long happy marriage, and large figures bank account !
…
mplex the models are. If we are running multi-room E+ studies, that will take far longer to calculate.
Rhino/Grasshopper = <1%
Generating Radiance .ill files = 88%
Processing .ill files into DA, etc. = ~2%
E+ = 10%
Parallelizing Grasshopper:
My first instinct is to avoid this problem by running GH on one computer only. Creating the batch files is very fast. The trick will be sending the radiance and E+ batch files to multiple computers. Perhaps a “round-robin” approach could send each iteration to another node on the network until all iterations are assigned. I have no idea how to do that but hope that it is something that can be executed within grasshopper, perhaps a custom code module. I think GH can set a directory for Radiance and E+ to save all final files to. We can set this to a local server location so all runs output to the same location. It will likely run slower than it would on the C:drive, but those losses are acceptable if we can get parallelization to work.
I’m concerned about post-processing of the Radiance/E+ runs. For starters, Honeybee calculates DA after it runs the .ill files. This doesn’t take very long, but it is a separate process that is not included in the original Radiance batch file. Any other data manipulation we intend to automatically run in GH will be left out of the batch file as well. Consolidating the results into a format that Design Explorer or Pollination can read also takes a bit of post-processing. So, it seems to me that we may want to split up the GH automation as follows:
Initiate
Parametrically generate geometry
Assign input values, material, etc.
Generate radiance/ E+ batch files for all iterations
Calculate
Calc separate runs of Radiance/E+ in parallel via network clusters. Each run will be a unique iteration.
Save all temp files to single server location on server
Post Processing
Run a GH script from a single computer. Translate .ill files or .idf files into custom metrics or graphics (DA, ASE, %shade down, net solar gain, etc.)
Collect final data in single location (excel document) to be read by Design Explorer or Pollination.
The above workflow avoids having to parallelize GH. The consequence is that we can’t parallelize any post-processing routines. This may be easier to implement in the short term, but long term we should try to parallelize everything.
Parallelizing EnergyPlus/Radiance:
I agree that the best way to enable large numbers of iterations is to set up multiple unique runs of radiance and E+ on separate computers. I don’t see the incentive to split individual runs between multiple processors because the modular nature of the iterative parametric models does this for us. Multiple unique runs will simplify the post-processing as well.
It seems that the advantages of optimizing matrix based calculations (3-5 phase methods) are most beneficial when iterations are run in series. Is it possible for multiple iterations running on different CPUs to reference the same matrices stored in a common location? Will that enable parallel computation to also benefit from reusing pre-calculated information?
Clustering computers and GPU based calculations:
Clustering unused computers seems like a natural next step for us. Our IT guru told me that we need come kind of software to make this happen, but that he didn’t know what that would be. Do you know what Penn State uses? You mentioned it is a text-only Linux based system. Can you please elaborate so I can explain to our IT department?
Accelerad is a very exciting development, especially for rpict and annual glare analysis. I’m concerned that the high quality GPU’s required might limit our ability to implement it on a large scale within our office. Does it still work well on standard GPU’s? The computer cluster method can tap into resources we already have, which is a big advantage. Our current workflow uses image-based calcs sparingly, because grid-based simulations gather the critical information much faster. The major exception is glare. Accelerad would enable luminance-based glare metrics, especially annual glare metrics, to be more feasible within fast-paced projects. All of that is a good thing.
So, both clusters and GPU-based calcs are great steps forward. Combining both methods would be amazing, especially if it is further optimized by the computational methods you are working on.
Moving forward, I think I need to explore if/how GH can send iterations across a cluster network of some kind and see what it will take to implement Accelerad. I assume some custom scripting will be necessary.…
, Engineer and Researcher from France with broad programming experience. He is the author of the City in 3D Rhinoceros plugin for creation of buildings according to geojson file and with real elevation. Guillaume already created a new component: "Address to Location". It enables getting latitude and longitude values for the given address:
2) Support of Bathymetry data: automatic creation of underwater (sea/river/lake floor) terrain. This feature is now available through new source_ input of the "Terrain generator" component. Here is an example of terrain of the Loihi underwater volcano, of the coast of Hawaii:
3) A new terrain source has been added: ALOS World 3D 30m. ALOS is a Japanese global terrain data. Gismo "Terrain Generator" component has been using SRTM 30m terrain data, which hasn't been global and was limited to -56 to +60 latitude range. With this addition, it is possible to switch between SRTM and ALOS World 3D 30m models with the use of source_ input.
4) 9 new components have been added:
"Address To Location" - finds latitude and longitude coordinates for the given address.
"XY To Location" - finds latitude and longitude coordinates for the given Rhino XY coordinates. "Location To XY" - vice versa from the previous component: finds Rhino XY coordinates for the given latitude longitude coordinates. "Z To Elevation" - finds elevation for particular Rhino point. "Rhino text to number" - convert numeric text from Rhino to grasshopper number. "Rhino unit to meters" - convert Rhino units to meters. "Deconstruct location" - deconstructs .epw location. "New Component Example" - this component explains how to make a new Gismo component, in case you are interested to make one. We welcome new developers, even if you contribute a single component to Gismo! "Support Gismo" - gives some suggestions on how to make Gismo better, how to improve it and support it.
5) Ladybug "Terrain Generator" component now supports all units, not only Meters. So any Gismo example file which uses this component, can now use Rhino units other than Meters as well. Thank you Antonello Di Nunzio for making this happen!!
Basically just forget about this yellow panel:
This panel is not valid anymore, so just use any unit you want.
6) A number of bugs have been fixed, reported in topics for the last couple of weeks. We would like to thank members in the community who invested their time in testing, finding these bugs and reporting them: Rafat Ahmed, Peter Zatko, Mathieu Venot, Abraham Yezioro, Rafael Alonso. Thank you guys!!! Apologies if we forgot to mention someone.
The version 0.0.2 can be downloaded from here:
https://github.com/stgeorges/gismo/zipball/master
And example files from here:
https://github.com/stgeorges/gismo/tree/master/examples
Any new suggestions, testing and bug reports are welcome!!…
Added by djordje to Gismo at 5:13pm on March 1, 2017