.!
Feel free to ignore them, or to remove this thread.
They are just a couple of thoughts:
1st idea: It would be great to right click on a slider and reset it to a "original" value (maybe just a click on a little icon next to the name, so it is even faster).This can be handy when using Galapagos, as all the sliders gets changed...and the fastest way I found so far to reset them is to close and open the GH file.But I bet as Galapagos is so new... well... maybe this is something you already thought about!
2nd idea: Having parametric sliders (with inputs).Imagine you want a slider to vary from x to y... now you have to type in the values. It would be good to set set x and y with inputs.
This is actually very useful using Galapagos, but quite useless in all the other cases...
Probably than the best way to do this is to add a feature in Galapagos to use domains as inputs... but I read somewhere that you are working on this already!
3rd idea: Change the value (or range) of multiple sliders.Imagine you want all the sliders you have to be =2... and imagine to have 20 sliders... if you select them and right click on one, it will only change that one. (not the selection). Would be good to edit a selection. (or maybe there is a way and I don't know it?)
----
Well, don't know if that will help somehow, but they are just thoughts! ;)
Thanks if you will consider them!!!
Compliments again for the incredible hard work on GH!
Cheers,Fil…
.
I had updated the components a few weeks ago but then got too lazy/busy to properly document that anywhere. Some of the additional features are:
1. It is now possible to substitute an IES file with a text string. For example one can paste the contents of an IES file into a text panel and connect that to the input for _iesFilePath. Alternatively, you can read a text file using the native Grasshopper "Read File" component, then embed (and internalize) that information inside the "Text" component.
So, either of the below two options will(should) qualify as an input for the _iesFilePath:
This makes it possible to embed IES data inside a GrassHopper file, thus doing away with the need for connecting to a file on a local drive.
2. I created a new component called Honeybee_IES Project which does the following:
1. It consolidates all the electric lighting RAD files for a simulation in one place. The single radFilePaths output from the component can be connected to the daylight simulation instead of connecting individual radFilePath outputs from every luminaire.
2. It creates a BOQ and luminaire schedule for all the luminaires used in the simulation. The schedule can either be viewed in a Grasshopper text panel or exported as excel.
The values for LLF, Candela Multiplier and Lamp Depreciation factor are printed out for each luminaire.
The effect of the multipliers on power consumption can be seen in the BOQ in the Total Power column:
Adding lumens to the output will be minor fix. I will update that within a few days.
I think the point-grid for the photometric and peak candela display are a great idea. I will add that functionality within a couple of weeks.
Are you implying the inclusion Type B photometry by "support for all ies file types" ? If so, that has been on my to-do list for a while. It might, however, be a while before I can get to it as it would require writing a convertor from Type C to Type B so that it can be visualized as a photometric mesh inside the Rhino viewport. I think the hackish way to get Type B photometry to work in Honeybee is to first convert the Type B photometry to Type C using something like the Photometric Toolbox.
Finally, the electric lighting components were initially written as a hack and they are still pretty much work-in-progress. I agree that calling the simulation a lighting simulation and adding separate inputs for electric lights would be a cleaner way of approaching these simulations. Mostapaha and I weren't sure of the traction that these new features might get. Based on the feedback received we will be simplifying and enhancing these components and the workflow to do electric lighting simulations.
(PS: Although I have heard a lot about Accelerad, due to the lack of compatible resources, I have never run a gpu-based simulation myself. I am not sure if Nathaniel requires additional flags or information to run Radiance simulations through Accelerad. If not, it should be possible to use files written through Honeybee to run Accelerad simulations. I will defer to Mostapha on the possibility of incorporating Accelerad in the Honeybee project).
…
doing this with the current tools or a bit of scripting since the Flickr API allows you to make requests in a REST format, but utilizing the Flickr.net API library makes it much simpler.
First and foremost, you need a Flickr API key...do you have one of those?
A great way to get to know the Flickr API is with the API Explorer. Here is a link to the page for the flickr.photos.search method explorer: http://www.flickr.com/services/api/explore/flickr.photos.search
The cool thing about this page is that it generates the REST Http call towards the bottom. So, here is what I did:
1. Grab the coordinates of the bounding box per Flickr API request:
bbox (Optional)
A comma-delimited list of 4 values defining the Bounding Box of the area that will be searched. The 4 values represent the bottom-left corner of the box and the top-right corner, minimum_longitude, minimum_latitude, maximum_longitude, maximum_latitude. Longitude has a range of -180 to 180 , latitude of -90 to 90. Defaults to -180, -90, 180, 90 if not specified. Unlike standard photo queries, geo (or bounding box) queries will only return 250 results per page. Geo queries require some sort of limiting agent in order to prevent the database from crying. This is basically like the check against "parameterless searches" for queries without a geo component. A tag, for instance, is considered a limiting agent as are user defined min_date_taken and min_date_upload parameters — If no limiting factor is passed we return only photos added in the last 12 hours (though we may extend the limit in the future).
So, I went to Google Earth, picked a city (London, UK) and dropped two pins:
This gave me two locations, which I can put into the Explorer Page next to the bbox option. Here is what I put for these two points: -0.155941,51.496768,-0.116783,51.511431
2. Check has_geo
3. In extras, type in geo
4. Make the call!
You will see a list of responses in an XML format, these responses will be from the first page. Geolocated photos are limited to 250 / page, so you will have to grab them page by page.
If you want to add more options (minimum upload date, maximum upload date, etc) you can do this as well)
The best is at the bottom, you get the full http call for this: http://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=ffd44f601393a46e86aa3a5f8a013360&bbox=-0.155941%2C51.496768%2C-0.116783%2C51.511431&has_geo=&extras=geo&format=rest&api_sig=b42330e5d1523bd5fe60c2ad43acde99
Notice this call has some other api key, you should eventually replace this with your own.
You could copy and paste this into a browser and you will get the results with the latitude and longitude:
So this is really what you need to know to do this through GH. Since gHowl has an XML parser component that can access files on the web, you should be able to use the same http call into this component.
Eventually, we get a response, and we need to grab the lat and lon data. With gHowl we can map these to xyz coordinates, and generate the heatmap...this is just a linear mapping:
Attached are both the Rhino file and the Grasshopper file, as well as the image underlay.
I am working on a series of components that makes this more straightforward, but for now, this should get you started.
…
ion date p: file path r: revision count v: Grasshopper version l: list of add-ons used"""
def Main(): global f, d, a, c, p, r, v f = ghenv.LocalScope.ghdoc.Name d = ghenv.Component.Attributes.Owner.OnPingDocument().Properties.Description a = gh.CentralSettings.AuthorName c = ghenv.Component.Attributes.Owner.OnPingDocument().Properties.Date p = ghenv.LocalScope.ghdoc.Path r = ghenv.Component.Attributes.Owner.OnPingDocument().Properties.Revisions.Count v = gh.Versioning.Version l = 1
Main()
The first question is that I'm bouncing between gh. and ghenv. for different things - can I/should I be more consistent? Are there consequences?
The second question is that I'm trying to pull the list of add-ons (variable "l") used in a definition. This data exists in the ghXML in the Library chunk:
<chunk name="Library" index="0"> <items count="4"> <item name="Author" type_name="gh_string" type_code="10"></item> <item name="Id" type_name="gh_guid" type_code="9">9d96da9c-9354-ef32-7983-0acb11a3d493</item> <item name="Name" type_name="gh_string" type_code="10">LunchBox</item> <item name="Version" type_name="gh_string" type_code="10">2014.4.27.0</item> </items> </chunk>
Any ideas on how to get that bad boy?
Thanks!
B…
) Take it apart, trim holes, connections, and other stuff needed for the fabrication > (c) Make 2d drawings out of them. (d) exporting them
I've got a few findings that might be useful in that context:
1. When using large amount of components, the show selected only is pretty much the weapon of choice to debug. In this context it would be useful if the Custom Preview components (also the custom vector preview component) would not turn green when selected in "Draw Only Selected Geometry" mode, since it turns them pretty much useless in this mode.
2a. A second step up to the same problem would be if turning objects on/off (enable/disable) (preview/disable preview) could be done at the group level. (Perhaps the ZUI-kung fu you've introduced could be the way to go?). This would make creating scripts that can have different stages that do not always have to be enabled a bit easier to manage.
2b. This would of course even be better if the groupwise-enable/disable operations are overrides. (in the sense that a component is only enabled when the group and the component are enabled).
3. Colours. Would it be possible to add a small pallette to the GH colour picker? Right now if we for example pick a convention "Let's make all the functionality that's for debugging yellow, all operating code that should not require messing about with green, and the parts that require human interaction Red", is a bit cumbersome, because picking the same yellow will require me to remember the colour values to get the same colour (The pipet tool will also give different colours)
4. Scribble: Can I please easily align text to 0,90,180 or 270 degrees rotation? :)…
ate through vibrant landscapes. If you're looking for more gaming excitement, check out https://lfcarry.com/diablo-4 for the latest updates on Diablo 4. Get ready to redefine racing fun and explore new dimensions of virtual entertainment.
…
Added by MichaelD0112 at 4:42am on August 31, 2023
to incorporating math and geometry in computational design education, Paneling Tools
Marlo Ransdell, PhD Creative Director, at FSU , Digital Fabrication in Design Research and Education
Andy Payne, LIFT architects | Harvard GSD | FireFly
Jay H Song, Chair, Jewelry School of Design, Jewelry as Personal Expression, Extra+Ordinary@Jewelry.com
Pei- Jung (P.J.) Chen, Professor of Jewelry, SCAD
Gustavo Fontana, designer/co-founder nimbistand, Diseñar, desarrollar y comercializar productos por tu cuenta.
Joe Anand, CEO MecSoft Corporation, RhinoCAM
Julian Ossa, Chair, Industrial Design Director, Diseño – Una opción de vida a todo vapor!, UPB
Minche Mena, SHINE Architecture, Principal
J. Alstan Jakubiec, Daylighting and Environmental Performance in Architectural Design Solemma, LLC
Carlos Garnier R&D Director / Jaime Cadena – General Director, Plug Design, www.plugdesign.com.mx
Mario Nakov, www.chaosgroup.com [ V-Ray ]
Andres Gonzalez, RhinoFabStudio
Workshops:
o) Paneling Tools
o) RhinoCAM
o) Rhinology in Design, for Jewelry
o) Footwear
o) V-Ray: Jewelry Design
o) V-Ray: Architects and Industrial Designers
o) FireFly
o) J. Alstan Jakubiec, DIVA
The cost for each workshop or the Lectures is 95.0 US$
To register:
WORK-SHOPS April 2 - RHINO DAY
WORK-SHOPS April 3 - RHINO DAY
REGISTRATION RHINO DAY
NOTE: All students and faculty members that register to this event, will receive a Rhino 5 Educational License at the event.
…
occur more than once in the same list, and different elements with identical values can occur more than once. Also, a list may contain lack of elements, referred to as "nulls".
Sets. Strictly speaking a Set is a mathematical construct which adheres to a strict collection of rules and limitations. Basically, a Set is the same as a List, with the exception that it cannot contain the same element more than once, or indeed two or more different elements with the same values. You see, in mathematics there is no difference between a value and an instance of that value, they are the same thing. In programming however it is possible to store the number 7 in more than one spot in the RAM. Grasshopper does not enforce this rule very strongly though, you can use a lot of Set components on lists that have multiple occurrences of the same value. The big difference between Lists and Sets in Grasshopper is that Sets are only defined for simple data types that have trivial equality comparisons. Basically: booleans, integers, numbers, complex numbers, strings, points, vectors, colours and intervals. Lists can contain all kinds of data.
Strings. Strings are text. There's nothing more to it. I don't know why early programmers chose to call them strings, but I suppose it's a better description of the memory representation of them. Strings are essentially sequences of individual characters.
Trees. Trees are the way all data is stored in Grasshopper. Even when you only have a single item, it will still be stored in a tree. A tree is a sorted collection of lists, where each list is identified by a path. A specific path can only occur once in a tree, when you merge two trees together, lists with identical paths are appended to each other. Trees are an attempt to losslessly represent not just the data itself, but also the history of that data. Imagine you have 4 curves {A,B,C,D} and you divide each into 3 points {X,Y,Z}. Then, for each of those points you create a new line segment {X',Y',Z'} and then divide each of those line segments again into 5 points each {K,L,M,N,O}. The way data is stored in trees, it should be possible to figure out whether a point M belongs to X' or to Z', and whether that X' or Z' came from A, B, C or D. This is why paths are often quite long after a while, because they encode a lot of history.
Paths. A Path is nothing more than a list of integers. It's denoted using curly brackets and semi-colons: {A;B;...;Z}. A Path should never be empty {} or have negative integers {0;-1}, but it is certainly possible to create a path like this and it probably won't even crash Grasshopper. Paths are 'grown' by components that (potentially) create more than one output value for a single input value. For example Divide Curve. It creates N points for every single input curve. In cases like this a new integer is appended to the end of the path.
In the next release the Path logic in Grasshopper is somewhat different. I fixed a number of obscure bugs (hopefully without introducing new fresh bugs) and special cased certain operations to somewhat reduce the speed at which paths grow. This may well break files that rely on a specific tree layout, but I hope the temporary sacrifice will be worth the long-term benefits.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
eets into the existing geometry taking into account (a) their maximum flex/bending capability - trying to create a "skin sphere" instead of a faceted ugly chaos (b) their physical size in order to avoid getting into the usual wedge situations (i.e: examine if a given flexible sheet of metal - kind of ribbon- can cover a NURBS of some sort).
first it is very easy to 'work with' existing geometry in GH and use that as a starting point. but the interesting part is the skin panels. you talk about two things, not having it faceted so i assume you want double curved panels? and then you want to optimize the panels based on the curvature and max sheet size. because you are using a geodesic dome then the curvature is constant which makes things a bit easier.
so the biggest issue is how to take the triangular piece of sphere that connect back to the super structure of the dome (that you show in your image) and sub divide that to the proper size panels that are able to be fabricated. you also want to minimize the amount of unique pieces that are created to make it more economical (the fact that it is a sphere will also make this easier).
because it is a sphere and the structure is comprised of identical triangles each piece of triangle sphere will be identical, the only only thing is how many different panels pieces will be needed to make up each section.
i think this can all be accomplished fairly easy in GH (or GC) using built in function to sub divide the panels, add size constraints and optimize for uniqueness. its a fun problem that should not take to long to figure out.
…