Mostruoso!

Eh … adesso come adesso sarebbe un mezzo-Rhino.
( Lo vedrei piu’ come in GH-Rhinizzato :wink: , cioe’ fare quello che fa GH con una ‘agile’ interfaccia utente tipo Rhino … Ma sempre come progetto ‘esterno’, se ci fossero gli strumenti per farlo agevolmente. Non sono sicuro, ma non credo che ci siano per ora . Forse con GH2 :slight_smile: )

Per un RhinoGHizzato completo bisogna se non altro sistemare fillet e (relativi) trim … ma forse in futuro Rhino abbandonera’ i fillet del tutto.
( Secondo me potrebbero anche essersi gia’ pentiti di averli inseriti all’inizio … :smile: )
… E i trim potrebbero seguire …

… E allora l’idea di RhinoGHizzato funziona ! :grinning:

M’intrometto in questa discussione, senza entrare troppo nei dettagli e magari saltando diversi passaggi. E’ che questo ed un altro post s’integrano perfettamente con qualcosa che m’è venuta in mente nel rispondere in merito al plugin Xnurbs.

Ho già avuto modo, nel passato, di convenire sulle incredibili, quasi illimitate, potenzialità di Grasshopper.
Uno strumento fantastico, assolutamente imbattibile quando si tratta di esplorare soluzioni e variazioni sul tema.

Al tempo stesso, per le necessità “spicciole” del design in campo industriale (product design), automotive e attività similari, l’interfaccia di GH ha lo stesso impatto limitante ed ostico di un modellatore parametrico.
Mi spiego: per poter sfruttare correttamente le funzionalità di un modellatore parametrico devi necessariamente vincolare lo sketch di partenza, se non esegui correttamente questa basilare operazione, la parametrizzazione rimarrà un’utopia. O un mero esercizio di geometria variabile di tipo frattale. Casuale, incontrollata.

Allo stesso modo, pensare di creare superfici che si sviluppano intorno a dei volumi o comunque dei vincoli preesistenti (il tipico caso dell’elettronica e della componentistica in un prodotto di consumo) utilizzando i nodi e le formule di GH mi pare quanto di meno intuitivo si possa concepire.

Avete menzionato una sorta di GH Recording… idea fantastica. Ma GH non avrebbe dovuto essere lui stesso la Construction History di Rhino ? E com’è che si è arrivati a questo punto, deviando in modo così radicale dall’intento originale ?

Per quel che riguarda GH recording, mi permetto di segnalare che A|W Maya (ora Autodesk) di fatto è un sistema di programmazione con un front end grafico, basato sul linguaggio MEL.
Ogni singolo passo della modellazione genera uno script MEL. E’ semplicissimo, in Maya, aprire la finestra Script e con un semplice cut&paste isolare la porzione di script che riguarda un modello o una determinata azione, copiarlo, trasferirlo sullo shelf, assegnargli un’icona ed eventualmente poi, a proprio piacimento, assegnare slider, switches, dials ecc. creando così una maschera interattiva per la generazione “parametrizzata” di oggetti, oppure per il controllo di movimenti, deformazioni, espressioni.
Tutto può essere controllato e parametrizzato, con una certa semplicità e linearità, in una qualsiasi fase del processo di modellazione ed animazione.

Semplice, complicato ? Non saprei.
Ma certamente logico e lineare.
Io ho customizzato così parecchi processi, nel 2001/2002. Ora ho meno passione per quel genere di cose. Ma… hey, sono solo 18 anni che la tecnologia è disponibile. :smiley:

E qui arrivo al punto. Se confronto il caso appena descritto, con GH ma anche e soprattutto con un’innumerevole sequela di applicazioni e comandi che di questa linearità e logica non hanno proprio sentito parlare, pur avendone un enorme bisogno, mi vien da chiedere:
Ma alla McNeel che hanno nella testa ? Come li selezionano i programmatori ? C’è qualcuno con un minimo di expertise in UX Design ? Esiste un project manager ? Un Development Coordinator ?
Non intendo polemizzare, sono domande che mi pongo davvero, e che non trovano risposta.
Se ad esempio penso che nel tempo hanno generato prodotti semplicemente assurdi, cervellotici ed inutili come Bongo, allora inizio seriamente a preoccuparmi.
Anche perché ho seguito a suo tempo il forum su Bongo, e le risposte del team McNeel erano semplicemente disarmanti, lì a testimoniare che questi vivono su un altro pianeta, totalmente disconnesso dalla realtà.

