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
years ago of a custom board I made with an ATMega Tiny44 microcontroller and a light sensor (really simple board): https://vimeo.com/16596268. But, it worked quite well.
There's a couple of things to remember. First, when sending data from your board to Grasshopper, you need to make sure that you add a carriage return and new line feed characters to the end of your print statement. Normally, when using the Arduino IDE, this is handled by simply using a Serial.println(); function... which automatically adds those two characters onto the end of the line. You need these two characters, because Grasshopper needs some way to determine where the 'end of the line' that you're sending is. If you add those two characters onto your string, then you can read that data in to Grasshopper using the Generic Serial Read component. You can parse up the string (depending on how you format it) using the built in Grasshopper string components (or write your own script if you prefer).
Sending data from Grasshopper to your board is pretty simple (actually, it's already done if you use the Generic Serial Write) assuming your device shows up as a COM port on your computer (and you open that port before writing the data). However, you'll likely need some code to translate the incoming string into some meaningful information to send to whatever pins on your microcontroller. This is basically what the Firefly Firmata is for. But, this is built specifically for the Arduino pin configuration... so it likely wouldn't work here. But, you may be able to translate some of the same functionality from the firmata into your code.
Hopefully this helps get you started.
Best,
Andy…
if you can't resolve the details ... well ... they do that as well. For Europe contact my good friend Peter Stevens. (BirdAir).
In general: PRIOR designing ANYTHING (at all) you must formulate some kind of collaboration with a specialized manufacturer. Problem is that ... er ... if they don't know you they don't give much attention (this is a rather "closed" AEC sector).
On the other hand if your membrane is bespoke designing the components (anchor plates, masts, tensioners etc etc) and/or using bespoke ones available in the market (not many around. mind)... well ... this IS the core of the matter. Rhino is NOT suitable for that kind of stuff by any means.
Kangaroo 1/2 is the way to go when inside GH. Other apps especially the "pro" ones are very expensive. BirdAir has the best software for that matter but is mostly an internal product available as well only for few "strategic" partners as they call Architects who can design that kind of stuff.
Other than that have some fun:
Tensile Membranes test3 - Grasshopper
And this ... well ...is about NOT doing it:
Need help about using Kangaroo for form finding
…
t Houdini is fantastic for, more stability, faster processing. Yay for Houdini! It's a great product. You may be surprised to find that many people - some here - actually use both products. For different things.
Your posts turn into bizarre quests...your recent ravings have you careening from Rhino to Revit to Maya to ZBrush to Houdini, all the while bitterly lambasting McNeel for not implementing everything perfectly. You insult everyone along the way, and to top it off, launch into self-aggrandizing, astonishingly delusional claims..."the most beautiful images!" "the greatest breakthrough for Rhino!" This last claim refers to what is more or less a Pythonic macro that saves Rhino files, spins up a COM instance of ZBrush, calls some commands, then brings it back. That can be useful to people who have ZBrush...but really? So very very great, as you insist? As you shout at the top of your lungs how wonderful you are, and how like peasants everyone else is? It's a macro, dude.
I can only guess that your most recent, exaggeratedly unhinged and increasingly personal attacks on pretty much everyone else here are you now actually trying to get banned, just so that you can feel even better about yourself (if it's possible), and as some form of justification for your self-righteousness. But your act is both so very loud, and so very tired; and more importantly, you'll never see how you miss the point on so many levels...really, if it's so terrible here, you could preserve some modicum of dignity and bring your gaudily baroque, self-important roadshow to the next software package that you inevitably be disappointed by, either because the community there also doesn't somehow see your "genius," or because it breaks on occasion.
Really, just go.…
Added by David Stasiuk at 2:10pm on October 24, 2017
o sensor Shield V5.0 - 2 standard servos (plugged into pins 9 and 10 in the sensor shield) - 7.5V wall power supply - USB cable to computer
I'm running Rhino SR 8 on a 32 bit Windows Vista machine I have Version 0.9.0014 of grasshopper (the latest) and Firefly_Build_1.0067 I have flashed my Arduino board with the latest firefly firmata (updated September 10th, 2012)
I have checked that I am using the "MEGA write" box I have got the right bits going to the right pins and I have checked that they all have "servo" ticked instead of "digital" or "pwm"
My servos and board work perfectly well with the normal Arduino software, but just not any longer with firefly since my computer was switched off.
The port shows correctly as COM 4 and opens fine.
When I move the slider to control the servos, the TX light is on and the RX light flashes, but no servos move... (everything works with the sweep example in arduino though, so I have eliminated power and wiring issues)...
Any ideas what might be the problem?
I've tried re-installing, switching off and on many times, changing cables, trying a different board (also doesn't work any more with the duemilanove), trying all pins on the shield, trying one servo without the shield, trying one servo with the shield, lots of googling, lots of searching forums, unblocking the firefly installation files in explorer, lots of things... I'm all out of ideas... And very confused as it was working just a few days ago... Am I just missing something really obvious or could there be an issue with the software at my end?…
edefining the axis variables, logarithmic scales, display thresholds, better marking management - or at least add contrast!
Hey Fred,
thanks for the feedback! This is a basic version, and personally I used a custom component to read and parse the history files from the canvas to be able to e.g. scroll through generations and solutions or display more solutions at once (via pathes, mostly requires modification of the initial setup) ...
but you are right. I would love to bring the solution's navigation directly into the rhino viewport but I think that would be a major hack .. unless you can give me a hint how to do that. the displaying and user-preference-handling are besides a re-entrant history, some more algorithms and parallelization the next things to tackle, but display is definitely one of the easiest, so ... soon! work will begin in january i guess, since the project then starts i hope - but it will start for sure.
best
r
…
an external test suite.
We have a lot of parameters we want to test with, so doing so in Rhino is cumbersome.
To this end, we've experimenting to run Rhino/Grasshopper with a number of ways:
- 1) Using the COM interface, to create Rhino, load grasshopper then run tests
- 2) Exposing Rh/Gh internals using WCF via a Rhino command, which starts off WCF, then run tests
- 3) Exposing Rhino/Grasshopper internals using .Net remoting, again via a Rhino command
We've tried -1) that seems to be a dead end, limited access to Rh/Gh
We've tried -2) that works but raises an error in the WCF server stating that RhinoCommon is not available (see attached image). I've tried copying dll's from the Rhino installation to the running wcf directory, but that does not help.
Todo -3) We've still got to try this method.
I've googled similar entries in the forums:
http://www.grasshopper3d.com/forum/topics/how-can-i-use-grasshoper-externally
http://developer.rhino3d.com/api/rhinoscript/introduction/external_access.htm
Does anyone know why -2) wcf fails or if .net remoting will work successfully.
Or indeed if there are other options to address our use case?
Many thanks,
Milan…
ther math and logic. i can usually conceptualise what i want to do and cobble some semi working thing together but don't know which components to use and how to patch it. so i'm super happy to have someone who knows what he's doing to find this interesting.
and i'm glad you mention the fanned frets again, there is one input parameter that's still missing for the multiscale frets to be fully parametric, it's the angle of the nut or which fret should be straight. it depends a bit on personal preferences and playing posture what is more comfortable. so being able to adjust this easily would be cool. again i have no idea how the maths for that work or if you can just rotate each fret the same amount around it's middle point. The input either as fret number (for the straight fret) or as a simple slider from bridge to nut should do as input setting.
Here are the two extremes and the middle ground:
i've been thinkin today while analysing your patches and cleaning up my mess what exactly the monster should do.
Here are the input parameters needed, i think it's the complete list
scale length low E string
scale length high e string
fret angle/straight fret
string width at nut
string width at bridge
number of frets
fretboard overhang at nut (distance from string to fretboard bounds)
fretboard overhang at last fret
string gauges
string tensions
fretboard radius at nut (for compound radius fretboard radius at bridge is calculated with the stewmac formula)
fretwire crown width
fretwire crown height
action height at nut (distance between bottom of string and fretwire crown top)
action height at last fret
pickup 1 neck position
pickup 2 middle position
pickup 3 bridge position
nut width
the pickup positions should be used to draw circles for the magnet poles on each string so they are perfectly aligned and can be used for the pickup flatwork construction. ideally they would need a rotation control aligning the center line of the pickup so it's somewher between the last fret angle and bridge angle. personally i do this visually depending on the design i'm looking for, some people have huge theories on pickup positioning but personally i don't believe in it.
that should result in everything needed to quickly generate all the necessary construction curves or geometry for nut/fingerboard/frets/pickups. this is the core of what makes a guitar work, the more precise this dynamic system is the better the guitar plays and sounds.
i posted another thread trying to understand how i could use datasets form spreadsheets,databse, csv to organize the input parameters. What would make sense for the strings for example is hook into a spreadsheet with the different string sets, i attached one for the d'Addario NYXL string line which basically covers all combos that make sense.
The string tension is an interesting one, and implmenting it would sure be overkill albeit super interesting to try. it should be possible to extrapolate from the scale length of each string what the tension for a given string gauge of that string would be so that you could say 'i want a fully balanced set' or 'heavy top light bottom) and it would calculate which SKU from d'addario would best match the required tension. All the strings listed in the spreadsheet are available as single strings to buy.
i'm trying to reorganize everything which helps me understand it. i just discovered the 'hidden wires' feature which is great since once i understood what a certain block does or have finished one of my own, i can get the wires out of the way to carry on undistracted. a bit risky to hide so many wires but it makes it so much easier not to get completely lost :-)
btw, the 'fanned fret' term is trademarked, some guy tried to patent it in the 80's which is a bit silly since it has been done for centuries. there is a level of sophistication above this as well, check out http://www.truetemperament.com/ and that really is something else. it really is astounding how superior the tuning is on those wigglefrets, the problem is that it's rather awkward for string bending and also you can't easily recrown or level the frets when they are used. …