Guardavo alcuni video del nostro carissimo Marco Traverso e sono rimasto a bocca aperta nel vedere questo:
Sono senza parole…
2 Mi Piace
confermo e sottoscrivo 
Che robetta!!!
Secondo me tutte queste “trasformazioni/deformazioni” dovrebbero poter essere generate nativamente in fase di editing in Rhino. Parzialmente, è ciò che permette di fare la storia di costruzione, ma con GH si ha un livello di definizione e libertà ancora maggiore.
In particolare, tutte le trasformazioni UDT in Rhino, per esempio, dovrebbero contemplare tali possibilità, andrebbero riviste in questa chiave di lettura.
Attualmente è tutto molto rigido, bloccato, poca libertà in questo genere di operazioni, secondo me.
Ecco quello che voglio dire; certamente GH è un altro discorso:
Indubbiamente quello che dici tu sarebbe già un grosso passo avanti, cioè maggiore interattività nelle trasformazioni.
Comunque la mia modesta opinione da utente di Rhino ormai navigato, è che grasshopper pur colmando molti limiti ha un approccio non tipicamente visuale o friendly. Volenti o nolenti si tratta di uscire da una logica di modellazione ad una di programmazione. Ma quanti degli utenti rhino in percentuale ha voglia o ha la possibilità di farlo? Secondo me è necessario ricucire il divario tra Rhino e Grasshopper offrendo un avvicinamento con una tecnica più visual, più interattiva, dove non si vede tutto quell’insieme istruzioni caratteristiche di grasshopper che resterebbe un backend, un’interfaccia dove tu chiedi cosa vuoi ottenere in modo visuale… fantascienza?
5 Mi Piace
Infatti, se noti, nel video utilizza il pannello di grasshopper per “modellare”.
Un pò quello che fai tramite lo script o il plug-in, dai all’utente una serie di campi in cui inserire i valori e ti salta fuori il risultato.
La finestra di GH con tutti i componenti e tutti gli slider alla fine è utile solo a chi crea la definizione.
Molto bravo, lo invidio per quello che riesce a fare.
Concordo! GH è uno strumento eccezionale ma, in verità, il suo utilizzo non è affatto immediato, diciamo che contrasta un pochetto con la logica di modellazione “user friendly” di Rhino.
Difatti è l’unico plug-in (ormai sempre meno plug-in) che si identifica con caratteri decisamente propri e insoliti, oserei dire.
Lo utilizzano in tanti ormai, soprattutto gli architetti, ma se fosse un parametrico da associare agli strumenti di Rhino sarebbe ancora meglio; a me, così come concepito, non piace affatto; non avrei nemmeno il tempo per iniziare da zero a cercare di capirlo e “manovrarlo” alla meno peggio, non so voi… Dovrei iniziare con qualche corso serio, procurarmi un qualche manuale, osservare dei video esplicativi, fare pratica… Al momento non ci penso nemmeno! 
Siamo in perfetta sintonia su questo.
Grazie a tutti per i commenti positivi, fanno molto piacere 
!
Nello specifico con quel demo ho provato proprio ad utilizzare Grasshopper anche come strumento per la modellazione di blend e altre superfici freeform in modo da avere uno strumento flessibile e quasi interattivo.
In realtà alcuni degli strumenti sono delle approssimazioni, perché fino a poco tempo fa Grasshopper non aveva accesso a comandi come BlendSrf (ancora adesso l’accesso ai comandi di surfacing non è completo), quindi gli script costruiscono delle superfici approssimate ricavando curve sulle superfici, creando curve di raccordo (BlendCrv) e poi utilizzando Sweep2 e/o altri comandi. La continuità di tangenza/curvatura non è quindi rigorosa, ma sufficiente per una modellazione di massima (cosiddetta concept modeling).
Sono d’accordo, ed è anche il suo probabile limite. E credo che esistendo oggi Grasshopper, oltre alla Construction History, lo sviluppo di altri strumenti parametrici non sia probabilmente una priorità per gli sviluppatori.
Non sarebbe male una integrazione di questo tipo: magari con un sistema a stack come quello dei “modifiers” o “deformers” dei vari modellatori poligonali, sicuramente meno flessibile di Grasshopper ma più utilizzabile nei casi comuni.
L’idea secondo me è buona: fantascienza forse no - complesso sicuramente sì… si potrebbe avere un’interfaccia in Rhino basata sul motore di Grasshopper (per non dover riscrivere tutto di nuovo), dove la generazione della definizione avverrebbe in maniera nascosta all’utente.
Visto nelle sue potenzialità Grasshopper effettivamente spaventa un po’- alla fine si tratta di un completo ed esteso linguaggio di programmazione.
Però secondo me se già si conosce bene Rhino e ci si avvicina in modo misurato, per risolvere piccoli problemi di modellazione, allora non è così proibitivo e può essere utile da subito.
Ad esempio in meno di 1 minuto si può ricreare un comando UDT interattivo, un array dinamico da proiettare ecc, in modo da poter trovare rapidamente una soluzione esteticamente più valida in modo interattivo. A quel punto si torna su Rhino e si continua da lì.
Ci sono situazioni in cui si opera su molti elementi geometrici oppure ci sono operazioni che in Rhino romperebbero la storia di costruzione.
Ad esempio recentemente mi è capitato di dover dare spessore a delle superfici curve (diverse centinaia), estrudendo ognuna lungo la propria normale calcolata al centro. In Grasshopper ci sono voluti pochi secondi: poi ho salvato la geometria in Rhino e cancellato la “definizione”.
In questi casi Grasshopper è un’alternativa a scrivere script, con il vantaggio di avere un workflow più fluido e di dare un feedback in tempo reale.
In ogni caso anche per fare piccoli interventi è necessario padroneggiarlo, non ci si può certo improvvisare. Serve pratica costante e quando passi il 99% del tempo a modellare in modo classico vorrei poi degli strumenti più immediati. E’ vero che i problemi da risolvere nella modellazione sono infiniti ma in fondo l’interfaccia di Rhino è già una semplificazione di complesse operazioni.
Forse tu Marco potresti sviluppare con grasshopper una serie di strumenti generali, dei moduli (come in fondo già fai) e fornirli agli utenti (con il benestare di McNeel) come pacchetto di plug-in. Forse darebbe il via a percorrere questa strada anche a molti altri utenti del tuo livello e in breve tempo si colmerebbe il vuoto.
Grazie per la tua disponibilità a parlarne
Ovvio, improvvisare no, però per certe cose non è necessaria una conoscenza super approfondita.
Comunque sono d’accordo che avere un’interazione più immediata sarebbe una cosa utile a molti utenti.
Per avere un’integrazione ed un’interattività come si deve occorrerebbe sviluppare un vero e proprio plug-in di Rhino, che a sua volta si integri con Grasshopper, insomma un progetto corposo - e al momento il tempo è veramente poco…
Però parlarne è una buona cosa, a volte le idee si evolvono da sole nella testa e magari ne esce fuori qualcosa!
Grazie a te per lo scambio di idee!
Forse, una cosa che potrebbe aiutare (non so se sia già esistente) sarebbe la possibilità di creare una definizione base partendo da una serie di comandi… tipo un “registra GH”.
Facendolo partire, tutto quello che si fa da Rhino viene “registrato” in GH (nel limite del possibile) e, successivamente, l’utente va a modificare la definizione aggiungendo o togliendo quello che gli interessa…
O magari un “Deriva storia in GH”, così la storia di costruzione diventerebbe più interattiva…
2 Mi Piace
Grazie Sergio! 
Già, sarebbe la cosa più semplice per l’utente, ma decisamente complicata da implementare.
Perché o si crea un plug-in con comandi ex-novo in Rhino che supportano questo (ma allora dovrebbero essere ricreati tutti i comandi da zero e non avrebbe senso) oppure occorrerebbe integrare i comandi esistenti.
In questo secondo caso non so se sia possibile con un plug-in esterno, forse sì, occorrerebbe avere degli event listener che ad ogni invocazione di un comando in Rhino lo “interpretano” creando in Grasshopper i componenti e le connessioni corrispondenti.
Ad esempio, seleziono una curva e la estrudo in Rhino, in Grasshopper viene creato il componente curva con il riferimento alla curva in Rhino, il componente estrusione, il componente vettore (diviso in direzione e distanza) e infine la superficie ottenuta.
Se successivamente lavoro sulla superficie, ad esempio facendo un array, dato che l’ID della superficie è a quel punto già presente in Grasshopper, invece di creare un nuovo componente, si collega il componente array al componente esistente, collegando i vari passi della storia di costruzione. Facile a dirsi, no? 
Altrimenti dovrebbe essere fatto direttamente da McNeel ma la vedo altrettanto dura.
Tra l’altro ne parla David stesso qui: https://discourse.mcneel.com/t/v6-wish-history-on-steroids/4959/5?u=marco_traverso
Forse come ‘estensione’ di GH ?
( Non so se la API per gli add-on consenta di generare delle definizioni … )
Una (o piu’) toolbar con comandi appositi (compatibili con GH) che generino un componente … e credo anche degli oggetti particolari, che conservino il riferimento al componente creante.
Va beh … e’ troppo divertente immaginare queste cose … 
Beh, il post è del 2014… magari adesso i tempi sono più maturi…
Leggere la storia e buttarla in GH potrebbe essere più semplice di allora.
Comunque concordo che dovrebbe essere una cosa implementata direttamente da McNeel più che da uno sviluppatore esterno…
Se con la V7 riuscissero a fare qualcosa… sarebbe come portare una specie di parametricità a macchia di leopardo…
1 Mi Piace
Eh, allora la vedo dura … 
Sarei gia’ molto contento se rendessero GH accessibile da RhinoCommon, per poter costruire ed eseguire le definizioni da plug-in o script.
Sai mai che assumano un altro David Rutten che si mette a fare uno spin off del RhinoGrasshopperizzato!