ho cercato un componente che potesse leggere i dati di un cerchio ma ho trovato solo questo:
Dato che GH non gestisce autonomamente le stringhe non capisco perchè hanno accorpato i dati del centro con quelli del piano quasi come se il centro fosse un parametro secondario!
Ma bisogna fare i salti mortali con n geroglifici per estrapolare questo dato oppure esiste un componente che mi estrae tutto in modo più logico? Potevano almeno scriverli in 2 liste…
Forse è un problema che vedo soltanto io?
Sono alle prime armi con gh (davvero un mondo nuovo) però se è il centro il dato che ti occorre puoi usare il componente area che ti restituisce in output sia l’area che il centro, se poi volessi avere le coordinate del centro usi il componente deconstract point è da un pannello leggi le sue coordinate
Ciao Federico.
Con DeconstructPlane ricavi i dati del piano, origine compresa,
che in questo caso corrisponde al centro del cerchio. 
( Menu’ Vector → Plane )
Secondo me sei rimasto troppo “attaccato” al Lisp.
Non credo che abbiano realizzato GH per gestire le stringhe.
È molto più semplice.
Non vorrei fare paragoni… ma che significa? la gestione delle LISTE e delle STRIGHE è la base della programmazione ed elaborazione dei dati in ogni sistema, Gh per me è affascinante ma ci sono cose che, oserei dire, filosoficamente non comprendo…
Volevo dire che GH è una programmazione ad oggetti.
Bisogna entrare nell’ordine di idee che il car e il cadr bisogna lasciarli da parte.
Secondo me non ha senso voler ricavare informazioni dalle stringhe.
Per fare ciò posso utilizzare linguaggi disponibili VB, C#, Py.
Ma allora tanto vale programmare in RhinoScript.
Io almeno la penso così.
Allora, se guardi il Panel del mio esempio dall’output BasePlane del componente ARC è GH che tira fuori una stringa. Non mi estrapola i dati in una lista con 0: O(x,y,z) e 1: Z(x,y,z) che sarebbero più comodi anche se mi risulta incomprensibile la logica…Base Plane più importante dell’origine del cerchio matematicamente insensato.
Quindi Leopoldo se GH non gestisce le stringhe (cosa peraltro banale) perchè le genera? Come estrapolo il dato origine del cerchio? Penso che per un ambiente parametrico sia il minimo…
Grazie molte Emilio, effettivamente funziona ma da un punto di vista matematico è a dir poco un nonsenso. Il centro del cerchio non è necessariamente un’origine e poi caspiterina indicarlo subito? costava tanto? ma poi farne un componente per il cerchio e uno per l’arco? Ma!
Ciao, scusa se intervengo, capisco la tua “frustrazione”… quello che vuole dire Leopoldo è che gh è nato per permettere a chi non sa nulla di programmazione di poter creare delle automazioni.
In quest’ottica bisogna lasciarsi andare e utilizzare i componenti così come sono stati creati facendo a volte dei giri che sembrano assurdi (per chi sa programmare) ma che si rendono necessari per accompagnare utenti che, altrimenti, si perderebbero al secondo passaggio.
Purtroppo GH è enorme e serve tanto tempo per entrare in “contatto” con tutti i componenti… bisogna portare pazienza…
Qui la cosa è coerente con lo scripting.
Anche in vbs ti vengono restituiti o richiesti dei piani di riferimento per creare delle entità semplici (vengono restituiti come array che contengono il piano e i vari punti).
Questo perché, lavorando in 3d, è necessario passare in modo univoco i riferimenti nello spazio senza dare per scontato che si stia lavorando sul piano XY del world.
Ciao Fede, ha molto senso secondo me. Esattamente come quando programmi indichi un piano e l’origine rispetto al WCS (la sola cosa che esiste) l’analisi di un arco ti restituisce questi valori che sono meno banali di quanto sembri. Nel caso dell’immagine la circonferenza è stata aperta cliccando il raggio dove vedi “end” ed infatti nella geometria quello è il punto dove si congiungono gli estremi. Il piano ad essa collegato è di conseguenza orientato rispetto all’origine.
La stessa circonferenza con lo stesso centro ma fatta digitando il raggio (non cliccando) avrebbe posizionato l’ end a ore 3 con un piano diverso e di uguale origine.
Le liste contengono dati che sono formattati per circolare secondo un senso all’interno di Grasshopper. Se guardi le coordinate di un punto hanno un formato simile a quello che si userebbe per un vettore.
Credo che la cosa migliore per chi inizia a usare GH sia quella di dimenticare qualsiasi linguaggio di programmazione e darsi degli obiettivi da raggiungere in questo ambiente. Con crescente difficoltà.
Hehe … su questo punto non posso darti torto … 
Voglio dire: i cerchi di Rhino sono definiti da un piano, la cui origine e’ anche il centro del cerchio.
A me sembra ragionevole, pero’ sarebbe anche ragionevole specificarlo nella documentazione … e io questa informazione non la trovo (puo’ essere colpa mia che non la vedo, ovvio).
Allargando il discorso… all’ambiente Rhino in generale e ancor piu’ a Grasshopper,
l’impressione che ne ricevo io (quindi interpretazione personale) e’ che Rhino sia un compromesso, soprattutto in certe sue parti che definirei marginali rispetto al suo ‘core business’, per cosi’ dire, cioe’ la modellazione organica/estetica.
Il compromesso che ci vedo io e’ tra il prezzo di Rhino e le sue prestazioni.
Suppongo che in McNeel preferiscano mantenere basso il prezzo (parecchio basso rispetto ad altri programmi) a costo di non offrire un programma completamente sviluppato e rifinito.
Quindi restano spesso alcune parti … direi in sospeso.
Cioe’ utilizzabili, ma accettando a volte di incappare in qualche inconveniente, come appunto la documentazione di script & Grasshopper.
Quanto alle stringhe, premesso che conosco poco GH (abbreviazione per Grasshopper), mi sembra che permetta di lavorarci.
Non peoccuparti del Panel. Il Panel serve a darci delle informazioni, quindi necessariamente converte tutto in testo, ma non significa assolutamente che i dati in uscita dai componenti siano del testo.
E comunque GH e’ molto bravo a convertire i vari valori nei tipi di dati che servono.
Ci vuole solo ( 
) parecchio allenamento perche’ Gh tende a ragionare a modo suo e, almeno a mio parere, non e’ immediato entrare nel suo ordine di idee.
Inoltre GH e’ sviluppato praticamente (per quanto ne so) quasi solo da David Rutten, quindi l’aggiunta di nuove feature e’ ancora piu’ lenta di quanto accade per Rhino …
Per cui certe operazioni possono non essere disponibili, almeno come singolo componente, ma spesso c’e’ il modo di ottenere cio’ che serve a patto di … scovare la giusta strada.
In piu’ GH permette di utilizzare dei componenti script, che allargano enormemente le possibilita’.
Ultima cosa … secondo me paragonare un linguaggio tradizionale come il Lisp a GH non ha molto senso.
Sono cose diverse: programmazione visuale/grafica rispetto a programmazione con istruzioni di testo.
Pero’ se ti trovi bene con gli script, Rhino permette tranquillamente di utilizzarli, in un ambito decisamente piu’ simile a quanto succede utilizzando il Lisp.
Purtroppo il Lisp non e’ previsto, ma se ci ficchi il naso secondo me scoprirai che Python concettualmente non e’ poi cosi’ diverso.
Certo a patto di imparare una diversa sintassi …
Ma questa e’ solo la mia opinione, per avere quella ufficiale di McNeel bisogna chiedere a Giuseppe …
se non sbaglio lo conosci gia’ … 
Ciao Giuseppe!
Mi va bene tutto, ok anche per il piano ma la matematica non è un’opinione: per descrivere un cerchio si usa centro + raggio e l’origine del piano cartesiano la posso mettere in n posizioni diverse. Dal mio modestissimo e limitato punto di vista preferirei un più ampio controllo dei dati. Grazie di tutto!
Scusa Federico … ultima cosa poi sto zitto (finalmente !).
Dici giustamente: la “posso” mettere dove voglio.
E scrivendo la mia libreria geometrica, come ha fatto McNeel, posso decidere di utilizzare un piano con origine nel centro del cerchio.
Risparmio un punto: invece di salvare origine del piano piu’ centro del cerchio, con un punto unico ottengo capra e cavoli .
( Poi, come ho gia’ detto, se questa informazione fosse piu’ semplice da trovare, meglio ancora )
Ultima anche per me! Comunque vi ringrazio per la vicinanza.
Dal mio modestissimo punto di vista se splittavano i due dati, separando il piano dal centro, sarei stato più contento…
Da quello che ricordo, nello spazio euclideo una circonferenza è univocamente determinata se abbiamo
un raggio,
un centro (O in GH)
e un piano che può essere identificato da
a) la sua normale (Z in GH),
evidentemente questo è il motivo per cui è presente un singolo vettore normale (Z 0,0,1 passante per l’origine ovvero il piano XY) . Se ad esempio scriviamo Z (1,1,1) dovremmo ottenere una normale parallela alla trisettrice del primo ottante, una specie di piano a 45 gradi nello spazio che non ricordo come si chiama.
b) oppure da tre vettori di coordinate linearmente indipendenti
(per tre punti non allineati è possibile trovare un piano comune),
c) l'equazione del piano cartesiano ax+by+cz+d=0
(Avremmo dovuto avere 4 coefficienti, quindi GH non usa questa notazione).
ps oddio, la circonferenza può essere univocamente determinata anche utilizzando equazioni cartesiane, ma nella vita l’uso è: questo è il raggio, questo il piano, questo il centro… vaaai.
Hai ragione secondo me, potevano separare le informazioni.