w number. If the script is slow you can also double click a number slider to access a panel that lets you slide a value without invoking a recalculation.
You don't need most of the inputs, which are for controlling the transition to the borders of open meshes. No, there's no manual beyond right-click help.
FixC and FixV are to fix and thus retain open borders, mostly, or sharp creases and there is art in them, meaning tricks you just have to blunder into or search for.
Flip is an alternative remeshing strategy worth changing from 0 to 1 to see the effect.
MeshMachine is only giving a nice even curvature-adaptive (Adapt setting 0.8 or so is more reliable than 1) mesh, merely, not thickening mesh wires into struts.
The struts are currently individual capped mesh cylinders. You could also use very slow nurbs cylinders. They may or may more likely not successfully Boolean union together in Rhino. Their diameter is set in the Mesh Pipe component.
There are other plug-ins for thickening the wires of a mesh. Exoskeleton, Intralattice and my favorite, somewhat tweaky Cocoon marching cubes which is however very robust, and I sometimes run the overly fine mesh result into MeshMachine to make it regular and adaptive, since the Cocoon refine component is hard to control. I mostly enter 1s into most inputs though.
If you turn on menu item Display > Canvas Widgets > Profiler and zoom in close enough to the canvas, you'll see timer readouts for how long each component took for a solution, so I can see that the pipes are the slow part, so I'd normally right click disable the chain early on, and right click turn on preview for the earlier mesh step before I make the pipes. The MeshMachine step takes only 2 seconds, and that's with Iter (internal iterations) at 10 instead of a workable 5.
Also turn on Display > Preview Mesh Edges to see the actual MeshMachine mesh.
…
ld see were the set of basic tutorials. I've run through a few other folk's video tutorials also.
The test case I chose, I picked because it is a super simplification of an actual space I'm trying to model (a large school sports complex - see below). Ive modelled it as a closed volume, with a few solid objects inside it, and it is a much less box-shaped space, with a ceiling that is not flat, and a significant lattice of acoustic panelling that encloses the roof trusses.
the volume of this space is around 50000 cubic metres, which if I followed the guidelines o0f 50-100 rays per cubic metre, would be 2.5 - 5 million rays. I ran a simulation on the test simplified box space with 100k rays, which took about 2 hours running on a macbook pro booted into windows. Perhaps I need to find a much more serious machine to run this on. would it be a reasonable assumption to think that as more rays are added, the results would converge on a particular solution? if so, if you had to take a guess, how many rays/m3 would be required to get a solid estimate of reverb time +/- 0.1s?
I don't mean to imply that Pachyderm isnt up to scratch - simply that I'm trying to find some way of determining whether a given set of simulation parameters are going to give a result that will be enough to make decisions about surface materials and treatments that will be required. I tried a bunch of different methods and simulation parameters to see if they were even remotely similar, and unsurprisingly, they werent. I'm not an acoustic engineer, I'm an architect who has studied some acoustics in addition to my regular subjects. I know enough to be dangerous, but I'm trying to convert that into enough to be useful. :). I'm totally open to any advice anyone might offer.
One last thing, could you confirm that the T-30 parameter is T-30 (and so needs to be doubled to get RT60)
Thanks for responding,
Ben
…
t'd be great.
I am trying in Rhino 5 and would like to understand where to get the documentation and get the feel for the differences.
Also, do you write such scripts directly in the component? Or elsewhere? How can one debug them?
Thank you for your help.
Option ExplicitCall Main()Sub Main() Dim arrObjects, arrMP, i Dim offsetSize offsetSize = 1 arrObjects = Rhino.GetObjects("Select curves to offset") If IsArray(arrObjects) Then For i = 0 To UBound(arrObjects) arrMP = Rhino.CurveAreaCentroid(arrObjects(i)) If IsArray(arrMP) Then Dim arrNewobject, strGroup, grpName arrNewobject = Rhino.OffsetCurve(arrObjects(i), arrMP(0), offsetSize, ,2) Rhino.AddLayer("offset") Rhino.ObjectLayer arrObjects(i),"offset" Rhino.ObjectLayer arrNewobject,"offset" strGroup = Rhino.AddGroup Rhino.AddObjectsToGroup arrObjects(i), strGroup Rhino.AddObjectsToGroup arrNewobject, strGroup End If Next End If End Sub
…
ask for some help and I sent the def to someone who tested the def out and made it work and send it right back to me and I got the same error I realized something wasnt right.
here some images of what the def does
Flat hexagonal panels over a given surface.
I get errors with the sliders and the VB script. Original script by Luis Fraguada from LAN then Davide del Giudice/ from madeincalifornia Checked out the definition because I have almost no knowledge with scripting and he made it work and sent those images back to me and this definition fixed, wich doesnt work on my computer and here some images of the problem.
and here some images of the problem.
…
a and we'll stop adding new stuff. At this point the Grasshopper version will be rolled to 1.0 Beta 1 and we'll keep on fixing serious bugs, resulting in Grasshopper 1.0 Beta 2 etc. etc. until the product is stable enough to be treated as a commercially viable product.
This does not mean Grasshopper will no longer be free. Robert McNeel & Associates (who develop and own the copyrights to Grasshopper) haven't decided yet whether or not to sell Grasshopper or whether to keep it as a free plug-in for Rhino customers.
As soon as Grasshopper 1.0 goes into beta, all development (apart from the odd bug-fix) stops and we start typing on Grasshopper 2.0. It will probably be a few months until the first 2.0 WIP version is released but basically the whole process starts over.
What are we looking to accomplish for 1.0 and which things are planned for 2.0 and beyond? The only major feature still missing in 1.0 is the Remote Control Panel. This feature was removed at some point and has been partially rewritten since then. Once it's finished, we consider the 1.0 feature set to be complete.
To be honest we've made very few concrete plans yet concerning 2.0, however it's clear that some things need to be at least seriously considered and researched. Here follows a list in no particular order:
Documentation System. This is one of the things we know we're going to do as we've already started. The Grasshopper help system will need to be rewritten and a lot of help topics need to be typed up. We have a pretty good idea what it is we want to accomplish with the new help and how we're going to go about it.
Vocabulary. Along with new documentation we'll critically analyse the current terminology and vocabulary of Grasshopper. We'll probably come up with glossaries and style sheets. We want to use words that are —at best— self documenting and —at worst— non ambiguous.
SDK and core library cleanup/improvement. Grasshopper was the first large scale product I ever developed and a lot of mistakes were made in the SDK design. A lot of functions and classes have been marked obsolete over time and many operations are not properly bottlenecked. I also want to add a lot more events so it's easier for code to keep close tabs on what's going on at any given moment.
GUI platform. At the moment Grasshopper is pure .NET winforms using GDI+ for all the interface drawing. There are certain performance issues with using large GDI+ surfaces and certain limitations on what we can and cannot draw. We will be investigating other graphics pipelines such as WPF, OpenGL, DirectX, OpenTK and whatever else seems promising.
Multi-threading. It is clear that some components are embarrassingly parallel, and since almost every single laptop and desktop has at least 4 cores these days it would be a shame not to use them. We will investigate what it takes to implement multi-threading as a standard feature.
Large file support. Grasshopper becomes awkward to use when a document contains more than a hundred or so components. We need to both improve the interface to provide methods for layering or grouping sub-algorithms and also add ways to reduce memory and computational overhead.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
three categories, each one corresponding to different shapeType_ input:- polygons (shapeType_ = 0): anything consisted of closed polygons: buildings, grass areas, forests, lakes, etc
- polylines (shapeType_ = 1): non closed polylines as: streets, roads, highways, rivers, canals, train tracks ...- points (shapeType_ = 2): any point features, like: Trees, building entrances, benches, junctions between roads... Store locations: restaurants, bars, pharmacies, post offices...
So basically when you ran the "OSM shapes" component with the shapeType_ = 2, you will get a lot of points. If you would like to get only 3d trees, you run the "OSM 3D" component and it will create 3d trees from only those points which are in fact trees. You can also check which points are trees by looking at the exact location on openstreetmap.org. For example:
Or use the "OSM Search" component which will identify all trees among the points, regardless of whether 3d trees can be created or not.However, when it comes to 3d trees there is a catch:
Sometimes the geometry which Gismo streams from OpenStreetMap.org does not contain a "height" key. Or it does contain it but the value for that key is missing.OpenStreetMap is free editable map database, so anyone with internet access and free registered account on openstreetmap.org can add features (like trees) to the map database. However, regular people sometimes do not have height measuring devices which are needed for specific objects as trees.So "OSM 3D" component will generate 3d trees from only those tree points which contain a valid "height" key.However, a small workaround is to input a domain(range) into the randomHeightRange_ input of "OSM 3D" component (for example the following one: "5 to 10"):
This will result in creation of other 3d trees which do not have defined height, by randomizing their height. randomHeightRange_ input can also be applied to 3d buildings, and it is definitively something I need to write a separate article on.
In the end it may be that nobody mapped the trees in the area you are looking for.
After you map a tree to openstreetmap.org then it will instantly be available to you or any other user of Gismo. I will be adding some tutorials in the future on how this can be done. But probably not in the next couple of weeks.
Let me know if any of this helps, or if I completely misunderstood your issue.…
Added by djordje to Gismo at 3:52am on February 8, 2017
option, after downloading check if .ghuser files are blocked (right click -> "Properties" and select "Unblock"). Then paste them in File->Special Folders->User Object Folder. You can download the example files from here. They act in similar way, Ladybug Photovoltaics components do: we pick a surface, and get an answer to a question: "How much thermal energy, for a certain number of persons can my roof, building facade... generate if I would populate them with Solar Water Heating collectors"? This information can then be used to cover domestic hot water, space heating or space cooling loads:
Components enable setting specific details of the system, or using simplified ones. They cover analysis of domestic hot water load, final performance of the SWH system, its embodied energy, energy value, consumption, emissions... And finding optimal system and storage size. By Dr. Chengchu Yan and Djordje Spasic, with invaluable support of Dr. Willian Beckman, Dr. Jason M. Keith, Jeff Maguire, Nicolas DiOrio, Niraj Palsule, Sargon George Ishaya and Craig Christensen. Hope you will enjoy using the components! References: 1) Calculation of delivered energy: Solar Engineering of Thermal Processes, John Wiley and Sons, J. Duffie, W. Beckman, 4th ed., 2013. Technical Manual for the SAM Solar Water Heating Model, NREL, N. DiOrio, C. Christensen, J. Burch, A. Dobos, 2014. A simplified method for optimal design of solar water heating systems based on life-cycle energy analysis, Renewable Energy journal, Yan, Wang, Ma, Shi, Vol 74, Feb 2015
2) Domestic hot water load: Modeling patterns of hot water use in households, Ernest Orlando Lawrence Berkeley National Laboratory; Lutz, Liu, McMahon, Dunham, Shown, McGrue; Nov 1996. ASHRAE 2003 Applications Handbook (SI), Chapter 49, Service water heating
3) Mains water temperature Residential alternative calculation method reference manual, California energy commission, June 2013. Development of an Energy Savings Benchmark for All Residential End-Uses, NREL, August 2004. Solar water heating project analysis chapter, Minister of Natural Resources Canada, 2004.
4) Pipe diameters and pump power: Planning & Installing Solar Thermal Systems, Earthscan, 2nd edition
5) Sun postion and POA irradiance, the same as for Ladybug Photovoltaics (Michalsky (1988), diffuse irradiance by Perez (1990), ground reflected irradiance by Liu, Jordan (1963))
6) Optimal system and storage tank size: A simplified method for optimal design of solar water heating systems based on life-cycle energy analysis, Renewable Energy journal, Yan, Wang, Ma, Shi, Vol 74, Feb 2015.…
..
The problem is that using the index, adding a activies, the next activies change the index and then the link is wrong.
example: I need to connect to hotel function with house function, therefore i have 0 and 4 index in my panel.. So i have to extract the index linked to the alphabetical value to be able to draw lines between the points associated to the names of activities. Now if i add a new string between the values, the house activity hasn't the original index 4 but the new index 5. So the link will be not created between hotel and house but hotel e new activity in the index 4.
…
The first is that XML requires that there be one root tag, where GH does not necessarily require their be one trunk to build its tree. In more GH specific terms, any XML document would always require that a path be {0;....} and there could never be a path like {1;...} or {13;....}. The fact that GH rarely does this is inconsequential, because its possible, so therefore has to be dealt with somehow. The first option is to simply have the component throw an error and not write the XML. That's fine, but in order to use the data you'd have to start remapping or splitting out your tree... not fun. The second option would be to wrap the data in a root tag so that the XML requirements are met, however this is manipulating the data that you're saving which I don't like. The third option, would be to write each root trunk out into separate files. The easiest option is 2, but I don't like modifying the data, although it would be possible to put attribute on that root tag to discard it if it was later read back into GH.
The second issue is that in order to write comprehensible XML, you'd need to specify the element names along with the values, which has the potential to be very cumbersome. In your case, you have all your tag names there and are just looking to modify the data that was in those tags, but this is definitely the best case scenario. If the ability is there to write xml, then that means it can come from anywhere in GH, not just from a previously parsed xml doc. Inevitably, assuming one would go through the hassle of creating names for all their xml elements, invariably there would be an path that would be missed, so what would you do as the name for that element? Throw an error? write out something else based on the path? Taking this to the extreme, would it be possible for someone just to supply data with no element names whatsoever?
In thinking about that last question, it would be nice if the GH path could be used for writing out the element names, but unfortunately both curly brackets and semicolons are invalid in element names (ie so <{0;1;0;5}>SomeData</{0;1;0;5}> is invalid because of the {,}, and ; characters. Element names also can't start with a number). So in order to write out an actual GH path, it would need to be transformed in some manner so that the previous example might look something like this <GhPath_0-1-0-5>SomeData</GhPath_0-1-0-5>
There are a bunch of other potential issues as well that would likely leave writing xml from GH in somewhat limited state. Some of those include enforcing/validating schema and supporting for other xml features(such as CData).
Ultimately, when I first wrote the xml parser I wasn't sure what people's needs were going to be in regards to using XML in GH. Based on the two main issues I outlined above, I chose to leave writing xml out for the time being. Its not that it can't be done (far from it actually), some decisions just have to be made pertaining to those issues. It does seam like it would be something useful, so I'll begin to look into adding it, and if you've got some other suggestions or preferences about which solution would be better, then sound off.
EDIT:
One thing I should note, all of my comments above pertain to saving xml. Once you've parsed an xml file, its no longer xml, its just regular data with GH which can be manipulated however you prefer. It would be entirely possible to to use GH's tree manipulation and list tools to move chunks of xml around, remap xml, etc.…
ack to .ghx?
This is in relation to a discussion I've been having with David Rutten & Scott Davidson about GH consuming memory in a relatively large GH definition (~. I think what I've learned from this is that one should limit the size of the GH file, or put some incremental stops in the definition to limit the length of calculations that it runs at once. Is this a valid conclusion?
The GH file we're talking about is 7Mb & the Rhino file is about 120Mb, but when working w/ the GH def. I try to only keep about 2 curves turned on.
Here's a summary of the discussion:
Hi Mike,thanks for sending it over. I've been fiddling with the file for about 10 minutes and it climbed from 1.7 GB to 1.9GB, but then I've been switching previews on which means more meshes get calculated so you'd expect a higher memory consumption. It is possible we're leaking memory, but if you're working for hours on end, memory fragmentation might also explain part of the increase. Basically, memory gets fragmented just like disks get fragmented after prolonged use, difference is that memory cannot be defragmented unless you restart the application and allow it to start with a clean slate. I'll try and find any leaks we may have missed in the past.Goodwill,David
──────────── David Rutten
On 09/03/2011 06:19, Mike Calvino wrote:
Thanks very much David for the quick response. I've attached the files zipped. I can't figure out what's doing it. After working in the file for awhile, the memory usage in the Windows Task Manager climbs . . . it's gotten to 1.57+Gb before I exited GH & Rhino5Wip & let it dissipate, then restart & work for awhile before it does it again. It probably takes like 4 or 5 hours before it gets that high. That's the highest it's gotten, & that only happened while I was working in a Rhino file that had all of the elements baked into it - turned off at least, but it still climbed to 1.57+Gb. It seems to climbs when you work in the file & move around in both the GH def. & the Rhino file. Like turn on a few of the Extr components at the right end of the "StandareRibExtuder" groups, you can watch the MemUsage go up, but when you turn them off, it does not go down. - goes up fast at this point. Maybe I need to figure out how to do the definition with fewer components, I'm sure that's part of it, but I must confess, I think I'm still early on in the learning curve.I really hope that this is not operator error on my part & I do apologize up front if it is. I have done a disk cleanup, I have tried excluding .3dm & .ghx files from my NOD32 antivirus, no change. I hope you can find something.Let me know if you have any trouble with the files.See if you find anything & please let me know . . . thanks!Cheers! --Mike CalvinoCalvino Architecture Studio, inc.www.calvinodesign.com
…