r window, and operate your script with a simple user interface.
The latest release of Prairie Dog for Grasshopper adds 3 great new features. First, the interface has been greatly simplified and now mimics the Grasshopper interface. Second, four sliders types are available: Floating Point, Integer, Even, and Odd numbers. Finally, Always on Top will keep your panel from getting hidden by other windows.
Learn more about it here: ryangathmann.com/prairiedog/Or download the latest version Food4Rhino: food4rhino.com/project/prairie-dog
If you have any questions or feedback I would love to hear it.
Enjoy!
…
e following is the shading control part of my .hea file generated from honeybee. I believe the 1 underneath represents the number of the states I input. When I switch both of the "1" within the .hea. The batch files would start the process but there is another bug for the gen_gdp_profile. It was having problem with .oct that it is looking for outside_daysim.rad which is not exist in the tmp within the folder.
I am still running the gen_dc and I will update it over if I encounter any error after editing the .hea file.
…
seem to find a working solutution. Doing this by hand is not a option, as I need to export up to 500+ dwg files, so any kind of automation is usefull.
So in essence I need to export 2 layers, with each layer containing a couple of crv's to DWG. The dwg should include this layers structure when opened
In the forum I found two components that should have this kind of functionality, but neither seem to work or is still supported.
I am currently testing with the TTtoolbox plugin and its CADexporter, however this does not support the export of multiple layers. Only 1 layer can be exported.
The Finches components could possibly be useful for export batch processing, but the component is not longer for download as the makers (http://www.nicholas.demonchaux.com/) website is offline. I am currently on Rhino 5, with GH 0.9.0075, so if comeone can share a gha file of this, that would be much appriciated.
Are there alternatives that are being used by the community that i am aware of? As this seem to me has been of use to more people…
me logic produced by running the 2-d voronoi component.
From a given set of polylines we can extract the centers and this can drive both the voronoi component as well as provide the XYZ drill points for the cnc. The definition has a variety of different options. You need Lunchbox, Weaverbird, and Starling. I can't tell you how amazing these 3 tools are from a design perspective. They are extremely powerful so if you don't have these you must install them asap. You can get the tools at http://www.food4rhino.com/
This definition works by first choosing a grid type, next you choose voronoi type, and subdivision type. From the voronoi type list you can choose basic (just grid), truncation (uses truncation calculated via the image sampler), truncation dual (uses the dual of the truncated image based grid), and subdivision (takes the basic grid type and uses different subdivision shcemes). Each of these provide different patterns of polylines from which we can extract our drilling points. I am rather proud of this definition since the overall idea is one which is so simple it's easy to overlook - the idea that drilling with a ball end mill makes voronoi plots. Now when you combine that with all of these amazing tools it can go off right quick. The nice thing is the paatern you see on screen is the pattern that gets made by drilling wysiwyg cnc patterns.
VORONIO_DRILLing.gh
Here are some on screen patterns in process in the following order truncation, basic, subdivision:
here is a video moving over a machined example:
…
.
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).
…
ut am trying to force myself to use it in all my projects so I can learn a little more each time.
I was lucky enough to get hold of a set of points depicting the site topography which have around 60m variance throughout the site, and have used this to generate a mesh giving me a surface. What i'd like to do is use this to create a load of layers trimmed to the mesh, then lay them out and number then so I can nest them and laser cut them.
I have seen plenty of waffle but I need to do this in a horizontal only layers which stack and i'm not entirely sure how to approach this. So far I created a bounding box and then measured the distance between the top and the bottom point to subdivide into the thickness of the material I have but then I became stuck, any help would be greatly appreciated.
Thank you for your time,
Richard.…
Added by Richard Gwilt at 1:37am on October 16, 2013
me" module. Strangely enough, the multi-threaded one runs remarkably slower, whereas the order of the printed results is senseless. Does anybody have experience on how to make it work properly? Already checked the post here.
import System.Threading.Tasks as tasks import time, math
#single-threaded
start = time.time() for i in range(1,501): print i end = time.time() print "single = ", end-start
#multi-threaded
iterations = 500 def get_i(i): print i start = time.time() tasks.Parallel.ForEach(xrange(iterations), get_i) end = time.time() print "multi = ", end-start
1. As (a) the values are printed in random order and (b) the computing time is high, are there any clues what i am doing wrong?
2. Is there a more accurate way to compute the required time for a command or a chunk of a script?
Thanks and best,
jnm
…