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
basis" problem ... all of a sudden - quite recently - a girl posted the MITESIGF (Most Important Thread Even Seen In Grasshopper Forums). She doesn't even realized that: she's novice:
http://www.grasshopper3d.com/forum/topics/array-1
4. Why this MITESIGF is MITESIGF? For 2 reasons:
4.a: Wooden pairs (Beams) Profile Curves (belonging in some tree) MUST allow individual control on a per "item basis" (OK, that's obvious) - see Images posted in the thread. No attractor (or any other "global" policy) can cut the mustard here (to tell you the truth this happens in 99% of pure engineering cases, but they appear very rarely in GH Forums - if at all, mind). If the profile curves are defined with 5 points (or 9 for the double thing) we need "on-the-fly" control over this Array (like the radii in your Sphere Manipulator) :
4.b: Critical Bottom-to-Top issues arise: Create a "global" topology (call it "parent") - the beams - and then place real-life "components" (call them "childs") that affect (most probably) the "parent". OK, that's impossible to do with GH/Rhino (peace of cake with CATIA/Microstation) but you can "approximate" things up to a point. Alternatively: you can "trigger" some interest from GH/Rhino developers if they have any AEC market(s) in mind.
Topic 4.a requires the master-to-slave slider thingy (iterate over branches (index slider:master) > reset the 5 values (value slider:slave) > modify them on the fly > save > increase/decrease branch > ...).
Other than that my definitions are far more challenging than this simple case ... but ... anyway ... long is the path (and hilly).
more soon.
best, The Troll
…
ceros.
Public concerné /
Architectes et designers, utilisateurs de Rhino souhaitant paramétrer Rhinocéros à l’aide de Grasshopper,
programme associant des composants et une structure de graphe interagissants avec le modèle Rhino.
Une bonne connaissance de Rhinocéros est nécessaire. La langue de la formation est le français.
Structure et Objectif de la formation /
La formation se déroule sur 3 jours : les 2 premières journées sont consacrées aux « fondamentaux » de
Grasshopper avec en préambule une introduction au design et à l’architecture paramétrique et leurs impacts
dans la conception, la création et la construction.
La troisième journée sous forme d’atelier est dédiée à l’étude de cas concrets proposés par les stagiaires, qui,
quelques jours avant la formation, pourront envoyer leurs projets par mail à - info AT rhinoforyou DOT com -
Les stagiaires, après la formation, pourront rester en contact avec les formateurs de HDA par le biais du
blog complexitys.com et le twitter @HDA_Paris. La durée de cette formation permettra d’atteindre une
autonomie et une bonne compréhension basée sur des exemples concrets.
Programme ind icatif des notions traitéES pendan t la formation /
Introduction à la conception Paramétrique . Rhinoscript, Grasshopper: différences et similarités . Interface
graphique de Grasshopper . Objets, Données, Listes . Opérateurs scalaires : La mathématique de
Grasshopper . Gestions des données : la logique de Grasshopper . Vecteurs, Points, Lignes, Surfaces : La
géométrie de Grasshopper . Listes, Arbres, Branches . Le dessin paramétrique: exercices divers et exemples
. Références, Bibliographie, Support de cours . Ateliers d’architecture et design paramétrique (3ème jour) .
Moda lité de la formation /
Venir avec un PC portable équipé de Rhinocéros version 4.0 SR 7 et de la dernière version du plug-in
Grasshopper (téléchargeable sur www.grasshopper3d.com).
Le coût du stage de 3 jours est de 1050 € HT par personne.
Réserver votre place dès que possible car les places sont limitées à 10 participants maximum.
Inscriptions et renseignements: Jacques Hababou, info AT rhinoforyou DOT com
Pour en savoir plus sur l’architecture paramétrique: www.complexitys.com…
.
Today we have gone live, and the plugin is available on Food4Rhino. You will find an installer package, sample files, and a demo video on getting started:
http://www.food4rhino.com/project/human-ui
Visit the Bitbucket Repo and poke around in the code:
https://bitbucket.org/andheum/humanui
Check out today's coverage in Architect Magazine:
http://www.architectmagazine.com/technology/nbbj-releases-human-ui-to-bring-parametric-modeling-to-the-masses_o
Finally join our group and ask any questions or post any comments here:
http://www.grasshopper3d.com/group/human-ui
See below for detailed description!
----------------------------------
Human UI
Primary Development by:
Lead Developer: Andrew Heumann / andheum / @andrewheumann
Product Manager: Marc Syp / marcsyp / @mpsyp
Contributing Developer: Nate Holland / nateholland / @_NateHolland
Gone are the days of faking a user interface by laying out sliders and text panels and hiding wires on the Grasshopper canvas. Human UI interfaces are entirely separate from the Grasshopper canvas and leverage the power of Windows Presentation Foundation (WPF), a graphical subsystem for rendering user interfaces in the Windows environment.
OLD NEW
In other words: Human UI makes your GH definition feel like a Windows app. Create tabbed views, dynamic sliders, pulldown menus, checkboxes, and even 3D viewports and web browsers that look great and make sense to anyone--including designers and clients with no understanding of Grasshopper.
Human UI has been in development at NBBJ for over a year, as part of a larger NBBJ Design Computation initiative to deliver our tools internally as Products -- with fully automated installation, managed dependencies, analytics, documentation, and “magical” user experience. Human UI has been a huge component of the user experience part of this puzzle, and we are excited to share it with the larger Grasshopper community so that others can benefit from it and contribute to its development.
The initial release of Human UI is accompanied by a few simple examples to get you started, but we have developed sophisticated user interfaces with these tools at NBBJ and will slowly be rolling out more advanced examples. We also look forward to opening up the development to the community and seeing what new features and paradigms we can add.
Download the plugin at Food4Rhino and get started building Custom UIs for Grasshopper right away! We are happy to answer any questions or field discussion in the dedicated Grasshopper Group. Please join us!
Join the Grasshopper Group
http://www.grasshopper3d.com/group/human-ui
Download the plugin + sample files
http://www.food4rhino.com/project/human-ui
Visit the Bitbucket Repo
https://bitbucket.org/andheum/humanui
We look forward to seeing where this project takes you, please share your projects made with Human UI!
Sincerely,
Design Computation Leadership Team, NBBJ
…
ur setup. Can you say what sensor you are using? Are you using an Arduino to write this ascii information to the serial port? If so, there may be some formatting code for the string that you'll need to do to get the Read component to function properly. I see that you were able to open the port and Start reading... so my first thought is that the data is formatted correctly....
All of the read components look for a specific character (in this case two characters) to indicate when it has reached the end of the line being read and should spit out the data. In this case, Firefly uses the Carriage Return (\r) and Line Feed (\n) to know when it has reached the end of the line. In arduino, these are automatically added to any line if you use the Serial.println("blah, blah, blah"); command. Notice, this is different from the Serial.print("nothing to see here"); command. This doesn't mean that you can't still use the regular print command... it's just you need to use the println command to indicate when you've reached the end of the line. Let's take a look at a simple example.
void setup() { Serial.begin(9600);}void loop() { int sensorValue = analogRead(A0); Serial.print("The value of the sensor is: "); Serial.println(sensorValue);
delay(20); // important to wait some small time so you aren't sending just a ton of info over to GH which will cause it to crash :(
}
The first print statement prints a string to the serial port... and the next one adds the current sensor value... and THEN adds the carriage return and line feed to start a new line. The nice thing about using these together is that you can concatenate any type of data you want. If you were to upload this sketch, you should see a sentence being printed to the serial port that says "The value of the sensor is: 512". I made up the number, but you get the idea. Notice, I also had to include a delay function. You don't always need this (there are other ways to go about this) but the important thing to note is that the loop cycle on the Arduino can run really fast. I mean... really fast. So, you wont want to send so much data over to GH, because this could flood the string buffer in the Read component and cause it to crash (eventually). It's a good idea to add some small time interval just to slow it down a bit. I should say that I've optimized the refresh rate in the next release so it's significantly faster... so hopefully this wont be as big of a problem... but hopefully that helps some.
Now... Why are you writing data to a sensor? Sensors by default are considered inputs... so I'm quite confused as to why you would want to send data back (if you are... then you need some way to handle the string data being sent from GH... this is the whole reason we built the Firefly firmata... it sets up the two-way protocol so you don't have to deal with all of that mess... If you're going to read and write, you're better off just uploading the firmata and using the Uno Read and Write components). Also, I'm not very familiar with the Hyperterm or Advanced Serial Port Terminal... but I will say that could get COM conflicts if you're trying to open the port with different tools. Anyway, I hope some of this helps you get up and running.
Cheers,
Andy
…
ceros.
Public concerné /
Architectes et designers, utilisateurs de Rhino souhaitant paramétrer Rhinocéros à l’aide de Grasshopper, programme
associant des composants et une structure de graphe interagissants avec le modèle Rhino.
Une bonne connaissance de Rhinocéros est nécessaire. La langue de la formation est le français.
Structure et Objectif de la formation /
La formation se déroule sur 3 jours : les 2 premières journées sont consacrées aux « fondamentaux » de Grasshopper
avec en préambule une introduction au design et à l’architecture paramétrique et leurs impacts dans la conception, la
création et la construction.
La troisième journée sous forme d’atelier est dédiée à l’étude de cas concrets proposés par les stagiaires, qui, quelques
jours avant la formation, pourront envoyer leurs projets par mail à info AT rhinoforyou DOT com
Les stagiaires, après la formation, pourront rester en contact avec les formateurs de HDA par le biais du blog
complexitys.com et le twitter @HDA_Paris. La durée de cette formation permettra d’atteindre une autonomie et une
bonne compréhension basée sur des exemples concrets.
3 Formules possibles /
3 jours ( Initiation+Atelier ) : du lundi 20 septembre au mercredi 22 septembre
2 jours ( Initiation ) : lundi 20 et mardi 21 septembre
1 jour ( Atelier ) : mercredi 22 septembre
Programme ind icatif des notions traitéES pendan t la formation /
Introduction à la conception Paramétrique . Rhinoscript, Grasshopper: différences et similarités . Interface
graphique de Grasshopper . Objets, Données, Listes . Opérateurs scalaires : La mathématique de
Grasshopper . Gestions des données : la logique de Grasshopper . Vecteurs, Points, Lignes, Surfaces : La
géométrie de Grasshopper . Listes, Arbres, Branches . Le dessin paramétrique: exercices divers et exemples
. Références, Bibliographie, Support de cours . Ateliers d’architecture et design paramétrique (3ème jour) .
Moda lité de la formation /
Venir avec un PC portable équipé de Rhinocéros version 4.0 SR 7 et de la dernière version du plug-in
Grasshopper (téléchargeable sur www.grasshopper3d.com).
Le coût du stage est de 350 € HT/jour par personne.
Réserver votre place dès que possible car les places sont limitées à 10 participants maximum.
Inscriptions et renseignements: Jacques Hababou, info AT rhinoforyou DOT com
Pour en savoir plus sur l’architecture paramétrique: www.complexitys.com…
o Common - just like C#. But Rhino Python has a "Scripting Language Wrapper" which breaks commonly used taks down to simpler functions.
Here's a general Example:
Take a look at the code on this website http://wiki.mcneel.com/developer/rhinocommonsamples/addline). Generally it's Rhino Common code in three language to create a line. They look equally difficult.
But if you use Rhino Python Scripting you can use an simplified syntax to get the same result. It's very similar to Rhino Script.
The code would be:
import rhinoscriptsyntax as rsstart_point = rs.GetPoint("Get start point")end_point = rs.GetPoint("Get end point")line_id = rs.AddLine(start_point, end_point)
OK - No Error Tracking here, but still you can see that the syntax is much simpler. (And in the end you just have less lines of code you have to debug.
And the good thing about Rhino Python is, that you can mix these approaches. Once you reach a level where Rhino Python Script doesn't get you there, which by the way happens very rarely, you can still use the Rhino Common methods.
Also, in Python Sycripting 99% of what you probably would like to do is available as a "wrapped" script function.
Rhino Python Script is currently also better documented than Rhino Common for C# and VB.Net. If you have used Rhino VB Script before, these functions will be very familar to you.
I'm not sure, why it's currently a separate plug-in. I belive the reason is that Rhino 4 (which is supported by GH) doesn't support Rhino Python. Also it's currently WIP, so it needed to be updated more frequently than GH itself. In the long run (I believe) it might be integrated into GH as a general component
- Martin
P.S.: To use Rhino Python within GH is a little more tricky than my example - but nothing compared to developing C#
P.S.2 Here's the code with Error Tracking:
import rhinoscriptsyntax as rsdef AddLine(): start_point = rs.GetPoint("Get start point") if start_point is None: print "No start point was selected" return end_point = rs.GetPoint("Get end point") if end_point is None: print "No end point was selected" return line_id = rs.AddLine(start_point, end_point) return line_idAddLine()
…