Buona sera ragazz*, mi piacerebbe capire se la mia è una richiesta che possa avere un gran riscontro o è solo un capriccio di uno che non ha grandi capacità! In questi giorni mi è stato proposta la possibilità di conoscere un software di modellazione diretta ma che ha delle possibilità di operare anche in ambito parametrico, qui mi è esploso il cervello. La facilità di poter controllare un modello 3D con delle funzioni parametriche è incredibile, ovviamente per il mio abito di occupazione, ma non ha la complessità del nostro mostro Grasshopper ed in pochi minuti si è già pronti per operare. La mia domanda: è possibile pensare ad integrare un ambiente paramentrico “facilitato” per le comuni e banali modellazioni per chi non ha velleità di far concorrenza a Jan Olav Jensen e Børre Skodvin. Grazie e se è stato fuori luogo mi potete bannare 
Ciao.
Ma perchè mai bannare!!! Domanda lecita.
La risposta, al momento, è semplicemente no.
Il motivo è banale.
Sviluppare un kernel di modellazione parametrica in parallelo allo sviluppo di Rhino è eoni-anni-luce fuori dalla nostra portata.
Quello che fanno molti/tutti è affittare codice fatto da altri. Questa è una scelta che non faremo mai dato che non ci piace essere tenuti per le pa…rti intime.
Ciao Giuseppe, grazie sempre per la tua disponibilità e chiarezza, capisco perfettamente il punto di vista e lo condivido, mi dispiace per questa possibilità mancata
Eppure secondo me non e’ una cattiva idea … 
E, se ho capito bene, non si parla di replicare il funzionamento dei normali CAD parametrici, cosa che richiederebbe appunto di utilizzare un kernel tipo Parasolid o di svilupparne uno simile.
Piuttosto credo che l’idea sia di cercare (ipoteticametene, OK) un modo proprio di Rhino/McNeel, come mi sembra succeda per molte altre feature di Rhino, per utilizzare la modellazione parametrica.
Entro certi limiti, certo.
Ma del resto, dato che Grasshopper utilizza il kernel di Rhino, i limiti sono gli stessi che valgono anche per Grasshopper.
Quello che a mio avviso manca, per cosi’ dire, non e’ tanto la possibilita’ di costruire una cosa simile utilizzando il software gia’ in possesso di McNeel, quanto la convinzione che una simile impostazione sia utile e forse anche apprezzata dagli utilizzatori.
Mi sembra una questione piu’ strategica che tecnologica.
Del resto, e la cosa mi ha sempre stupito, diciamo almeno da quando e’ apparso Grasshopper, a quanto ricordo ci sono state pochissime (se non nessuna) richiesta di questo tipo sui forum.
In pratica mettere insieme Rhino e Grasshopper per ottenere un CAD semplice e senza troppe pretese, almeno da un certo punto di vista, ma che possa anche essere usato, se non altro per certe cose, parametricamente.
A me e’ sempre sembrata la cosa piu’ logica da chiedere a McNeel, ma, ripeto, da quanto (non) si legge sui forum, agli utilizzatori (che appaiono sui forum) pare non interessi.
In questo ambito McNeel preferisce impegnare risorse nella History, e forse con Rhino 9 nei constraints, cioe’ sviluppare nuova logica piuttosto che cercare di utilizzare al meglio quella che c’e’ gia’ (secondo me).
Legittimamente ovvio, ci mancherebbe. .
McNeel ha dimostrato di saper sopravvivere nel mercato CAD per oltre 20 anni, quindi tanto di cappello !
Mah … forse si teme di perdere la facilita’ d’uso del direct modeling, anche se personalmente non vedrei la necessita’ …
Forse altro … .chissa’.
Come dice Emilio, qualcosa si potrebbe fare forse, ma è un mercato diverso e troppo battuto dove non potrebbe primeggiare e anzi lo metterebbe malamente in confronto coi big. Invece nel freeform programmabile Rhino cammina a testa alta e fa un signor lavoro.
Se serve qualcosa di gratuito e ben fatto c’è freecad
Ciao Emilio, esatto! L’idea era di pensare ad un “ponte” tra la modellazione diretta e Grasshopper! Se Rhino si avvicina ad un parametrico senza voler competere con i big non credo che possa perdere la sua storica caratteristica di modellatore, anzi ne acquisterebbe un valore aggiunto che strizza l’occhio alle mode e necessità contemporanee.
Ciao Anto,
Gia’
Ma come sempre e’ diffcile, se non impossibile, interpretare cosa succede nell’ecosistema di Rhino, diciamo cosi’. 
Secondo me l’unica speranza per indirizzare McNeel in questa direzione sarebbe un buon numero di richieste in tal senso provenienti dal mondo dell’architettura, che ultimamente mi sembra riesca ad orientare maggiormente Rhino verso il proprio ambito.
Del resto Grasshopper e’ stato ideato ed e’ tutt’ora sviluppato da un architetto.
E a mio avviso il kernel geometrico di Rhino si adatta bene a lavorare in quel settore.
Il fatto che fino ad ora cio’ non sia avvenuto, almeno a quanto ne so io, potrebbe dipendere dal fatto che (supposizione mia, correggimi se sbaglio) chi lavora in architettura non ha avuto molte occasioni di conoscere i CAD parametrici, come succede ad esempio per la meccanica.
Penso che invece la tradizione in quel campo riguardi piu’ AutoCAD o programmi simili, ma ora vedo molto citato Revit, forse le cose stanno cambiando … non so.
D’altro canto Grasshopper e’ squisitamente parametrico, ma forse molti si trovano bene appunto con Grasshopper. Non sentono la necessita’ di avere le stesse possibilita’ in un ambiente piu’ snello.
Mi viene da pensare: “Se hanno tutto questo tempo, mi fa piacere, buon per loro ! ”
E probabilmente nemmeno in McNeel si vede la necessita’ di esplorare questa possibilita’.
Anche perche’ decidere come impostare una cosa del genere potrebbe non essere banale.
Bisogna sostituire in qualche modo i link (se si chiamono cosi’) di Grasshopper, oltre probabilmente a ‘miscelare’ in qualche modo comandi di Rhino e di Grasshopper, e sarebbe bello anche un modo per vedere/editare questi vincoli.
Una mia vecchia idea sarebbe utilizzare i livelli per questo, ma certo ad altri l’idea potrebbe non piacere.
Oppure utilizzare il classico albero degli oggetti che usano i CAD parametrici, ma bisogna costruirlo da zero. L’albero, secondo me, avrebbe anche il vantagio di agevolare l’importazione delle geometrie dai suddetti CAD parametrici.
Mi sembra di leggere sui forum di problemi appunto in questo tipo di importazioni.
Se poi si riuscisse a collegare molto piu’ strettamente Rhino e Grasshopper secondo me sarebbe la cosa migliore.
Anzi, personalmente non ho mai capito perche’ grasshopper non sia stato integrato fin dalla nascita ‘dentro’ il workflow di Rhino e sia invece stato tenuto, direi accuratamente, separato.
Tutto sommato penso che ‘parametrizzare’ Rhino in qualche misura sarebbe certo un’ottima cosa, ma lo sviluppo sarebbe certamente impegnativo.
Come dicevo, credo dipenda molto dalla quantita’ di richieste.
… Che per ora, almeno leggendo i forum, temo sia una quantita’ parecchio ipotetica … 
Emilio, secondo me c’è un problema di fondo.
Se modello un aereo o una gru in SolidWorks (Parasolid), la variazione di un parametro mi comporta attese di un secondo più o meno, qualcosa di simile, fatta con GH, mi inchioda il pc per 30 minuti.
La gestione dei dati in memoria non è ottimizzata, non so perché, ma quando arrivo a questo livello di modellazione parametrica mi fermo e dico: benedetta Dassault (almeno da questo punto di vista ). Ecco perché è impensabile lavorare nella meccanica con Rhino, pur avendo la buona volontà di costruirsi il modello. GH va bene per modellazioni con bassa complessità.
PS che non sia dotnet?
esatto, infatti a questo “brige” parametrico non verrebbero richiesti modelli molto complessi (già ci sta Grasshopper per questo!). Mi occupo di interior design e spesso mi trovo a disegnare scatolette (mobili) e pannelli (boiserie) che per varie ragioni, ccommittenti/tecnici/cambiamento del mio gusto, devo sempre risistemare mille volte e, capite benissimo, che con una modellazione diretta è una grossa scocciatura.
Preciso che le macchine che utilizziamo allo studio sono tutte Mac 
Ciao Luca
Haha …
Pero’ e’ interessante !
Ricordo di aver letto qualcosa su GH2 … a proposito, lo hai provato ?
David diceva che GH1 e’ rallentato da troppe conversioni di dati.
GH2 cerca di utilizzare i dati originali per quanto possibile, mentre GH1 converte i dati in ingresso e in uscita dai componenti utilizzando delle classi custom di GH senza preoccuparsi troppo.
Anche il fatto che GH sia molto tollerante sul tipo di dati in ingresso concorre a perdere tempo.
Non so, penso sarebbe comunque interessante fare un confronto fra GH1 e GH2 sul tempo di ricalcolo.
Ma credo che GH ‘perda’ comunque del tempo, appunto perche’ in ingresso ai componenti deve accettare un po’ di tutto …
Forse puo’ concorrere anche il grafo dei componenti, come sono collegati tra di loro caso per caso.
Nel senso che forse a volte vengono fatti dei calcoli superflui, ma non so … sono cose per sentito dire (cioe’ letto sul forum).
Non ho idea su quanto dotNET rallenti il calcolo o meno …
Entro certi limiti la cosa vale anche per Rhino, almeno per le versioni che utilizzavo io, e credo anche per gli altri CAD, in misura probabilmente diversa.
Pero’ direi che c’e’ comuque una bella differenza tra modificare un modello a mano, come facciamo normalmente con Rhino, e farlo fare a GH.
Sia che il modello sia complesso, sia che sia semplice.
I tempi cambiano nei due casi, ma il rappporto tra rifare a mano e rifarlo con GH penso resti comunque favorevole per il ricalcolo automatico.
Secondo me il fatto che una potenziale feature non sia utilizzabile sempre non giustifica la rinuncia a svilupparla.
La userai quando serve e ti sara’ molto utile in quei casi.
Per gli altri casi si useranno altre cose.
Cosa c’e’ di male o di strano ?
E’ un ragionamento che ho letto a volte fatto da McNeel (scartare una cosa perche’ non sarrebbe di uso universale) … e francamente mi fa un tantino infuriare. 
Come se i comandi che abbiamo funzionassero sempre e comunque … 
Be’ … direi che dipende da cosa disegni e da come lavori.
Per alcune cose non e’ male, per altre si’.
Dipende da molte cose …
E comunque quando si usa per la meccanica a quanto ne so e’ molto spesso per una questione di prezzo, oppure viene utilizzato in parallelo con altri software per operazioni specifiche.
Inoltre, anche leggendo varie esperienze sul forum, ho imparato che con un bel po’ di ingegno si possono far fare a Rhino cose incredibili.
Rhino e’ molto versatile … e quindi molto difficile da sfruttare a fondo.
E va bene cosi’ ovviamente.
… e Siemens e PTC … e forse qualcun altro ancora.
E va be’ … si parla di altre classi di prezzo.
Questo non e’ paragonare mele e arance, questo e’ paragonare la mela col seme.
Non ancora, ma pare abbiano rinominato tutti i componenti, c’è quasi da ricominciare da capo.
Anche io ho letto che è stato riscritto il codice per l’esecuzione in parallelo e altro
Ho il codice C#, potrei passarlo in GH2, ma forse non si può fare ancora.
Scusate se mi permetto ma vorrei farvi notare che Grasshopper è molto più semplice di quanto pensiate e avete a disposizione tutto quello che serve per essere totalmente indipendenti. Cercare scorciatoie per evitare di fare quella minima fatica iniziale per comprendere uno strumento non è mai stata la mia scelta. Ho creato e vendo un plugin che non cerca di replicare o sostituire Grasshopper ma convivere con lui e con gli altri strumenti di Rhino, e lasciare l utente libero di usarlo o meno senza schiavizzarlo come ho letto in un post. Il tutto sempre per forrnire all utilizzatore strumenti intelligenti per sfruttare la propria capacità e fantasia. Ancora non siamo in grado di fornire la voglia di faticare ahahahahaah
C’era qualcosa che bolliva in pentola e che avrebbe reso Rhino 8 ‘parametrico’, ma per ora sembra che sia stato rimandato alla versione 9.
Mi sembrano i soliti tempi di McNeel. Ci siamo abituati.
Tra l’altro se ben ricordo i constraints sono basati sul lavoro di Daniel Piker.
Bene che arrivino nuove idee e nuove capacita’ …
Qualcosa trovi qui, da quello che ho intuito era lui che si occupava di sviluppare i vincoli per Rhino.