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
itual:
dll and gha files unblocked
Rhino5 64bit SR11 and GH 0.9.0076 (evaluation version)
.NET framework 4.5 or later
COFF loading turned off (either the global setting or just for Kangaroo2, following the instructions above)
I´v my kagaroo2 dll and gha files in local machine
I worked at windows 8.1 (64 )and windows 7 (86)
The kagarro2 work´s in these machines without problems
only the Grap component does not work...
I´d an educational lab licence for Rhino, and I´ll try to work with another one maybe it does not work with newest release, my licence is SR 7
I install the Rhno 5 version SR11 but will expire in 30 days…
go As New MRhinoGetObject()
go.SetCommandPrompt("Sélectionnez les deux arrêtes sur les pièces à serrer pour placer la Boulonnerie...")
go.SetGeometryFilter(IRhinoGetObject.GEOMETRY_TYPE_FILTER.edge_object)
go.AcceptNothing()
go.GetObjects(2, 2)
If (go.CommandResult() <> IRhinoCommand.result.success) Then
C1 = go.CommandResult()
End If
Dim object_ref1 As MRhinoObjRef = go.Object(0)
Dim obj1 As IRhinoObject = object_ref1.Object()
Dim curve1 As OnCurve = object_ref1.Curve()
Dim object_ref2 As MRhinoObjRef = go.Object(1)
Dim obj2 As IRhinoObject = object_ref2.Object()
Dim curve2 As OnCurve = object_ref2.Curve()
C1 = curve1.NurbsCurve
C2 = curve2.NurbsCurve…
your surface in order to do it with more control points, these new points will be attracted by curves and moved on z by a factor depending on distance from curve, changed by graph mapper and by a constant thickness. This will give you 2 surfaces, one unchanged an another on the top. These surfaces will be closed by lofting their edges and joined.
The closed surface will be meshed and send to bowerbird waffle.
…
pper, it appears that half of the surfaces are now flipped (normals now pointing to the inside of the polysurface). I've tried to use a guide surface, I tried offsetting points along the normal to test for inclusion and then flip. I've even tried to flip normals manually by mutliplying the normal by -1.0...no matter what I try, can't seem to get all surfaces to be in the same orientation. Any insight would be appreciated...
Using:
Rhino SR6 on win xp
Grasshopper version 0.6.0019
Thanks!
~BB~
here's an image of what i get when i do the dir command in rhino:
here's what i see when i display normal vectors in grasshopper:
…
ted by tool conversion, but it seems to be strange because when i put the same file into ECOtect Weather Tool i can run weather data graphs, like this one:
I hope you can help me. Thank you in advance.
(i attached my epw file, by Notepad++ i noticed too many "question marks")
…
used of 180 being for the northern hemisphere and 0 for the southern hemisphere.For the optimal tilt, to my knowledge, they are mostly based on correcting location's latitude through a single formula.TOF component is more sophisticated. It essentially replicates the Solmetric's Annual Insolation Lookup tool.What it does is that it creates a grid of points. Each point represents the calculated annual insolation on the surface (PV module, SWH collector, facade, any kind of surface) for a single tilt and azimuth angle.Each point is then elevated according to the annual insolation values. The mesh is created from that grid of points. The portion of the mesh which is the highest, represents the optimal tilt and azimuth angles. So the higher your "precision_" input is, the more points in a mesh you'll have - thus the more precise final optimal tilt and azimuth will be.For the diffuse component of the annual incident solar radiation for each point the Perez 1990 modified model is used. Direct is from classical cosine law, and Ground reflected component from Liu and Jordan (1963).So TOF component calculates the optimal tilt and azimuth based on annual incident solar radiation, not AC energy....…