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
edit 29/04/14 - Here is a new collection of more than 80 example files, organized by category:
KangarooExamples.zip
This zip is the most up to date collection of examples at the moment, and collects t
sinergetici associati alla compresenza simultanea di differenti strumenti di analisi e digital design all'interno di un processo di progettazione in svolgimento. I partecipanti utilizzeranno Grasshopper (modellatore parametrico per Rhino): l'uso di questo editor grafico di algoritmi si integra alla perfezione con gli strumenti di modellazione di Rhinoceros 3D espandendo le possibilità di corstruire modelli parametrici altamente complessi. Per generare una complessità simile saranno utilizzati collegamenti live ai diversi programmi elencati di seguito: . Autodesk Ecotect Analysis via GECO . FEA software GSA via SSI Durante questi intensi 3 giorni, i partecipanti impareranno il workflow dei plug-ins con l'aiuto di esempi esplorando una panoramica dei differenti software, le possibilità di testare le performances di un progetto o l'uso di strumenti addizionali non legati ad un singolo sistema (es. accentuazione, formazione, reazione parametrica) [english text] The focus of the workshop is to integrate and correlate the synergistic effect associated with simultaneous presence of different digital design- and analysis tools in an ongoing design process. The main attention is set on easy to handle interface , which should be used at a early stage of conceptual design to respond to external and internal influences in a intelligent and sustainable way. Participants will use the software Grasshopper as a parametric modeling plug-in for Rhino. The usage of this graphical algorithm editor tightly integrated with Rhino's 3-D modeling tools open up the possibility to construct highly parametrical complex models. To generate this complexity we will use live linkages to several programs listed below: . Autodesk Ecotect Analysis via GECO . FEA software GSA via SSI In this 3 intense days, the participants should learn the workflow of the plug-ins with the help of examples and get an overview of the different software's, there possibilities for evaluating the performance of a design or the usage of additional tools to be not chained to a single system . (e.g. parametrical accentuation, parametrical formation, parametrical reaction) [.] Dettagli : Istruttori: Thomas Grabner & Ursula Frick from [uto]. lingua del corso: inglese (saranno disponibili tutor di supporto ma è richiesta una conoscenza di base della lingua unglese).
Quote d'iscrizione (min 12 max 20 posti): educational* : € 280.00 + iva professional: € 450.00 + iva * studenti, docenti, ricercatori, dottorandi e laureati fino a un anno dalla data di laurea OFFERTA EARLY BIRD SPECIAL: le prime 5 domande di iscrizione pervenute entro il 31 Dicembre 2011 avranno diritto ad una quota di iscrizione scontata del 20% Quote d'iscrizione E.B. SPECIAL: E.B. SPECIAL educational* : € 224.00+ iva E.B. SPECIAL professional: € 360.00+ iva. ulteriori info, dettagli e iscrizioni: http://www.co-de-it.com/wordpress/nexus-advanced-grasshopper-workshop-with-uto.html…
radiance parameters to get rid of blotching. To add another level of complexity to my problem, I am running simulations with a translucent material with the following properties: void trans testTrans
0
0
7 0.478 0.478 0.478 0.000 0.010 0.178 0.635
I have had no issues with the renderings when I use clear glazing, as seen on this image:
However the blotching-issue becomes very noticeable when I introduce translucent glazing into the scene:
For the two above cases I used the following parameters:
_av_ is set to 0
xScale is set to 2
_ab_ is set to 6
_dc_ is set to 0.5
_aa_ is set to 0.2
_ad_ is set to 2048
_st_ is set to 0.5
yScale is set to 2
_ps_ is set to 4
_ar_ is set to 64
_as_ is set to 2048
_ds_ is set to 0.25
_pt_ is set to 0.1
_dr_ is set to 1
_pj_ is set to 0.9
_dp_ is set to 256
_dt_ is set to 0.25
_lr_ is set to 6
_dj_ is set to 0.5
_lw_ is set to 0.01
I ran another test with increased Radiance parameters and got the following output:
with the following parameters:
_av_ is set to 0
xScale is set to 6
_ab_ is set to 6
_dc_ is set to 0.75
_aa_ is set to 0.1
_ad_ is set to 4096
_st_ is set to 0.15
yScale is set to 6
_ps_ is set to 2
_ar_ is set to 128
_as_ is set to 4096
_ds_ is set to 0.05
_pt_ is set to 0.05
_dr_ is set to 3
_pj_ is set to 0.9
_dp_ is set to 512
_dt_ is set to 0.15
_lr_ is set to 8
_dj_ is set to 0.7
_lw_ is set to 0.005
Although the second blotching case is much better than the first, it is still very bad for hours when the sun is lower in the sky. The above images are rendered for a clear sky at 18:00 in Germany in a West-facing room.
Sorry for the long post! Can someone help? Kind regards, Örn
…