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
string may contain any number of curly bracket pairs with non-negative integers in them:
"When {0} brings back {1} days and {2}"
The number inside the brackets refers to the data to insert in that location. In effect, {x} is a placeholder for actual data. The data inserted into a specific bracket pair is the data supplied in the latter part of the function. {0} refers to the first item, {1} to the second, {2} to the third and so on ad infinitum.
If I supply some data the entire expression may look like this:
Format("When {0} brings back {1} days and {2}", "Spring", "blue", "fair")
which will result in the string "When Spring brings back blue days and fair".
If the data you're inserting is a number (or a date) then you have additional formatting flags that you can use. These additional flags appear behind the placeholder index integer separated by a colon.
Format("Pi = {0:0.00} ({0:0.000000})", Pi)
The :0.00 means the number will be formatted using two digits. The other flag will enforce six digits, resulting in: "Pi = 3.14 (3.141593)"
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 3:00pm on February 3, 2013
n the inability to be a real-life member within a parametric workflow (same kind of issue with Evolute Tools Pro).
As regards strictly AEC matters the main problem with GH is Rhino itself (not feature/constrain driven, not a solid modeler, not AEC oriented by any means and not biased towards assembly/component modeling). Other than that and due to the known GH inability to handle/manage blocks/nested blocks at bake time ... well... I hardly can see how "to set up work flows between different tools such as ..."
I'll post soon 5 - rather "trivial" - AEC cases that are totally undoable (shop drawing level) with anything other than CATIA (or NX).
BTW: since international practices grow and grow in numbers these days (and individuals are dead) I can't see any realistic limitation for creating dedicated teams (kinda like Frank Gerhy did) that can easily deal with the "extremely heavy" nature of the beast.
BTW: this is a job ad (Project Architect role) from one of the biggest US AEC practices (rather a corporation, he he)
How things change these days ... don't you agree?
best, Peter
…
nette for years.. but without the nice GUI. It also allows combining constraints solving to be part of the DAG.
What is parameterics? Or parametric associative as GC has been described. Can't remember. History or procedural modeling? Even constraints solving or rules based solving all use parameters. Is it generative or merely parametric? I guess the difference is a parametric door doe not generate other parameteric doors?
BIM has opened the door to a more data centric view and manipulation of the design model. To old skoolers a wall is a linear construct that can be abstracted into parameters... beginning and end points of wall in plan + height and thickness. But start adding other stuff and need to ineteroperate with others and things get problematic.
Pretty soon, all those abstractions (parametric or otherwise) need to be structured and you end up talking about schemas etc to control the format of the parameters using rules as checks or constraints..so that your parameters can interface with parameters from others without causing data quality issues. It all gets very database thinking like.
So, I would say parametrics as GH does it is more free form and ad hoc and at some point if it goes BIM, the parametrics will be need to be (re)structured..
BIM is dependent on IFC development which is not very fast. IFC4 is only beginning to think about parametrics and 'Design Transfer'.
…
humacher (Zaha Hadid) and in fact most issues of AD (Architecture Design)
The Politics of Parametricism: Digital Technologies in Architecture by Matthew Poole, which is kind of a follow up
In my opinion learning Grasshopper will be enough and there is no need to learn Python to use it successfully. Best to have a deep understanding of Grasshopper and what it can do then to try and learn too many things at once. It will help you in applying the principles to other code and not the other way round (ie. learning the concepts first and then going into grasshopper). The best way to learn the concepts is by applying and trying them in a tool like Grasshopper.
I absolutely recommend that you visit a Grasshopper workshop, as that will teach you a lot more than Youtube videos. If you cant visit a workshop, then I recommend the rese.arch video series on Grasshopper. They're really indepth and go from simple introduction to very advanced. You should ideally buy and complete all of them.
Also there is of course Dynamo and its integration with Revit and BIM, which is something to look at, although Grasshopper covers all of that as well, at least with the integration with ArchiCad. Autodesk products are more common around the world though.
Be aware that a lot of the power of Grasshopper is also in the plugins you can get for it, like Kangaroo (physics simulation), Ladybug&Honeybee (environmental analysis), Karamba (finite element analysis), Hoopsnake or Anemone (looping) and many, many more. You can find them at food4rhino.com.
Good luck!…
y case. Here's the thing. There is this subject at my university where we are assigned a famous building and we need to recreate it in Rhino. We're given bonus points if we manage to code some interesting part of it in Grasshopper. So far so good, I'm doing pretty well with Rhino and by far I am happy with the results I've achieved with modelling the given building. Harbin Opera House by MAD is the building I'm trying to model. There is one particular surface:I've built this surface in Rhino and now I'm trying to map pyramids on it. Not only have the pyramids to be different in height, but their height has to be dependent on the curvature of the surface. I'm getting some results but it seems to be exactly the opposite of what I need. I want to have higher/spikier pyramids where my curvature analysis shows red/blue and lower/slopier pyramids where the analysis shows green colour.At the moment I'm not really sure how the code I have works, but it seems that the height of the pyramids is dependent on a distance from a point in space to the projection of the cap-point of a pyramid.Here're my Rhino and Grasshopper files:surface1.3dm
surface1.ghI'd be grateful if someone of you guys could handle my problem. I've got one more issue with this surface, but once I get a solution to the first 1 will let know what the second one is.Thanks in advance and keep well!…
are invisible in the picture.
So what you see it's a common band that has lost all those characteristics of the original in order to protect the process.
We also did an "invisible setting" prototype which has built in Flexibility.
If you are in the jewelry industry you would know what I mean and it is close to a miracle.
It's a shame I can not share details and this is why I am planning my next major work on something 10 times more complex then this, at least.
It's will be for my own business and for the jewelry industry as well.
I hate to tease people and then not to be able to produce anything more than an image.
But I thought it would be better than nothing, at least for jeweler designers, so they can see that there are more and more users and that complexity it is not something to shy away from, and it's worth the time spent because the returns on production are far larger than for special orders and this is why GH is useful.
We can design a piece of jewelry usually in less then 1 hour, hence GH is not really worth the time.
But for production with so many variables (Finger sizes controlling most of the outcome together with stone sizes etc.) then GH it's a MUST!
I really appreciate everyone's comments and suspicions and I understand why.
99% of the people out there do not really understand the complexity of jewelry at the industrial level. It' s not just form but the post-production that's the killer.
This industry it's still an hybrid of technology and art with, and due to the lack of the old school pros, unfortunately, we face very lousy and unpredictable execution in the post production (after the casting process). This leaves you with a design process and intention that requires a lot of control over every possible variant of the object.
One wrong design aspect it's multiplied thousands of times at the benches (for every single piece) = bad profits!
It sound more serious that it is but very few companies are willing to do so (delivering good product vs low quality and this also happens because the consumer is not longer aware of the difference. So, who does keep quality, it's only because of integrity, third party QA or just pride).
This is way GH is invaluable. This is why that Def looks like out of proportion for that (Visual) simple band.
It is because there are dozens and dozens of variable effecting everything else. In fact it is not even complete as it is in order to cover everything but the most critical ones.
Sorry for the long replays. I am an instructor and a professional jeweler by trade since I was very young and I love to teach, so I overflow with explanations... and Components :)).
Next time it will be "in the open" as they say...…
uments:
1. You are targeting CATIA don't you? (not exactly tomorrow but ... soon) and/or SolidWorks (hello C# haven't we met before?).
2. You MUST deal with nested block instances instead of what you are trying to do right now (I'm talking about the real MERO things not abstract Lines and points). This is not doable with GH components I'm afraid (but it's rather easy with code).
3. You MUST deal with RDBMS in order to keep track with what's going on in your company per project per case per designer (who sells that bolt? what's his cat name? is he a reliable supplier? what I'm doing in life? ... that sort of "queries"). At this point: CATIA is 1% CAD things and 99% PLM stuff (Product Life cycle Management). We do want that since it's 21st century running don't we?.
I hear you: but these are 3 arguments ... indeed but ... hey who's counting? he he.
Method:
A. This def attached has a very simple C# that gets mesh Pts and makes a nice U/V style collection of points (DataTree in plain English).
B. Then we go to that umbrella sticks thingy: we can calculate anything (already the thing does "some") plus your collections of divided points (with the right way, he he) VS a given node: you said (Skype) that you want to calculate angles with these (from 2 to 6) in mind: obvious since you are doing real-life MERO things.
C. Then we could calculate the appropriate Planes for PlaneToPlane transformations: get a nested instance definition (the red things that you've showed to me yesterday) placed at 0,0,0 (Plane.WorldXY) and put in in every Plane collection related with every node (clash defection is an obvious must).
Case resolved, closed: what about that Vodka?
More in Skype
…
merely automates finding clear intersections between pairs of objects and then splits the objects along those intersection *curves*, deletes the trims, then joins the remains, and cycles on. But within the confusing Rhino Settings tolerance value, wherever surfaces actually just sort of come closely together, there *is* *no* clear intersection curve. So it bugs out and stops working EVERY time you try more than a dozen or two spheres.
Some software can do this by switching to volumetric pixels (voxels). $9K-$30K Geomagic Freeform is an example of this. It also fails sometimes, often due to memory issues, as you can imagine since it needs to fill all inner space of each sphere definition with 3D pixels.
Materialize Magics for $16K can often handle such Booleans well. It will take a seeming lifetime to figure out such often pirate software kludges though.
One thing you can try though is to simply drape a mesh or NURBS plane onto the top of your spheres.
There's a well known *reason* your Booleans are failing. Nobody here has yet even hinted at it:
The main reason is that Rhino/Grasshopper developers don't care about the human element. The math exists to make this work very fast, every time. It just has to join things *right*, incorporating human knowledge of kissing surfaces, instead of acting stupidly, like some pocket calculator. But that would involve hacks that make 99% of complex Booleans work instead of 10%, and we can't have that since it will be SLOWER for the other 1% that just happen to have no nearly kissing or really kissing surfaces.
You could also use the new Cocoon plugin to do a surface *around* your structures, with a given radius of extension beyond the spheres, then offset that surface back the same radius. That is 100% robust, but won't offer quite as sharp of intersections, more rounded, like most everybody wants anyway.
You can *test* Boolean failures, by running a Grasshopper intersection command, to see the intersection curves, and zoom in to see how badly many of them are, all knotted, or twisted, or even with gaps, often with gaps.
It's a math problem nobody at McNeel wants to solve, sorry.
Just write a check for $25K and spend six months taking notes, like I did, and you can merge your simple spheres finally.…
Added by Nik Willmore at 6:33pm on October 20, 2015