ne. Though I suppose providing a help file which lists some useful tricks for some operations would be a good place to start.
It would be possible to add persistent undo to Clusters, and it wouldn't even be that difficult. Adding undo data into the GH file is something I've been meaning to add since the first day of undo/redo, and the plumbing is in fact there, but it was never fully hooked up. I will definitely try this for GH2. And I'll also have a think about how to implement version history for clusters.
Phew, my brain hurts even just to think about this. I suppose step one would be to write a clever merge algorithm for two files that have some things in common and some not. But even that will be tricky as heck.
This is a major problem. First of all, running the solver in a thread and keeping the UI alive will only slow things down even more. On a file which takes 15 minutes to solve that's no big deal, but you certainly don't want to be adding a 20 millisecond delay to a solution which only takes 30 milliseconds.Multi-threading will be something I'm going to try and implement in GH2, but there's only so much I can do. If you run a solid boolean operation on a boatload of shapes, it's a single operation that is performed inside Rhino and there's nothing I can do to make it run on multiple threads. This is in general an issue, sometimes it takes a long time because there are many operations to perform; like offsetting 2500 curves. I can probably multi-thread that provided the Rhino curve offsetter is thread-safe. However stuff may also take a long time because there is a single operation (like the aforementioned huge solid boolean).Lastly, I have no way to predict how long a component is going to take. I can probably work out how far along in steps a component is, but not how far along in time.
What would you do with a solver which runs in the background? How does it differ from only running solutions when you want to? Let's say the solver is threaded and the canvas remains responsive. As soon as you make a change to the GH file, the solver needs to be terminated as it is now computing stale data. Wouldn't it be just as effective to disable the solver, make all the changes you want to make, then press F5?
Just because something runs in a thread doesn't mean you can shoot it in the head any time you want without consequences. Aborting threads typically means setting a boolean somewhere and then letting the thread commit suicide, while performing all the necessary cleanup. If you just destroy a thread there's no saying in what state you leave the memory.
I think a good place to start with these sort of problems is to keep on improving clusters, add more flexible structuring UI such as Layers or Filters or Pages or whatever to the canvas, add ways to share data between remote parts of a file without suffocating the display with wires, and to provide easy ways to temporarily disable parts of a file (think of it as Clipping planes for GH). That way you can make local changes and see local effects before solving the entire file again.
I'm certainly impressed by the sheer extent of the file you people made, it will be a lovely test case for UI improvements.
--
David Rutten
david@mcneel.com
Tirol, Austria…
Added by David Rutten at 3:34am on September 4, 2013
er" logic but it miss when comes the copy or offset.
Here is my following logic
Take the square of 25 m x 12 m ; make it a surface
I divide it in "blades" of 20 cm
I take the edges of the "blades",
I divide this edges in 40 points (or equivalent) (A)
I identify my curves (curves) which are on the floors, which are curves (B)
First i do this "test" :
for each crossroad between A and B, i make a circle of X cm (slider) of diameter and the rule is the following :
* In this circle, the future movement of my A curve must be at Z = 0
Second step :
for each next point, i have to : leave a copy on Z = 0 and rise the second one for a heigh of Y cm (slider) from the ground.
the next (W = slider to chose every each number of point, i decide to do the following point) point, which is a little bit farer from the previous point, must duplicate the same height of Y ; and also be copied to Y + Y cm.
There is a Z number (slider) which is the max height possible for these points, which mean that the next point must be at this very same level except ... The third step scenario.
The purpose is to be able to have flat area, like step in a stairway.
Third step :
The grasshopper must test if the A points are between two or more "area at Z = 0". Why ?
The goal is to obtain something like screen "side view" if there are two starting points at Z = 0.
Which also mean that if there is an odd number of points, the remaining odd number must be at the top of the "stairs"
At this point of the grasshopper, we might be able to obtain, thanks to the sliders the "staircase form" regarding :
- The size of the test circle between A and B curves
- The "footstep" of each points (height)
- The number of points before a "copy of the point + the next footstep rise"
- The max heigh possible for all the point off B curves
And at this moment i have a new problem in my logic. You will get my idea, but it might be wrong as well...
Therefore, and after that, we should be able to link every point by a straight line.
To fillet with P (angle) a line with the following one
To join all the line of a same B curve
To cut it at the center of each circle at Z = 0 (the crossroad of A and B)
To offset it with Q (distance)
To rise a line from the center of each circle at Z = 0
To cut the extra part of each Offset"ed" curve to get an offset curve "aligned in Z" with the original one.
To create loft the original and offset"ed" one
To extrude the surface to a distance of R
And grasshopper "should be done" because, i will duplicate it for the ceiling, reverse the form with a -Z vector to the Y value and modifie my Z in Z' to modify my max height
Could you help me ?
…
ly one (Cost of the structural material in my case) and penalize the individuals that not satisfy the structural verification by multipliyng the cost for that iteration for a factor 10. This seem to work really good, infact I obtained a convergence of the results in a specific area and number of beams.
Now, I've to modify something because the thickness of the insole, tend to minimum of the range (only because it's the most expensive material in my case), despite the validation of structural verification that is satisfied with the maximum height of the beams.
I'm expecting a insole thickness about 20-30 cm and beams height less that the maximum. I increase the range of the thickness insole to a minimum of 20 cm, but I hope the solution tend to a larger value.
Do you have some suggestion in this case?
Your post was really helpful, thank you so much again for the perfect explanation!
Leonardo…
onents (radiation, sunlight-hours and view analysis) which let you study the effect of the orientation of your building and the analysis result. When you come to a question similar to "what is the orientation that the building receives the most/least amount of radiation?" is probably the right time to use this component.
HOW?
I'll try to explain the steps using a simple example. Here is my design geometries. The building in the center is the building to be designed and the rest of the buildings are context. I want to see the effect of orientation on the amount of the radiation on the test building surfaces from the start of Oct. to the end of Feb. for Chicago.
First I need to set up the normal radiation analysis and run it for the building as it is right now. [I'm not going to explain how you can set up this since you can find it in the sample file (Download the sample file from here)]
Now I need to set up the parameters for orientation study using orientationStudyPar component. You can find it under the Extra tab:
At minimum I need to input the divisionAngle, and the totalAngle and set runTheStudy to True. In this case I put 45 for divisionAngle and 180 for the totalAngle which means I want the study to be run for angles 0, 45, 90, 135 and 180.
[Note1: The divisionAngle should be divisible by totalAngle.]
[Note 2: If you don't provide any point for the basePoint, the component will use the center of the geometry as the center of the rotation.]
[Note 3: You can also rotate the context with the geometry! Normally you don't have the chance to change the context to make your design work but if you got lucky the rotateContext input is for you! Set it to True. The default is set to False.]
You're all set for the orientation study, just connect the orientationStudyPar output to OrientationStudyP input in the component and wait for the result!
The component will run the study for all the orientations and preview the latest geometry. To see the result just grab a quick graph and connect it to totalRadiation. As you can see in the graph 135 is the orientation that I receive the maximum radiation. Dang!
If you want to see all the result geometries set bakeIt to True, and the result will be baked under LadyBug> RadaitionStudy>[projectname]> . The layer name starts with a number which is the totalRadiation.
Mostapha…
her people) a tremendous amount of time creating them by hand. Dog Treat was far from perfect, however it was good enough to use almost daily.
Three years is a long time. Since 2016 my Gh knowledge has expanded and I’ve seen how dodgy some of the scripting is. With this in mind I started work on a new build. Many things have been tweaked and some things have been rebuilt from the ground up.
Everything has been designed to be leaner and be a general solution to the problem of creating dog bone corners on geometry for quick, efficient and safe CNC fabrication.
Some of these things are:
Adding prompts about user geometry to make them aware about open curves, varying curve heights and if their geometry had been altered (mostly removing unnecessary points on curves).
Smooth Transfers. If you’re in a rush and need to speed through cutting, smooth transfers mean that a lead in geometry is now created alongside the actual dog bone arc. This means the router bit doesn’t have to come to a minute stop at every corner. This is turned on by default.
Acute Angle Condition If the angle between the two curves adjacent to a dog bone point is acute, previously the dog bone corner was useless. This was because the distance between the end points of the dog bone arc were less than the diameter of the router bit. There are many ways this condition could be addressed. I chose to circumscribe a larger arc based on the original angle between the adjacent curves. While it removes more material from the corner, it minimises tool wear and any potential for material to burn.
Single Curve A single curve can now be input into Dog Treat. It will be output with both internal and external treatments.
I’ll continue to update Dog Treat as the need arises, it’s become somewhat of a hobby now. Maybe one day it will become part of a Plug-in… once I learn to code it though!
Happy Treating!
Hi Everyone,
Here's a tool I've been working on for the past 4 months or so in my free time. It's a dog bone corner generator, however it's a little different to some of the existing ones. It's designed to be used for large amounts of geometry and as such, it avoids using any curve boolean operations that are computationally taxing. You don't have to split your curves up into internal and external lots either, it works it all out so you can be lazy. I've also incorporated Lunch Box's Object Bake Component for a one click operation that bakes geometry back out to Internal and External profile layers.
Let me know how it goes, will update where necessary.
Best,
Darcy
Change Log
06/11/19 - Version 2.0 SECOND DINNER - Rebuild
29/09/17 - Version 1.3 - Now with smooth corners option, True for smooth default/False for original
18/05/17 - Version 1.2 - Now includes variable angle domain input (defaults at 90°) for angled corners
13/11/16 - slight change to enable acceptance of very large interior curves
…
Added by Darcy Zelenko at 8:44pm on November 9, 2016
he example file to this file so you can give it a try with any version of Honeybee that you're already using. The only requirement is to have OpenStudio installed as the component is using OpenStudio libraries to parse gbXML files. If you're using the latest version available on github the component is also available under WIP tab.
Why?
The main purpose of developing this component is to save time and effort for importing Revit models for energy and daylight analysis. It bothers me to see a lot of smart people spend a lot of time to just come up with solutions just to get the geometry from Revit to Honeybee for analysis. This component is not solving all the issue but is a first step forward. In an ideal world, the future version of Honeybee, which works both under DynamoBIM and Grasshopper should address this issue but that can take some time to be fully ready!
How?
To use this component you need to Export your Revit model as gbXML and then use the file path to load the file into Grasshopper. There are several resources available online on how to prepare the analytical model in Revit and export the gbXML file. Here is an image for importing the Revit 2017 sample model using the default settings. As you can see the model will be just as good as what your original gbXML file from Revit is.
What can be improved?
Well, there are several items that can be improved and they are mostly not on us. To get it started I add what I think are the 3 main shortcomings and my thoughts on how they can be addressed in the future. Feel free to add what you think needs to be added to this list in the comments section.
1. Revit analytical models and as the results gbXML files, by design, are not intended to be clean. Watch this presentation from the Autodesk University to see the logic behind this approach which in short is it doesn't matter for a large scale early stage energy model. Well, This will be quite a problem for studies that you can do with Honeybee. Included but not limited to daylight and comfort analysis.
The best solution that I can think of, until Autodesk fixes their exporter, is to use Revit Rooms and Spaces and generate a clean model from the scratch. We have already tried this approach in Revit but since the Revit API doesn't provide access to Room openings we had a very hard time to get it to work.
That's why that I opened an idea on Revit ideas to get over this issue. With your support we already have 81 votes, but it hasn't been enough to make them to consider the idea for an official review. If you haven't voted already and you think this will be a helpful feature take a moment and vote so we can have it implemented at some point in the future.
2. There is no way (that I know) to export only part of the model. The way export gbXML is set up in Revit is to export the whole model once together. As a result, if you have a huge model with 100 rooms and you want to get one of the rooms into Honeybee using this component you have to export the whole model, which can take some time, and then import them all back into Grasshopper. To partially address this issue I added an input to the component that allows you input a list of names for rooms that you're interested to be loaded into Grasshopper. You can use the name of the room/space in Revit as an input for the component.
3. The component doesn't import adjacencies, loads, schedules and HVAC systems. I wasn't able to export a gbXML file from Revit with any of this data except for the adjacency, but even if you can do that, the component currently can only import geometries and constructions. I hope we get access to 1 and so we don't have to use the xml file approach at all, but if that takes a very long time then we will add these features to the component.
Happy 2017!
Mostapha…
cribes a set of machine movements in X, Y and Z (Z being Pen Up and Pen Down) directions. It very closely related to G-code in this way - just slightly more simple than G-code overall.
For tool selection you use the Select Pen - SPx - command, x is the number of the pen you are using. As I'm using a vinyl cutter without a pen/tool changer I just use SP1 in the file header/ini of the cutter.
Without knowing the full spec of your machine it is hard to say for certain BUT all of my experience with CNC machines - of all sizes and spec levels - the actual control files are pretty much the same. Very simple text based HPGL or G-code text files run all motion control - even on things like 7 axis robot arms etc. For plotting I'd expect you'd be able to get a usable HPGL/PLT file without a lot of work - its just a matter of matching the file to what the machine is expecting.
To answer your question about getting the file to the printer its maybe best to explain it this way: there are two parts to this project1/ Create the correctly formatted text/hpgl/plt file ready to send to the printer2/ Send the file to printer
For part 1/ the procedure is:
Select the curves you want to printConvert the curves into a set of pointsFormat these points into HPGL Save this HPGL as a text file
For 2/ we need a way to stream the text file to a printer port
To do this I've used an old dos command line technique that allows allow you to 'copy' a text file to a printer LPT or COM port:
copy /b c:\spool\ini.plt LPT1
Type the above into a DOS command line and it will send a text file called ini.plt to the printer on LPT1 port. As you'll see in my attached code I use os.system calls in my python code to send files when needed.
So your original code was doing some strange things with the conversion from curves to points. Lines/Polylines were OK - with the code just using the line end points. For curves and polycurves the code code was exploding these into segments and then dividing into set of points. However this led to two issues: - curves that started off as closed polycurves would end up being plotted as open curve segments - which is not very good for a cut file and not very smooth for a plot file.- the division of the curves to points was by distance - and if this wasn't an exact division of the length of the curve the end point would not match up with the next line - again not ideal for a cutting file which needs to be a closed curve.
To solve the above I changed to using rs.ConvertCurveToPolyline - with the tolerance set to match the HPGL resolution of 0.025mm - this converts all curves needed to plot to polylines, leaves everything closed and ends points line up perfectly.
I had one other problem with my setup - I ran into a file size/curve number/plotting points upper limit. A small number of curves would cut/plot fine, however at a certain number in one file the print driver would throw an error and the plotter would not even start plotting the file. I could not work out where is the system this limit was being imposed. The current working version of my code is attached - it gets around this file size limit by creating a separate print file for each curve required and sending them to the plotter in sequence. Not as completely tidy as I'd like as it flashes up a cmd window on every loop - but plots/cuts are perfect.
The final 'nice touch' for the project is I've created a custom tool bar button to run the script - all I have to do to cut a file is hit the button on the tool bar, select the curves and hit enter = SO EASY!
I've attached my latest code, a sample HPGL file to plot a rectangle, and a screen shot of setting up the custom toolbar button.
Cheers
DK…
gap as for a 20 meter gap, it's not a good argument.
I fully concede that not every single thing may be backed up by logic. There are simply too many design decisions to make and not enough time to make them rigorously. And I do believe there is place for human intuition and art in architecture, but I also think that artistic (or intuitive, or emotional) considerations should clearly be labelled as such.
When Le Corbusier designed the urban layout of the city of Chandigarh he used his intuition to distribute the buildings and clusters. His intuition however was grounded in European climes and it failed him in India. On hot days it becomes almost impossible to walk the distance between them. Would Chandigarh have been a better place if the maximum distance was defined by the largest walkable distance on the hottest day of the year instead of the unjustifiable intuition of the designer? I suspect it would.
Furthermore, I believe that architects - student and professionals alike - regularly make formal decisions according to their aesthetic judgement. To suggest that students aren't qualified to make a design decision during their studies because they think it's formally successful seems exceedingly stingy;
There are plenty of rational decisions which are made by tacit processes. People can become very good at mimicking rational behaviour using intuition. And -as I said- if you are an architect with a distinguished career; if you've already proven yourself to be capable of good design then there comes a point where your intuitions can be trusted (to an extend).
But students whose every design has always been virtual, who have not been able to evaluate their decisions by a follow-up study, I don't see how anybody can trust their instincts. Instincts aren't just sitting in someone's brain, they are cultivated by relentless exercise and trial-and-error. Until you actually build something there is no error, only trial, and virtual trial at that.
I find architects' attempts to justify what are obviously decisions based on formal taste using other means often taking the same form of obfuscation that makes architects appear to be intellectual charlatans to specialists in other fields.
I fully agree here. If there are non-communicable aspects to a design, just say that. There's no shame in it as long as you're honest about it and have considered -however briefly- the consequences in case you're wrong.
I'm by no means advocating that all architects must master every detail in their work. Rather, that architects have at least a generalist's working knowledge of materials and construction systems. Floors don't levitate, and windows require depth; rules of thumb count as vital knowledge.
I think we're on the same page here. If you want to make a physical building, then there's more to it than pure design. Engineering comes into play. I don't mean to imply that engineering doesn't require creativity or even artistic intellect, but it is a different kind of problem-solving.
I fully agree with your fourth point. I just wasn't sure what performance-driven meant.
--
David Rutten
david@mcneel.com
Tirol, Austria…
Added by David Rutten at 4:19pm on August 14, 2013