E sì che, per chi come me si occupa di Product e Yacht Design, un minimo di cinematica servirebbe come il pane. Ma è mai possibile che non si possa comprendere che ciò che realmente serve nel mondo reale sono un minimo di vincoli e di parametri da assegnare in modo pressoché automatico (se disegno una ruota o un ingranaggio, insomma un cilindro e lo devo centrare e connettere al mozzo di un asse, un cilindro allungato, ma sarà così difficile da capire dove e come i due elementi dovranno essere connessi, quali vincoli dovranno essere assegnati e quanti gradi di libertà potranno essere concessi (con dei semplici slider e selettori) ?

E’ proprio necessario essere meritevoli di un premio Nobel per la Usability, per risolvere questo genere di problematiche ?

O basterebbe un minimo di organizzazione aziendale, meno matematici teorici e più coordinatori user oriented ?

E’ necessaria una laurea in Rocket Science and Quantum Computation for Prediction Analisys, per capire che dopo 25 anni di onorata carriera anche la User Interface di Rhino ha finalmente bisogno d’essere riveduta e corretta ?

I geni della Mc neel hanno mai visitato un Design Center in vita loro ? Hanno mai visto l’approccio pragmatico che ancora oggi vede il clay model al centro del processo, indubbiamente interfacciato e strettamente correlato ai processi di modellazione digitale, ma pur sempre un passaggio chiave, insostituibile per la definizione delle forme e dei dettagli finali.?

Io ho modellato (sul vecchio Computervision ma anche con il vetusto 3DS4 su DOS) prodotti complessi come ad esempio un intero laptop, nei minimi dettagli (incluse cerniere, viti, persino la cpu 486 con i suoi pin), utilizzando solo ed esclusivamente coordinate spaziali e comandi, zero uso del mouse, zero interattività. Ma anche componenti d’arredo, sedie ecc. E’ indubbiamente possibile, ma principalmente quando ricostruisci una realtà esistente, basandoti su punti di riferimento noti.

Il processo creativo è un’altra cosa. E non può essere assoggettato a slider, nodi, formule matematiche ecc. Quelli vanno benissimo, ma nella fase successiva, della manipolazione e dell’esplorazione di serie variazionali. In quel caso sì, indubbiamente, uno strumento fantastico.

Non è necessario reinventare l’acqua calda e nemmeno la ruota del mulino, basta guardarsi in giro e selezionare le tecnologie e gli strumenti più opportuni ed efficaci.
Lasicando gli accademici ad occuparsi di algoritmi e formule matematiche, non di processo e d’interfaccia utente.

Chissà se in McNeel lo capiranno mai.

1 Mi Piace

Ciao Paolo, grazie per il contributo approfondito (ho letto anche il tuo interessante intervento sul tread di Xnurbs).

Ti rispondo su un paio di cose

Se capisco quello che intendi, questo non è necessariamente vero. Uno dei punti di forza di Grasshopper è che può essere “inserito” in qualsiasi punto della modellazione e nel modo che preferisci.

Ovviamente si possono creare superfici a partire dalle curve che le definiscono, però è anche possibile partire da superfici già modellate “a mano” ed eventualmente modificarle parametricamente.
Oppure lavorare su geometrie già costruite per proiettare curve, costruire pattern, fare operazioni di trim ecc. mantenendo la parametricità e la non-distruttività.

Anzi, secondo me nel campo del design è proprio in questo approccio ibrido che Grasshopper dà il meglio di sé, perché lo puoi usare dove ti fa risparmiare più tempo e dove non devi conoscerne necessariamente tutti i segreti. Ad esempio: valutare il design di una griglia o di una texture su una superficie: il setup con Grasshopper richiede pochi minuti e puoi modificare le geometrie da proiettare ed avere un risultato (anche con render) in tempo reale, potendo così valutare tantissime opzioni e scegliere la migliore senza necessità di ricostruire alcunché…

Ammetto che a volte questo può diventare facilmente un lavoro più da “programmatore” che da “designer” - d’altra parte Grasshopper è un linguaggio di programmazione, pur senza sintassi e comandi scritti.

Personalmente mi trovo a metà strada tra le due figure, e questa è probabilmente una delle ragioni per cui mi sento a mio agio, ma capisco che è un approccio che possa non piacere.

Sicuramente necessita di un approccio diverso. Personalmente ho esplorato molto le possibilità di Grasshopper in campo industrial/product design e ci sono dei limiti, principalmente:

  • non tutti i comandi di surfacing sono disponibili - uno per tutti BlendSrf. Il che rende di fatto impossibile creare un modello “finito”, ma occorre limitarsi ad un concept
  • Per oggetti complessi la parametrizzazione “completa” può richiedere molto tempo - impostare i parametri, costruire gli elementi di base ecc.

Per il resto sinceramente ho trovato pochi limiti. E vedo le cose molto rosee in ottica SubD.

Però magari mi sfugge qualche applicazione: se ti va di farmi un esempio di come vorresti impostare un modello di product design con dei vincoli in modo parametrico posso provare a darti una risposta relativamente a Grasshopper.

L’idea in effetti è molto buona e consentirebbe di risparmiare molto tempo e/o di semplificare la costruzione di una definizione parametrica di base.

Anche se il nome originale di Grasshopper era “explicit history” in realtà lo stesso David Rutten ha recentemente spiegato come l’idea fosse sin dal principio quella di fornire un ambiente “visuale” e non necessariamente una “storia di costruzione” pura.

D’altra parte allora (come oggi) non esistevano gli strumenti necessari ad uno sviluppatore per poter replicare tutti i comandi di Rhino e creare una storia di costruzione vera e completa - e questo lo so perché prima ancora che ci fosse Grasshopper (stiamo parlando del 2003) ci sbattei il naso anche io.

Io oggi tendo ad interpretare Grasshopper non come uno strumento di modellazione ma più come un sistema che consente di creare modelli con algoritmi senza dover scrivere codice: e il principale vantaggio secondo me non è quello di non dover conoscere un linguaggio di programmazione, ma il fatto che quando si passa dalla modellazione alla scrittura del codice il cervello deve cambiare approccio: si passa dal ragionare in modo “visuale” con mouse o tablet a dover scrivere sulla tastiera, e questo (almeno nella mia esperienza) fa perdere il collegamento con quello che si stava facendo. Si deve tradurre il processo “geometrico” in un processo “linguistico”.

Invece con Grasshopper il ragionamento rimane sempre basato sulla geometria - non devo pensare alla sintassi, ai nomi delle variabili, ecc. - e il tutto risulta più fluido, anche perché il “debug”, cioè vedere come lavora l’algoritmo, avviene in tempo reale: collego due punti con una linea, vedo subito la linea (senza dover eseguire lo script) e quindi passo all’operazione successiva.

Quindi io vedo Grasshopper più come una semplificazione dello script che come una complicazione della modellazione.
E, pur sapendo in linea di massima scrivere il codice che mi serve, con Grasshopper mi “diverto” 100 volte di più e mi trovo spesso a preferirlo per sviluppare e testare algoritmi nuovi, che magari una volta completati potrò convertire in C# o Python per avere maggiore efficienza.

Però il tuo punto di vista è estremamente importante e sicuramente rendere accessibile Grasshopper a più utenti è qualcosa che in McNeel terranno in considerazione…

In pratica una “linea di comando” ancora più completa ed avanzata… Molto interessante - anche Blender funziona in modo simile, registrando le varie operazioni direttamente in Python.

Il problema di questi sistemi è la logica sottostante. Diciamo che io voglia creare un prisma a base poligonale con n lati e poi voglia estrudere alternativamente i lati del poligono della base superiore. Un sistema “robusto” dovrebbe essere in grado di riconoscere le mie azioni, e registrarle in modo che possano essere ripetute per poligoni con diversi numeri di lati. Fattibile? Tutto è fattibile… Semplice? non lo so…

Con Grasshopper un’operazione del genere viene fatta in 10 secondi se lo sai usare, e quindi non è più il collo di bottiglia… Però è uno strumento che occorre studiare.

Su questo ti rispondo senza avere una conoscenza diretta, quindi prendimi con le molle… In questi casi più che un sistema in grado di “riconoscere” il tipo di vincolo da utilizzare, non sarebbe utile avere dei template preimpostati che coprano i casi più comuni? E in questi casi , in assenza di template ufficiali, non sarebbe fattibile da parte dell’utente?

Sono talmente d’accordo che personalmente il vero processo creativo lo vedo proprio fuori dal computer,cioè nella testa e con carta e matita - al massimo un tablet con la penna :slight_smile:

Ciao Marco, e grazie per la tua pronta ed esaustiva risposta. :slight_smile:

Io sono andato giù un pochino “diretto” e forse pure “pesante” il fatto è che nel rispondere su XNurbs, leggendo alcuni commenti che in qualche modo andavano oltre lo specifico plugin, s’era accesa prepotente la spia d’allarme riguardante l’interfaccia utente e, più in generale, l’approccio spesso discutibile alla sintassi ed all’operabilità dei comandi che, unitamente alla cronica deficienza della documentazione che da sempre affligge i prodotti McNeel (ne abbiamo parlato decine di volte con Giuseppe) rende spesso farraginoso, unpredictable, insomma inutilmente complicato l’uso di certi comandi. Vedi ad esempio il thread sul flow on surface.
Per Giuseppe sarò pure corretto ed intuitivo, io devo dire che è nell’elenco, piuttosto lungo, delle funzioni che mi hanno fatto bollire il sangue.

In effetti avevo intuito anch’io la possibilità di intervenire su superfici modellate, inserendo elementi di geometrie parameterizzate e spesso complesse, e l’ho anche utilizzato in alcuni casi estremamente concreti. Se mi riesce magari posto un paio d’immagini, se le trovo.

Io sarei felicissimo di poter inserire Grasshopper nel processo progettuale, purtroppo l’approccio prescelto non è tra i più invitanti. Mentre invece quello visualizzato nella tua demo, con l’interfaccia interattiva sarebbe perfetto, esattamente quello che è possibile realizzare in maya e che a suo tempo avevo creato per alcune applicazioni.

Per finire, quando menziono la catena cinematica (una grave lacuna in Rhino) e l’assegnazione dei vincoli, io non chiedo realmente un riconoscimento così automatico come ho espresso. Mi sono spinto un pò in là, in effetti. Anche se sono conscio che oggi non sarebbe per nulla impossibile.
Sarebbe sufficiente un approccio simile ai vincoli di Solidworks (mates più che costraints) il più possibile semplificati (due cilindri dovrebbero riconoscere e proporre il vincolo di concentricità e l’asse corrispondente) con la possibilità di assegnare (da tabella, come nel tuo esempio) direzione e limiti dei gradi di libertà.
Nel caso di ingranaggi, sarebbe opportuno poter assegnare vincoli di tangenza alle superfici, magari prevedendo pure delle tolleranze.

Un minimo di IK da assegnare al classico figurino antropomorfo, per semplificare il posizionamento e l’interazione con gli oggetti circostanti.
Questi sono strumenti che realmente servono, in una logica ed un approccio il più distante possibile da Bongo, Flamingo, Neon, e tutte le altre assurdità in cui hanno incredibilmente sprecato risorse.

Altro punto dolente, ma veramente, ed è semplicemente vergognoso: l’interfaccia utente della gestione materiali. Un abominio.
Inutilizzabile. L’unica App che funziona decentemente è Keyshot, perché si limita al “bridge”, saltando a piè pari la gestione materiali in Rhino.
A suo tempo avevo preso Octane… una pena. Provato VRay… due dita in gola…
Ho utilizzato per anni con successo MaxwellRender, ma anche in quel caso saltavo a piè pari il Material Management in Rhino.

Se non si sbrigano a darsi una regolata, non la vedo particolarmente rosea.
Rhino ha ancora un buon potenziale, ma ha anche accumulato un deficit abissale in termini di usability.

Io avevo quasi deciso, al 90%, l’abbandono totale. Ora però sto per far partire un grosso progetto di Yacht Design in Oman e onestamente Rhino ha un suo significato nel campo della nautica. Anzi, proprio nel progetto (già approvato a livello governativo) Grasshopper potrebbe avere un’applicazione importante. Sono valutazioni che dovrò fare nelle prossime settimane, magari ti contatterò per parlarne.
Grazie ancora e Buona Notte

Ciao Paolo

Se ti va di postarle gli darò un’occhiata molto volentieri.

In effetti manca quel tipo di interfaccia diretta: al momento occorre crearsela da soli (il che non è in realtà troppo difficile) o farsela creare, ma questo ha senso in casi in cui le stesse operazioni devono essere ripetute molte volte.

Per quanto riguarda Bongo non conoscendo il prodotto non posso esprimermi, sicuramente concordo che tra Flamingo e Neon penso siano state spese molte risorse: è anche vero che da “esperimenti” a volte nascono delle gemme e quindi un po’ di spirito di esplorazione è positivo, ma probabilmente a volte si sono trascurate cose più importanti.

Sinceramente per le operazioni basilari non trovo la gestione così tremenda rispetto ad altri software (io ho usato Cinema4D, MODO e Blender) - certo Keyshot ha nell’usabilità il suo punto forte, probabilmente dovrebbero prendere spunto proprio da lì.

L’altro problema sul rendering è che purtroppo siamo in un momento di transizione: il render di qualità “Raytraced” si basa su Cycles di Blender, che è un “signor” motore di rendering: però non è molto intuitivo e la gestione dei materiali più complessi avviene - ti sembrerà una maledizione :slight_smile: - proprio attraverso un sistema di nodi sull’interfaccia di Grasshopper! Ma il vero problema secondo me è che l’implementazione non è ancora completa e mancano alcune cose che sarebbero molto utili (denoiser, color management, ecc.) Quindi alla fine se vuoi usare Cycles, tanto vale esportare e lavorare direttamente in Blender…

Sicuramente certi aspetti non si sono evoluti quasi per niente (UI) o sono rimasti affetti da problemi decennali (vedi i limiti degli strumenti avanzati di surfacing ). Probabilmente è anche cambiato il target dell’applicazione, con meno designer puri e più architetti o comunque utenti che non necessitano di geometrie particolarmente complesse.

Io il futuro però lo vedo in modo ottimistico, soprattutto perché con le SubD sarà possibile integrare il meglio della modellazione poligonale (possibilità di scolpire facilmente superfici organiche mantenendo la continuità di curvatura) con il meglio delle superfici NURBS (controllo dimensionale, facilità di taglio, trim ecc.) e il tutto parametrizzabile con Grasshopper.

Certo, se ti va contattami pure.

Grazie anche a te e buona notte :slight_smile:

OOOOOHHHH Ecco Paoletto nostro!
Ti avevo lsciato in Oman.
Ma non ti sei rotto?
Adesso dove sei? Che combini?
Sono stato dalle tue parti a salutare Cossutti.

Il progetto in Oman è completamente approvato, a livello ministeriale, ma il primo giorno di Ramadan s’è improvvisamente bloccato, causa problemi tra il mio cliente e il suo partner finanziario/industriale. Il solito Arabo avido e sfruttatore. Capita spesso tra le nuove generazioni, gli anziani sono più affidabili.
Il Ministero mi ha poi introdotto un nuovo investitore, un grosso gruppo, i presupposti sono ottimi, ma l’estate ha rallentato tutto. Dovremmo ripartire tra una quindicina di gg.
E mi sono evitato la calura… non tutti i mali vengono per nuocere.
Ora inizia la stagione bella.

:slight_smile:

Ti perdi la Barcolana… io vado!

non è detto del tutto. Se riesco passo in zona. In caso ci si vede.

L’ultima che ho presenziato era esattamente 10 anni fa.

@MarcoTraverso relativamente al video che è stato inizialmente linkato, sarebbe possibile avere dettagli su come ottenere le definizioni

e
?

Chiedo troppo?

Come si crea il pannello Lucio?

Condivido.

Ciao Luca,

Appena riesco vedo di recuperare le definizioni e cerco di postare qualcosa

1 Mi Piace

In Rhino lo attivi cliccando con il destro sopra la toolbar con le varie schede e spuntando “Grasshopper”,

Grasshopper%20Panel

poi in Grasshopper clicchi con il tasto destro sopra uno degli input supportati (slider, toggle booleani, checkbox, pulsanti ecc.) e selezioni “Publish to Remote Panel”.

Publish%20to%20remote%20panel

1 Mi Piace

ciao Giuseppe,

Cossutti Yacht Design ?

ciao , Andrea

Ciao Andrea!
Si. Troppo simpatico…e bravo. Come lo conosci?

ciao Giuseppe,
non lo conosco , ma ho fresato alcune chiglie e dei bulbi per una fonderia sua fornitrice .
ciao , Andrea

Gli hai fornito anche il piombo o solo fatto fresatura?

No solo la fresatura dei modelli