ere are ways to remap the data (PathMapper etc) and there's an excellent tutorial by David Rutten about path mapper on this forum somewhere.
And always look at whether you simply need to flatten your data to ba able to work with it.
For point lists I often use the PointNumber component to help visualise the data and the good old Panel component helps too!
When you see some of the elegant, compact definitions on here, there often seems to be some mystical foresight needed right from the first component but hopefully this jedi skill comes with practice!…
Added by martyn hogg at 12:24pm on January 13, 2014
e 7555, in callFromHoneybeeHive, "<string>" line 94, in main, "<string>" line 126, in script
(Swedish errormessage translation: "selected key does not exist in the lookup list")
I dont get any error messages in either LB or HB. HB says it has all libraries in its text output.I'm using a vanilla install of Win 10 with standard win firewall unaltered. I have a feeling it has something to do with files not downloading all the same.c:/Ladybug does not exist.
Picture shows contents of roaming/ladybug folder. is something missing?
This is what i've done so far:
Followed all the steps on the install instructions.Uninstalled and installed it again running in administrator mode.
Tried to get files from this thread, but links are broken to download those outdated files. I think I remember I usually have to do this when i do HB installs on new OS...I have not installed open studio, only energy+…
o be less from a tool-centric perspective, and more often geared toward general platforms (like BIM, or "computational" design).
For papers, I would search Cumincad first, as it captures a great deal of history as well as more current research from the proceedings of the eCAADe and ACADIA family of conferences. There are thousands of articles there.
Robert Woodbury's "Elements of Parametric Design" is considered pretty foundational. Sean Ahlquist and Achim Menges also put together a good anthology a few years back called "Computational Design Thinking" that collects several texts that are in line with the ICD's interests in biomimesis and emergence. "Inside Smartgeometry" is a good combination of theory, historical reflection, and state-of-the-art and edited by Brady and Terri Peters.
But really there is so much out there! One of my favorite short papers is Tom Maver's "CAAD's Seven Deadly Sins" which was basically a keynote mic-drop at the 1995 CAAD Futures conference. I'll spoil the end for you:
"7 Failure to criticise: Above all we have failed to exercise our critical faculties in relation to almost all of the research and development carried out by ourselves and by our peers in recent years. There has been a cosy conspiracy in the community to condone, even encourage, selfindulgent speculation and solipsism - a thoroughly bad example to set for young people in the academic community.
Conclusion: Perhaps these criticism are unjustly hard. Hopefully CAAD Futures 95 will prove me wrong or at least provide the opportunity for discussion."
…
Added by David Stasiuk at 11:10am on August 25, 2015
tween them)
However its not possible (Well its very tricky) for me to go back to the original geometry and merge the perimeter and the core into one zone.
As a result I thought that adding internal glazing would do the trick. However apart from using the addGlazing component I couldn't see any other way of adding internal glazing to the core zone without exploding it and putting it back together. So I modified the Glazing based on Ratio component so that the internal walls of the core would automatically be 95% glazing.
After passing the core zone through the modified Glazing based on Ratio component and then passing all the HB zones through the Solve Adjacency component I ran the daylight simulation. However the result is not what you would expect it appears as though there are no internal windows. (See the picture).
So two questions.
1. Is there a better way to merge these zones for a daylight study without going back to the original geometry?
2. From the illuminance map it appears that no light is passing through the internal windows. Why is this the case? Should I create a material that is like air so that the light can effectively pass through and then use this material instead?
…
ple I have to drag it through a panel before I can use it as an input to my python script. The supports comes as a list of strings (see figure) and I want to extract some of that information (e.g. what nodes are fixed) and write that to my txt file.
I extract the info with these lines:
for row in Support: node = row[8:row.find(' DOF')] file.write(" %s,\n" % node)
print node
>> 95
If I however don't drag it via a panel i get the following output:
for row in Support: node = row[8:row.find(' DOF')] file.write(" %s,\n" % node)
print node
>> Supports.Suppor
It's like the script doesn't get that each row is a string.
I have the input set to "list access" and type hint to "str" and I've tried to simplifying and flatten the list.
Greatful for help…
can be found in "C:\Documents and Settings\<user name>\Application Data\McNeel\Rhinoceros\5.0\Plug-ins\IronPython\settings\lib\rhinoscript" folder on WinXP. So could have used yours too.
RhinoCommon is a SDK and basically the power behind grasshopper and rhinoscriptsyntax functions. In fact each time you call a rhinoscriptsyntax, a RhinoCommon code gets executed.
And, yes:
import Rhino - imports RhinoCommon
import utility - enables importing utility.coercebrep() (or coerce3dpoint() coercecurve() ... so on)
Item access means an input is consisted of a single item.List access means an input is a list.Tree access means an input is consisted of a tree with data on different branches.rs.BooleanDifference requires both of it's arguments to be lists, so it would be logical to set the inputs b1 and b2 as lists. But there is one problem, that Mitch pointed out to me: it seems that python components (like grasshopper components) are "intelligent", and can distinguish whether you are inputting item, list, or tree. Setting your input as list, might disable this ability and leave you with only possible type of input (list).So honestly I do not know why in this case, setting the inputs to Lists worked - due to mentioned "intelligence" of python component, even an Item type would work.This might be a question for an experienced user, I am just a beginner.…
answer further on Friday.
The "ghdoc" variable and rhinoscriptsyntaxThe ghdoc variable is provided by the component if you select it as "target".You might ask yourself: "why do we need it"?Its use comes from the very design of the established RhinoScript library. This library is imperative, which means it is build from a set of procedures or functions that act on various geometrical types. Additionally, there is one level of indirection: most of the time, the user does not work with the geometry itself in the variable, but rather with Guid of geometry that is present in a document. This is exactly what ghdoc is: it is the document that the RhinoScript library always implicitly targets with all AddSomething() calls (for example, AddLine()).
Based on this comment...RhinoScript use within GhPython may be less idealThat comment is from a previous version of this component that did not have the ghdoc yet.With the ghdoc variable, the standard Rhino document target of RhinoScript is replaced, therefore we can use Grasshopper while leaving the Rhino document unchanged. This saves uncountable Undo's, and makes it easy to structure ideas through the definition graph
...is the rhinoscriptsyntax target irrelevant if using solely RhinoCommon classesYes. If you create class instances (objects), you will need to create also your own collection objects to store them (mostly lists, trees). You can imagine the ghdoc as being an alternative to them, just that you do not access data by index (number), but by Guid. So you can use the RhinoScript or the RhinoCommon libraries independently or mix them. The RhinoScript implementation in Rhino is open-source and is all written in RhinoCommon. Also the ghdoc implementation is open-source, and is here.
RhinoScript and/or RhinoCommon objects which are not recognized as valid Grasshopper geometryYes, sure, Grasshopper handles only a portion of all available types. Basically, unhandled types are all the types that do not exists in the 'Params' tab. For example, there is no textdot and no leader, so on line 149 there is a throw statement and all TextDot calls (about line 350) are commented out. When/if Grasshopper one day will support these types, these calls will be implemented.
DataTreeHere is a small sample. However, I think that 80% of the times it is not necessary to program for DataTrees, as the logic itself can be applied per-list and Grasshopper handles list-iteration.
I hope this helps,
- Giulio_______________giulio@mcneel.comMcNeel Europe…