other ordering mechanisms. If you feed layer names in explicitly, output is grouped by layer. If you feed multiple types or multiple object name filters, output is grouped by these instead, following standard data tree behavior. There are a number of ways to achieve layer-based sorting of objects using existing components:
Letting anything be organized by the layer-palette order is extremely sticky, since it can be re-ordered on the fly by various sort mechanisms. See more on this topic in my conversation with Tim Halvorson in the comments on the Human Group page. As it stands now I do not alphabetize layers in the layer table component as you say - I use the layer index, so that as new layers are added/rearranged, the entire order of the set doesn't change in unpredictable ways. If layer sort order is preferable to you, you can use the simple one-line script I provided Tim in order to retrieve the sort index and use it to sort your layers. My priority for both object order and layer order in the components is to minimize unnecessary changes/refreshes/event listening by returning everything exactly as the SDK gives it to me.
(3) I've added the Include Locked and Include Hidden options to the latest release attached to this post. However, this only pays attention to hidden objects, not hidden layers. I do not want to include a toggle for "Include Hidden Layers" because this would force the dynamic pipeline to expire every time a layer's visibility changed, which I do not want - for most purposes this would cause unnecessary recomputing. However, with the components as they exist now, you can drive the dynamic pipeline with a layertable set to auto update, like so:
This has the effect I think you are after, which is to ignore objects on layers that are hidden - and recognize them as soon as the layer is turned on.
…
: read below.
1. Using code for the random pts on BrepFace (yours + some holes to spice things a bit). Main reason? Well ... to control the miin distance (critical for engineering purposes). The other one is that you can disable the "even" distribution option and get random points as Fate brings them to us. That said David did a fantastic job on the equivalent native populate component.
2. Then the points are "elevated" (or not) according a user defined Z range. Reason? Well ... Plan B that is (making a tensile membrane system instead of that pessimistic "vault" thingy [ideal for funerals, mind]).
3. Then a user controlled (with regard what mash faces to kill) Delaunay mesh is created. Viruses in the mean time are placed around (you can use any block you like - see BlockManager). C# that does this is independent from the main action (but it doesn't work if the named block specified can't been found). Then the mesh is subdivided further (for obvious reasons). You can switch off this stage (that feeds finally Kangaroo 099). That said increase the N or viruses and spot the response time: this is the only way to do proper business with "identical" objects (same applies for truss members and for any collection of things in fact).
4. Then you double click on the 099 and Daniel does the rest.
BTW: As I said earlier the Anchor picking policy sucks. V2 does this properly.
BTW: Load R file first (and use Named Views).…
s can result in some unexpected (to me anyway) results. What can happen is it produces a "waist" in the twisted result which I guess should be expected but is not always desired. Here is an example of how I used it twice in the same part: http://www.thingiverse.com/thing:1601550
2. I took out your code at bottom right because it just didn't seem to be needed for the filleted surfaces I made. Of course I could be wrong about this - the fillet function is clearly very sensitive to points of discontinuity, so maybe I got lucky and just stumbled on a few values that worked.
And yes, I know about how sensitive ruled and lofted surfaces can be. I was pleasantly surprise to discover some of those problems can be fixed by reversing an edge curve 's direction. The concept of a curve's direction had never occurred to me and, as you pointed out, I learned about it from some posts in this forum.
And would you believe my first job after graduating was in the Loft Lines department of an aerospace firm? There is some irony there I think.
3. I'm not sure what to say about the green surfaces in your image. My guess is they are the result of some quirks in the filleting or lofting code that have to do with connections between curve and surface segments. I spent many hours trying to get continuous, smooth surfaces lofted from what appeared to be smooth edge curves so I could make objects like this: http://www.thingiverse.com/thing:1596100. I finally was able to find a method that worked - again, adapted from something I found in a post here.
4. On my printed part there is no fillet between the side and the top. It just looks like that because the part is small and no printer can make truly sharp edges. It is just melted plastic after all. I have made parts with top/side fillets and I think those look much better than ones made without them (http://www.thingiverse.com/thing:1118050) , but again it requires some extra fussing to get the filleting to work properly.
…
ot in parallel: simpleFoam, and the the it converges after 1769 iterations:
Several new folders were created in the case folder:
I opened the case file in PareView, which gives the following error message:
Nevertheless, the results can still be visualized, but I'm not sure if the visualization is correct:
... and additional error messages keep coming out:
Hope you can kindly advise if the results are correct and what to do with the error message during visualization in ParaView.
Thank you very much!
…
sion app (Modo, Z Brush etc) in order to get "as equal" as possible mesh faces.
For instance ... see a W depth truss (tri mesh > meaning that the "out" grid is hexagons) out from a Kangaroo "inflated" mesh:
2. A space frame is NOT a collection of abstract lines ... meaning that clash members detection (via trigonometry and NOT by checking boolean intersections) is far more important than the "concept" it self. If "live" alterations are required for addressing local clash issues ... well ... that's 100% impossible with native components.
See a typical clash detection capability:
3. A truss without proper connectivity Data Trees means nothing in real-life (vertices to edges, vertex to vertex, edges to vertices).
4. Each "standard" truss member (say: sleeves, cones and the likes) should be an instance definition placed in space according appropriate orienting planes. That way you may be able to handle thousands of components that in real-life participate in any truss of a certain size.
All the above are far easier to do with code (V4 is impossible with components).…
he grouping of the sliders on the remote control panel.
4. Separate viewport(look at picture)
5. Cluster editor new wish
My version grasshopper 0.8.0004
Best Regards,Valentin
Kiev, Ukraine
…
fsetted (to create an inner ceiling), and on the ground i lofted the curves also(floor).
I would like to create a random pattern of points on the ground-surface that pulls the off-setted, "inner roof" towards the ground, creating pillars resembeling to the bird skull section (picture 3). Preferrably in several "floors" if possible.. (like in the picture)
If anyone has a better suggestion on how to create the bird-skull structure inside my shapes, you are very welcome to say so!
I have only worked with grasshopper for a couple of weeks, so if you explain something, please do it step, by step, so that I can follow:)
Peace, thank you and keep up the good work everybody!!
/s …
400m swatch from a point somewhere in Catalunya.
The three APIs used were the following:
Google Elevations API
Mapquest Open Elevation Service API
Geonames SRTM3 API
I also tested the USGS Elevation Service, but I was looking for API which allowed me to query globally.
Here are the results (441 locations queried):
As a side note, Grasshopper reports the requests for data came in at*:
1.9s for Google Elevations API
3.5s for Geonames
413ms for Mapquest
*this is not only measuring the request, but also has to take into account the request throttling due to the various API limitations.
As you can see, there is quite a difference in the data, especially when looking at what Google returns. It is pretty clear that Mapquest and Geonames use very similar data coming from the SRTM3 dataset. This dataset is at 3 arc-seconds (appx 90m) for most of the globe (up to 60ºN and 56ºS). The resolution is 1 arc-second for the United States. Google reportedly uses hundreds of data sources to achieve a finer resolution, though this comes at a cost. Geonames and Mapquest put a limit of how many locations you can query at one time, with no limit per day (that I could find). Google puts a limit of 2500 requests per day, with each request having up to 512 locations, or a total of 25,000 locations.
The comparison was made possible by some of the little utility components which are included in gHowl, namely the XYZ->GEO component which translates points in Rhino/Grasshopper to WSG84 coordinates. …
ulio´s latest bakeAttribute, so it also sets a specified layercolor?
Thanks,
Phillip
Reply by Giulio Piacentino 1 hour ago
Hi Phillip
if possible, you should try to modify layer colors independently from baking. A layer can have only one color, but many objects.
To modify a layer color, use something along these lines:
if(!string.IsNullOrEmpty(layer) && !color.IsEmpty) { int n = RhinoDoc.ActiveDoc.Layers.Find(layer, true); if(n < 0) return; Rhino.DocObjects.Layer l = RhinoDoc.ActiveDoc.Layers[n]; l.Color = color; A = l.CommitChanges(); }
Can I also ask you to start a new discussion next time? I hope this helps,
- Giulio
…
lp you much, getting a single fast core is a much better choice. Fast and lots of memory also helps a great deal.
In the near future, the processes that would benefit most from it in Rhino and Grasshopper actually lend themselves remarkably well to multi-threading. Things like Intersections, Meshing, operations on individual items in arrays would all benefit since they involve a lot of repetition where one iteration does not depend on the previous one.
Rhino4 was not designed to be threadsafe, and there were places where it was not possible to thread certain tasks. For example, imagine the Contour command. You'd think that it would be a piece of cake to thread that, you assign the first 25 contour intersections to core 1, the next 25 to core 2, the next 25 to core 3 and so on and so forth. But as it turns out intersecting a Brep and a Plane requires Rhino to build a spatial tree of the Brep first (assuming it doesn't exist yet). These trees vastly speed up a lot of operations and they are created lazily, meaning they get created the first time they are needed. Now we suddenly have four threads all trying to run a Brep Plane intersection and all trying to build the same spatial tree at the same time. This cannot end well. So in Rhino5 we made sure that when the spatial tree is getting build, every other thread that tries to access the Brep gets put on hold until the tree is done.
Then there's problems that the Intersection function might store temporary data on the Brep during the intersection, which makes threading intersections on the same Brep an absolute impossibility.
Then there's the even worse problem that the Intersection function might store temporary data in a static cache, which means you cannot run the function more than once at a time, even if it's on different Breps.
In Rhino5 we tried to rectify all of these problems. I think we got most of them by now.
When Grasshopper switches to Rhino5 for good, we'll start looking into threading a lot more seriously, not in the least because we'll also switch to .NET 4, which has some pretty cool mechanisms for writing decent MT code.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…