sei un ganzo!
Le SubD rappresentano un po’ una novità, non tanto nel vasto panorama dei CAD, già presenti da diverso tempo in molti software, ma all’interno di Rhino. Pertanto, ritengo sia comprensibile tutto questo stupore ed entusiasmo. Però, non vorrei che questi nuovi strumenti facessero perdere di vista la base su cui Rhino è stato concepito ed ha rappresentato, da sempre, il suo punto di forza: la modellazione di superfici (creazione ed editing).
Mi auguro che il processo di innovazione, che passa anche attraverso gradite aggiunte (SubD), proceda di pari passo al miglioramento e potenziamento di tutti gli strumenti (fondamentali) di generazione e gestione delle superfici, sperando, quindi, che l’attenzione rivolta ai comandi SubD non infici su tanti altri aspetti.
Le SubD si affiancheranno alla modellazione rigorosa di tipo Nurbs, ben vengano, ma, da architetto e appassionato di design in genere, avrei preferito che Rhino risolvesse con maggiore decisione molte sue lacune e carenze; in fin dei conti, le SubD appaiono più come un simpatico “gioco” di modellazione che strumenti a cui affidare intere progettazioni o, ancor peggio, serie produzioni.
Domando: <<Chi utilizzerà le SubD all’interno di Rhino?>>. L’architetto? Credo poco. Il designer? Questo forse sí, anche se preferirebbe avere strumenti di fillet e blend migliori; l’orafo? I creatori di computer grafica? (quelli alla “Pixar”, per intenderci). Nel campo navale, aerospaziale, automotive? (ma per questi esistono ben altri generi di CAD…).
Le SubD sono un’aggiunta alle Nurbs, e lo sforzo che si sta facendo, è quello di far dialogare queste due entità. Ottimo direi!
Altrettanto ottimo, se posso aggiungere, è l’aver realizzato, finalmente, un ‘multiblend’ degno di nota, attraverso un plug-in (XNurbs), apparentemente banale e insignificante ma che dà a Rhino la possibilità di risolvere molte carenze e ampliarne le sue capacità (credo che in molti ne facciano uso e sia stato ben voluto; se ne sentiva la mancanza, eccome! Ora, mi raccomando, voi della McNeel, fatevelo “rubare” dalla Autodesk!).
Alle volte basta davvero poco per creare il cosiddetto “effetto wow”! CAD è anche fare giusto marketing e strategia…
Rispondo nella pausa di un corso quindi perdona la brevità e l’ordine sparso.
- XNurbs è un progetto esterno. Appartiene ad altri che ci faranno quello che meglio pensano. Noi non facciamo la “spesa” quindi non c’è nulla da soffiare. Se vogliono continuare a sviluppare per Rhino bene, diversamente bene lo stesso.
- Liquidare le SubD come una “cosa” che esiste da anni è come dire che L’auto elettrica esiste dal 1835. Forse un filo di approfondimento matematico non guasterebbe.
- Credi male. Chi usa SubD? Ti stupiresti… di quanti studi di architettura primari, nel mondo, usano costantemente le SubD… e quanti facciano avanti e indietro con Rhino 5 per questo. Sei talmente fuori strada che hai completato il giro. Fidati.
- SubD= gioco di modellazione per creare effetto WOW e/o arma di distrazione e marketing invece di migliorare le NURBS. Premesso che SubD e NURBS non sono mutuamente esclusive., quello che mi sorprende è che non hai capito la portata della cosa. Cioè del passaggio NURBS SubD MESH potendo fare il viaggio in entrambe le direzioni.
Quando ti sarai reso conto, ne riparliamo.
A Mcneel parli di marketing e strategie? Eddaiiiiiiii
Il mio discorso era un tantino diverso; capisco l’importanza di tutto il progetto e non è mia intenzione svilire un lavoro così prezioso e di grande portata per Rhino.
Chissà perché le SubD sono diventate importanti e stra-utilizzate proprio ora e, difatti, spuntano all’improvviso con la wip in continuo divenire: software come SolidThinking, FormZ, Catia, Ugs NX, ecc, le hanno implementate da diversi anni… Sarà una moda e, quindi, bisogna adeguarsi?
Va bene, Rhino propone qualcosa di nuovo, di convincente, senza scendere in particolari tecnici (forse più di quanto proposto da Tsplines o Clayoo), per questo me ne compiaccio…
Volevo solo far notare che alcune priorità sono state un pochetto trascurate (e qua si inserisce perfettamente lo sviluppo di XNurbs come strumento “esterno”). Tanto per fare un esempio più prossimo, trovi che una “Patch” rimasta pressappoco uguale in tutto il suo sviluppo, sia davvero convincente e faccia onore ad un modellatore freeform di superfici? Io avrei preferito che uno strumento come Xnurbs venisse sviluppato da McNeel e proposto come, finalmente, qualcosa di necessario e prioritario (è una mia opinione, figurati!).
Come dire che uno smartphone abbia una CPU preistorica (non possiamo fare altro, tenetevela così com’è), però di contro abbiamo inserito uno schermo 4K con miliardi di colori perché in qualche modo vi vogliamo impressionare.
Davide guarda: io non voglio convincere nessuno ma non voglio essere convinto.
Le SubD non “spuntano all’improvviso…chissà perchè”… spuntano perchè uno strumento come le T-Spline (simile alle SubD non la stessa cosa) tratteneva un numero enorme di utenti dall’ aggiornare. Così tanto per chiarire quanto “pochi” sono quelli che le usano…
Il tuo “improvviso” sono anni di lavoro fra concretizzare le fondazioni matematiche (hai una vaga idea…?) le librerie e gli strumenti di utilizzo. Improvviso… non siamo andati da Siemens ad affittare una kernel. E’ diverso.
Se brutalmente vuoi “pesare” XNurbs contro SubD+Quadremesh perdi 4-0.
Ma lo hai letto il post di Fabio Gambler con la mano? Tu ci vedi solo una manina allungata?
Per me le discussioni sui Massimi Sistemi della modellazione si chiudono qui.
Sempre volentieri a disposizione ogni volta che mi dirai cosa devi fare (caso specifico) e cosa ti manca.
Abbiamo detto come la pensiamo e ora, serenamente e Francescanamente…andiamo avanti.
Mi piacerebbe che a questo dibattito partecipassero anche altri utenti, capire come la pensano e, soprattutto, sapere se, per loro, le SubD rappresentano un sistema utile e indispensabile.
Non si tratta di convincere nessuno.
Molto francescanamente ringrazio la tua persona che, sempre con molto garbo, perde tempo a scrivere e a rispondere alle mie “illogiche” di pensiero.
Le subD nel mio lavoro sono fondamentali, quanto è Mancato tsplines è come se mi avessero mozzato un braccio. Concordo pienamente con Giuseppe sui tempi di sviluppo delle subD ( non sono un programmatore ma mi diletto ) e capisco benissimo quelle che possono essere le difficoltà e le problematiche.
Xnurbs provato e cestinato.
E poi smettiamola con le solite polemiche ,ogni volta che scrivi mi vien il mal di pancia ,sempre a fare confronti con altri software o perchè fanno questo e non quello.
Secondo me questo non è il modo di essere costruttivi ma Decostruttivi.
Bene, visto che i toni sono pacati, mi aggrego dicendo la mia.
Secondo me Sub-D è uno strumento potentissimo di modellazione che per quanto riguarda il design dà un’immediatezza espressiva e una libertà impareggiabile.
Finchè c’era T-spline non ho voluto approfondire perché si trattava di un pacchetto esterno e non avevo voglia di acquistarlo ( col senno di poi ho fatto bene visto che è finito ad Autodesk).
Ora le cose cambiano e di certo Sub-D rappresenta un utile incentivo per un futuro upgrade a Rhino 7.
Ovviamente si tratta di integrare nel proprio workflow una modellazione di tipo “poligonale” che implica quindi un cambio di strategia da parte di chi progetta. Questo non mi spaventa.
Quello che però mi colpisce, e sono d’accordo con David, è il mancato miglioramento da parte di McNeel di strumenti quale Patch o l’integrazione mancata di un efficace multiblend, senza contare ancora la miriade di problemini nei raccordi, blend, ecc. che sono la croce e delizia giornaliera d noi tutti utenti. Sub-D non copre questi problemi, e solo con smisurata pazienza e ore e ore passate ad aggirare ostacoli si arriva a risultati soddisfacenti. E’ come voler ampliare la rete stradale lasciando le strade preesistenti piene di buche.
Ormai in anni di esperienza conosco le buche e le evito, a costo di fare dei giri da vertigine, ma chi inizia ad affrontare la modellazione con Rhino impara a bestemmiare in tutte le lingue, e ne conosco parecchi.
Intendiamoci, Rhino per me è impareggiabile e sono un utilizzatore affezionato, ma mi fa rabbia che basterebbe poco per renderlo ancora migliore.
I confronti servono per crescere. Tu non ti confronti mai con altri? I pensieri tuoi non contrastano mai con quelli degli altri? Facciamo così: ce ne stiamo chiusi dentro una sfera e guardiamo solo in una direzione, ti va bene?
Il Decostruttivismo (o Decostruzionismo) non vuol dire “distruggere”, ma scomporre e guardare le cose sotto un’ottica diversa. Nessuno vuole distruggere, anzi!
Non ho mica detto che le SubD siano un lavoro inutile, insignificante o secondario… Secondo me dovreste leggere meglio ed essere più riflessivi, andare un pochetto oltre, e meno coinvolti “per partito preso”!
P.S. Sanpol è una persona intelligente non perché abbia detto “sono d’accordo con Davide…”, ma perché ha compreso il senso del mio discorso, per nulla banale!
Ciao Paolo,
Il lavoro di riempimento delle buche è di pazienza e costanza. Se ci volesse poco saremmo dei masochisti a non farlo. Il problema è che non ci vuole poco. Altrimenti con la SDK a disposizione e tutto quello che il modo informatico offre sarebbe già uscito il plugin RhinoFillet.
SE arriverà ci leveremo il cappello ammettendo i nostri limiti. Nella storia il solo plugin che io abbia visto in questa direzione e che mi ha fatto invidia è stato VR Shape. Ma era il frutto di programmatori che hanno creato le basi della kernel Siemens. Gente oltre la grazia di Dio. Hanno venduto a Adesk, sono andati in “pensione” e ora la sola continuità penso che sia fra la sdraio e la barriera corallina…
…beati loro.
Caro David
sei sicuramente una persona simpatica e un professionista preparato ma sinceramente ti dico che questo tuo atteggiamento verso le subD non ha molto senso, anzi è proprio fuori luogo, invece di apprezzare gli sforzi che mcneel fa per aggiornare rhino e renderlo possibilmente ancora più versatile, tu ti incazzi e fai critiche sensa alcun costrutto, ti prego, per favore, conta fino a dieci, fai un bel sospirone, beviti una birra (ti consiglio una weiss) e fai pace con rhino e mcneel.
con stima
Massimo
Ciao Giuspa
Scusa, ma ho dei dubbi.
Intanto sui plug-in in generale, sul fatto che, dato il basso costo di Rhino, anche i plug-in se non costano poco non li vuole nessuno.
E poi sui fillet.
Ormai fanno parte del folklore di Rhino , ma in realta’ a quanti interessano ?
Io nei forum leggo quasi sempre di G2 (a meno che per fillet si intenda quello)
Sembra anche che ognuno per i fillet voglia una cosa diversa.
In effetti FilletEdge com’e’ adesso non e’ male, anzi a volte fa delle cose che io non oserei nemmeno chiedergli.
Poi altre volte si pianta dove non si capisce quale sia il problema, va beh …
Io non saprei cosa offrire in un plug-in simile.
OK, so cosa vorrei io, ma siamo lontati da quanto, ad esempio, fanno altri cad (o kernel, se preferisci) per i fillet.
Un plug-in in grado di dare le prestazioni di un classico modellatore solido lo vedo molto complicato senza rifare tutto da zero.
Dimmi se sbaglio, ma io da utilizzatore le brep di Rhino le vedo parecchio instabili, imprevedibili, fragili.
Modificarle tramite logiche esterne senza generare qualche maledetto bordo aperto mi sembra un’impresa.
Forse e’ solo una idea mia, il fatto che queste brep non siano molto malleabili, ma allora perche’ i normali comandi Rhino le scassano una volta si’ e una no ?
Intendiamoci, non parlo di belle forme semplici, di superfici regolari e pulite come piace a Rhino.
Con queste anch’io sono capace ad andare spedito con Rhino.
I problemi di solito nascono su cose un po’ piu’ complesse, ma comunque sempre disegnate da Rhino. Oppure su modifiche successive, fatte tramite superfici.
Oppure ancora su certe geometrie importate da altri sistemi.
Ma in fondo non mi sembra neanche logico chiedere a Rhino di fare il SolidWorks.
Chi ha bisogno di quel tipo di fillet quotidianamente non si prende Rhino.
Rhino e’ un’altra cosa, e’ forte a modificare agevolmente curve e superfici, a lavorare superficie per superficie, a modificarle in molti modi diversi, a trovare vie nuove per ottenere forme particolari.
… E qui mi sorge spontanea la domanda …
Perche’ non vengono perfezionati quegli strumenti che lavorano, appunto, sulle geometrie di base, sulla singola superficie, o anche su piu’ superfici, ma senza considerarle un solido ?
Perche’ Rhino si ostina a faticare come un somaro per migliorare un pochino i fillet solidi, invece di rendere agevole il lavoro sui fillet di superficie ?
E il fatto di (non) rendere agevoli le varie operazioni mi sembra anche molto piu’ generale per Rhino, ma per ora limitiamoci ai cari fillet.
A me Rhino da’ un’impressione un po’ schizofrenica a proposito , tipo:
“Vorrei fare i fillet solidi ma non posso”
“Potrei fare i fillet di superficie ma non voglio”
Sembra abbia dimenticato di essere (stato) un ‘Modellatore di superfici per Windows’
e si dia arie da modellatore solido (che non e’) vergognandosi delle vecchie care superfici …
Non so … Probabilmente sono solo io che non ci arrivo, ma e’ un dubbio che ho ormai da anni …
Grazie !
P.S
Poi certo, le SubD sono anche un modo molto elegante per superare tutto cio’
e a me personalmente paiono un’ottima idea (da verificare in pratica, OK).
Per me le SubD cambiano le regole del gioco. Mi rendo conto che la modellazione poligonale richieda un approccio completamente diverso, personalmente mi sono avvicinato e ho approfondito questo tipo di modellazione qualche anno fa con MODO / TSplines e poi con Blender.
Usare le subdivision surfaces (mesh suddivise) consente di creare geometrie che con le NURBS richiederebbero uno sforzo incredibile. Basta pensare a complesse superfici di transizione, fillet/blend a Y e altro. Con le mesh si può semplicemente scolpire i vertici e in tempo reale si ha la geometria risultante. Poter convertire quella mesh in una geometria NURBS vuol dire rendere queste geometrie pienamente utilizzabili per la produzione. Non solo, ma consente di fare in modo semplice quelle operazioni che con le subdivision surfaces sono complicate se non impossibili, come tagli, fori, intersezioni ecc.
A questo aggiungiamo che:
- con il nuovo QuadRemesh si può fare il percorso NURBS->Mesh il che semplifica la creazione di mesh di base usando tutti gli strumenti NURBS
- che le tecniche di modellazione SubD sono ormai consolidate (l’algoritmo originale è del 1978) e che esistono centinaia di corsi e tutorial che possono essere applicati a qualsiasi software di modellazione
- che le mesh sono particolarmente adatte ad essere utilizzate con un approccio parametrico (Grasshopper), sia perché consentono di gestire facilmente forme complesse, sia perché molto efficienti dal punto di vista computazionale (tipo 100 volte più veloci)
- che le SubD creano una geometria con continuità G2 che personalmente per alcune forme organiche ritengo essere anche superiore alle tipiche costruzioni NURBS
Insomma tutti vorremmo avere dei fillet più robusti e miglioramenti negli strumenti di modellazione freeform, però se dovessi scegliere tra questi e le SubD sceglierei le SubD
Un’ultima cosa: ciò che manca (e su cui McNeel sta lavorando) è il set completo di funzioni e comandi di modellazione. Però fino a che questi non sono completati è possibile modificare o creare la mesh in un programma esterno, e volendo senza investimenti aggiuntivi, dato che l’ultima versione di Blender - che è gratuito e open source - è un mezzo miracolo, anzi un miracolo intero, e può essere paragonato per moltissimi aspetti ai software commerciali più conosciuti (in realtà su certe cose è anche meglio…)
Non ho alcun atteggiamento idiosincratico nei confronti delle SubD (sembra quasi che si tratti di persone in carne ed ossa). Ex ante, mi ero posto un interrogativo: se sia più proficuo introdurre, ad un certo punto di un lungo cammino, un tipo di modellazione differente rispetto a quanto proposto da sempre in Rhino, oppure, se sia più giusto risolvere molti aspetti rimasti incompiuti, in una logica di continuità nello sviluppo nurbs (non parlo di piccole aggiunte e aggiustamenti qua e là).
Ho potuto notare, per quel poco che so, che le due modalità di modellazione, così concepite, possano convivere, integrarsi ed aiutarsi a vicenda. Tutto perfetto!
Frattanto: tutti gli altri strumenti cosa
fanno? rimangono in “stand-by”, quasi immutati, in attesa che il nuovo arrivato prenda il sopravvento e faccia apparire Rhino come un nuovo MODO, o una sorta di 3D Studio Max in versione light?
A questo punto domando: <<Posso avere la libertà di giudizio, di critica, di espressione, al di là se possiedo, o no, una licenza, oppure se uso, o no, Rhino per il mio lavoro/diletto, o anche, se non possiedo la conoscenza di principi e metodi di modellazione applicata?
Da semplice conoscitore e disegnatore (senza scomodare le mie due lauree in architettura e in storia dell’arte, che poco contano), posso esprimere un parere, autentico, personale e libero su un software che mi sta a cuore, senza venire tacciato di essere un imbucato “rompipalle”, vis-polemico e, considerato pure da qualcuno, uno psicopatico?
Altrimenti, se si deve parlare di quanto è bello e bravo Rhino, o soltanto di “pallose” problematiche geometriche, fatemelo sapere…
Credo che il tuo pensiero sia più o meno quello di tutti gli utenti di vecchia data (non quelli che si sono avvicinati a rhino per gh).
Nei primi anni abbiamo visto un’evoluzione del programma inteso come cad “classico”, lavorando su strumenti e strategie di modellazione, per poi rallentare (riscrittura del kernel, sviluppo di plug-in, porting verso mac, gh ecc. ecc.) forse anche perché i comandi che c’erano sembravano più che sufficienti…
Ora, con le subd, mi sembra che si stia tornando verso una nuova strategia di modellazione più utile agli utenti “normali” che non hanno bisogno degli automatismi proposti da gh.
Inutile dire che le subd mi potranno tornare utili in alcuni progetti.
Detto questo, concordo sulla necessità di “rinfrescare” qualche comando base aggiungendo le opzioni che mancano (tipo il multi fillet tra più superfici, adesso tocca fare ogni singolo fillet e poi lavorare di taglia-cuci) oppure la possibilità di eliminare o modificare un fillet su polisuperfici (il comando che c’è adesso mi funziona solo se intervengo senza aver apportato altre modifiche alla polisuperficie).
Ciao Lucio
Trovi che GH abbia rallentato il resto dello sviluppo di Rhino ?
Non voglio polemizzare, sono solo curioso …
Hehe … ormai anche noi ragioniamo solo piu’ in termini di risorse dedicate a questo o quello.
McNeel ci ha condizionati … a forza di ripetere che questo non lo fanno o quello lo sospendono per mancanza di tempo e programmatori …
… Neanche fossimo azionisti.
Non direttamente… credo che, inevitabilmente, il supporto abbia dovuto aggiornarsi imparando a programmare con gh e che molti bug siano saltati fuori nell’interazione tra gh e rhino… non credo che i programmatori vivano in compartimenti stagni, più cose ci sono in un programma e più problemi saltano fuori… basti guardare giuspa, deve sapere di modellazione, programmazione, rendering, hardware, plug-ins… adesso anche le sub-d… le giornate sono sempre di 24 ore mi pare…
Essendo poco esperto posso solo riportare la mia limitata esperienza nell’uso di subd - pochi giorni di pratica mi hanno permesso di fare cose e forme che prima potevo solo sognare e che in tanti anni non ero mai riuscito a fare.
trovo SUBD un’arma potentissima e davvero molto apprezzata per quelli che erano i miei obbiettivi, ossia modellare forme organiche in maniera veloce.
Il fatto di poterle convertire ijn nurbs è cosa comodossima , infatti partire da queste nurbs a esegurie altre operazioni , booleane ecc ha fino ad ora avuto sempre esito positiva all’interno di Rhino.
La cosa ancora più incredibile dal mio punto di vista e, secondo me, indice della qualità delle superfici generate, è il fatto che anche usandole al minimo della loro potenzialità e senza pormi troppi problemi sulla qualità della topologica, tutti i test di esportazione in catia mi hanno fatto trovare dei solidi chiusi, senza buchi e pronti da usare per altre operazioni.
Per cui dal mio punto di vista trovo questa aggiunta una novità apprezzatissima , già molto ottimizzata e che mi ha aperto mille nuove possibilità.
Grazie McNeel
Considerazione interessante.
E dato che GH e’ un plug-in che usa RhinoCommon (a quanto ne so), credo che questa interazione abbia favorito anche gli script.
Bene !
Spero che anche le SubD siano a suo tempo esposte da RhinoCommon, in modo da poterle sfruttare via script.
( Credo di si’, se no GH come le utilizza ? )
E pensando a quanto detto da Marco:
E aggiungendo anche il fatto che, come ci dice Ivan:
( Cosa che con i modelli Rhino tradizionali te la sogni. )
… Direi che sia script che GH beneficeranno considerevolmente dalle SubD.
Ribadisco: per me le SubD per Rhino sono una manna dal cielo ( e credo anche dalla testa formidabile di Lear )
Credo che in futuro nell’uso di Rhino converra’ puntare il piu’ possibile sulle SubD, superando in questo modo i problemi che le Brep di Rhino si portano dietro sin dall’inizio (e di cui pare nessuno si preoccupi ).
Evviva le SubD !
… E gli anni di 12 mesi … vero McNeel ?
( Velato riferimento ai tempi di sviluppo delle release … )