Da vedere questa discussione
Non tanto all’inizio, ma dove interviene Bob.
Se son rose fioriranno … vedremo.
Da rhinofilo/utilizzatore spero che la cosa vada in porto e che funzioni. 
Emilio, cortesemente, potresti spiegare in parole povere tutta la questione? Mi toccherebbe tradurre tutto…
Grazie
Emilio cosa ti fa’ pensare che anche se Skyg venisse assunto , poi gli sviluppatori lo ascolterebbero?.
Ormai su certe funzionalita’ ho perso la speranza…
Invece di potenziare la modellazione di superfici , li vedo concentrati sulle subdivision surface che comportano un modo di concepire la modellazione totalmente diverso , e poco utile con chi deve rispettare misure precise.
Ciao Davide
Posso solo dire quel poco che capisco io, per informazioni piu’ affidabili ti conviene chiedere a Giuseppe.
C’e’ una discussione sui fillet in cui interviene Sky Greenawalt. Non conosco questo signore, ma da una sbirciata al Web sembra che sappia il fatto suo, e pare a questo punto che Bob lo conosca e lo stimi.
Sky dice grosso modo che lo sviluppo di Rhino gli sembra poco agganciato a quello che serve agli utilizzatori.
Bob gli offre il lavoro in questione: collegamento tra utilizzatori e team Rhino. Si parleranno
Ripeto: solo la mia personale interpretazione di quanto letto.
Ciao
Ciao Mario.
Hehehehehe … mica per niente ho detto “se”, “vedremo”, …
Mi sembra una novita’ l’atteggiamento di Bob, per quello che capisce chi si limita a leggere il forum.
Prevedo altresi’ malumori nel team sviluppatori.
Siamo scriptomani, Mario, e sappiamo benissimo che e’ molto piu’ divertente scriptare in liberta’ che dover seguire direttive altrui … per cui, eventualmente, agli sviluppatori tutta la mia comprensione.
Ma sono un utilizzatore, quindi comprendo anche chi Rhino lo usa, per cui sarei contento se, in quanche modo, con Sky o qualcun’altro, lo sviluppo di Rhino cambiasse un pochino rotta.
Spero che la saggezza di Bob riesca a trovare un modo per non scontentare nessuno …
In effetti ultimamente mi e’ capitato di pensare
Chissa’ che fine fara’ Rhnio ? Dove intente andare ?
Mi sembra un po’ assediato da nuovi CAD di costo limitato e con migliori prestazioni riguardo al kernel geometrico e magari in facilita’ d’uso…anche se forse inferiori su altri fronti.
Forse diventera’ una cosa diversa.
Sulle subdivision surfaces, da quello che sbircio in Serengeti, l’idea dovrebbe essere di integrarle con le nurbs, e ti confesso che, come ulteriore strumento di modellazione, mi piacerebbe poterle provare.
Certo, vedendo questi progetti avanzati, tipo UDT e subsurf, viene da pensare perche’ prima di queste cose, pur importanti, non cerchino di sistemare meglio le operazioni di base, e non solo sui solidi, ma anche per le superfici e pure l’interfaccia dei comandi.
Poi, va beh, ovviamente ognuno vede Rhino dal suo punto di vista e nota i problemi relativi.
Non sono un industrial designer e non so cosa serve in quel campo, notoriamente il riferimento per Rhino.
Forse li’ i fillet non sono cosi’ critici e magari c’e’ abbastanza tempo per poter smanettare il dovuto con i comandi Rhino standard.
Forse siamo noi che vorremmo snaturare Rhino, mah. 
Ciao !
Ok, ho inteso meglio. Grazie.
Comprendo che la annosa questione dei fillet in Rhino sia il centro della discussione. Da versione a versione se ne parla; miglioramenti sì, ma nulla di eccezionale su tale fronte! (non so come si comporta finora Rhino 6).
C’è chi sostiene che Rhino non posso mai gestire dei fillet alla stregua dei modellatori solidi, per ovvie ragioni (facciamocene una ragione!); chi pensa sia un problema di programmazione, magari legato ad un indirizzamento delle potenzialità di sviluppo un po’ “debole” in tal fronte; chi pensa che lo sviluppo si concentri volutamente su altri fronti, lasciando lacune sparse a macchia d’olio, tra cui, appunto, anche i fillet… Non saprei…
Di fatto, leggo spesso lamentele, le solite: i fillet non funzionano bene, anche in situazioni apparentemente semplici; il comando patch è vetusto; match srf lavora così così… ecc.
Bisogna dare atto a tanti meriti, tra i tanti, quello del duro e alacre lavoro di sviluppo, nonché, dell’ascolto diretto e continuo con l’utilizzatore da parte degli sviluppatori/curatori del software; ma di contro, bisogna anche riconoscerne i limiti e le carenze che si trascinano da versione in versione.
Secondo me, la differenza non la svolge tanto l’aver implementato una opzione in più all’interno di un comando, o l’aver introdotto un render maggiormente convincente o le sub surfaces (per carità, anche utili), bensì il fornire all’utente dei comandi (anche pochi) rivolti alla generazione ed editing di superfici davvero robusti e completi, che altri software farebbero fatica a generare con facilità ed immediatezza (sempre nella logica di Rhino). In soldoni: cosa fa Rhino di eccezionale rispetto ad altri programmi analoghi? In cosa si distingue davvero? Ormai ogni genere di CAD fa un po’ di tutto, si pensi, per esempio, ad Archicad (software BIM), il quale si sta cimentando, a suo modo, nella generazione di forme complesse, e non solo.
Ti do una buona notizia Mario: sbagli!!! Il contrario esatto.
Le SubD come le stiamo sviluppando funzionano e vengono calcolate con una tolleranza paragonabile a quella di modellazione. Altrimenti non ci avremmo messo nemmeno mano. Del tipo che potrai fare un match fra NURBS e SubD. Saranno completamente gestite dall’ SDK.
Insieme al progetto MESH (in generale) significa poter passare da NURBS a MESH una buona volta.
I fillet fanno arrabbiare tutti (sono fra quelli) ma francamente me ne frego abbastanza rispetto alla possibilità di gestire meglio - e come dovrebbe - molte altre cose che sono “core” della modellazione NURBS.
Se Skyg farà il miracolo…vedremo. Intanto deve chiarirsi le idee su chi risponde nei forum… (vedi post inglese)… very confused…
Scusa Giuspa, se capisco bene, dici che Rhino deve fare la modellazione free-form e quella la fa bene.
Il resto sono comandi ausiliari, di uso saltuario che servono solo di supporto alla modellazione vera e propria.
Giusto ?
Ciao Giuseppe
Ho letto il documento di Mcnell in cui si spiega a grandi linee cosa dovranno essere le SubD di Rhino, e non mi sembra che siano cosi lontane dal concetto applicato in T-spline.
Personalmente ho provato ad usare T-spline in modo continuativo nei 30 giorni della Trial, ho eseguito tutti i loro tutorial per impratichirmi nell’ uso delle SubD.
Ottimo strumento per chi non ha dei vincoli sulla forma dell’ oggetto che sta creando, meno buono per chi deve rispettare delle misure ben precise ( ad esempio le zone soggette a vincoli radiali della visiera di un casco ).
Ecco perche’ non sono cosi entusiasta sull’ introduzione delle SubD.
Mi si puo’ dire …usa le subD dove e’ utile usarle e negli altri casi usa i soliti strumenti di modellazione di Rhino.
Ovvio che alla fine faro’ cosi ma… mi rode che niente si faccia sul fronte delle nurbs nude e crude, e non alludo ai fillets 
Non esattamente: dico che ci sono degli aspetti fondamentali nella gestione delle NURBS che possono essere molto migliorati. Questo avverrebbe in un ambito che è in linea con lo scopo del programma. Prima ancora che nei fillets di cui discutiamo spesso.
Fare meglio quello che chiede mario per capirci.
Come dicevo nel post precedente l’approccio non è quello di fare un clone di T-Splines. Piuttosto di integrare una classe di geometrie che dialoghino in tutto e per tutto con le NURBS. Vincoli formali in primis.
Esattamente per risolvere il problema come lo hai indicato. Altrimenti i prodotti ci sono già. Quello che non credo sia spiegato è come sono state implementate le SubD da un punto di vista matematico rispetto alla approssimazione ora esistente con altre SubD (T-Splines sono una classe a parte di geometrie).
Credimi, non saranno un “ripiego”.
Tu che sei di “vecchia data”…ti ricordi quando introducemmo il progetto “gazelle” per la network?
Forse dirò una cavolata: ma si tratta di implementare le N-gon? (tipo quelle di Moi3d) o si parla di tutt’altra roba?
Scusate se mi intrometto…
Le N-gon sono già in Rhino 6.
Una N-gon è una topologia che semplifica una serie di facce mesh complanari (unite e saldate) in una unica “faccia” o elemento.
Confermo: si parla di tutt’altra roba.
Ad esempio mantenere la continuita’ ? Migliorare la facilita’ di costruzione/editing ?
O magari ricavare una superficie da una poly, o superfici non trimmate da trimmate ?
… Non so … sparo un po’ a casaccio, scusa se dico castronerie. 
Quello che cerco di capire e’ l’effetto di queste migliorie.
Serviranno ad un maggior controllo e una migliore qualita’ delle forme libere ?
A gestire piu’ facilmente la complessita’ delle superfici ottenute (di ogni tipo) ?
A migliorare le operazioni base in casi critici (offset, raccordo, taglio ecc.) ?
Interventi solo sulla forma delle superfici (non trimmate) o anche sui bordi delle trimmate …e quindi solidi ecc. ?
O altro ?
I fillet … eh … non mi senti di biasimare chi chiede i fillet. Sono una bella comodita’ in molti casi.
Ormai sono di uso generalizzato e, data la facilita’ con cui si imbastisce un solido attualmente, se poi ci si pianta sui fillet, si nota subito …
E secondo me si nota molto anche perche’ la riparazione e’ spesso piu’ lunga e complessa di quanto potrebbe essere.
Nel caso postato da Jørgen forse basta ritrimmare tra di loro alcune coppie di superfici. Questo si potrebbe fare con 2 semplici click, invece adesso devi esplodere o estrarre, ‘untrimmare’, sperare che l’oroscopo dell’intersezione sia favorevole ed eventualmente fare un po’ di woodoo, trimmare una per volta e riunire il solido … permettimi … “che pizza !”.
Scusa, ho divagato, quando leggo ‘fillet’ mi si rizzano i peli a mo’ di Mr. Hyde …
Grazie per le spiegazioni gia’ date e per quelle future … sei proprio un bravo ‘developer’ … Hahahahaha
Ciao !
Ciao a tutti, mi inserisco nel dibattito anch’io 
Utilizzo rhino fin dai tempi della 0 beta (metá anni novanta…) e sono legatissimo agli sviluppi ed al futuro di rhino specie ora che con la versione cinque a mio parere per molti versi si è rientrati “in carreggiata”, la versione 3 e 4 sempre a mio avviso sono state involuzioni pesanti tanto da farmi usare costantemente la versione 2 fino all’uscita della 5 appunto.
Mi associo a chi chiede migliorie sui fillet ma non in modo prioritario, anche se ci si deve impratichire rhino ti permette di aggirare i vari ostacoli sempre.
Diverso invece il discorso di generazione ed editing delle superfici dove davvero rhino dovrebbe aggiornarsi! Sarebbe bello poter controllare e vincolare tutti e quattro i bordi di una superficie sia da generare che editare per quanto riguarda continuitá o curvatura con superfici di confine (vd alias surfaces), altrettanto interessante sarebbe implementare funzioni tipo le Tspline all’interno di rhino che dialoghino con le nurbs, poter editare superfici o polisuperfici intervenendo con comandi che “muovano” aree interne per generare nervature di stile in modo semplice e interattivo sarebbe fantastico! Vero che certi comandi non sono idonei quando si deve sottostare a vincoli precisi dimensionali ma sono perfetti per tutte le parti/fasi di modellazzione libere da esse.
Scusate la digressione ma quando penso a come potrebbe migliorare il nostro grande rhino mi perdo…
Ciao
Continua la discussione sui fillet di Rhino…
Devo constatare che ogniqualvolta si parla di “fillet”, molti utilizzatori sostengono la non priorità di tali strumenti, ma al contempo, si accendono discussioni e lunghi dibattiti, e non mancano i soliti paragoni con altri software simili, evidenziando, anche attraverso esempi, le carenze ancora presenti in Rhino, alcune molto banali e inattese!
Le operazioni di “fillet”, chissà perché, non servono quasi mai a nessuno (o a pochi): “io non li uso quasi mai”, “per me non sono fondamentali”, “Io aggiro i problemi dei raccordi seguendo altre strade”, “io per forza di cose eseguo i fillet con altri programmi, esporto, poi rientro in Rhino” (come se fosse facile, una booleana con UGS NX, un fillet con Catia, poi si rientra in Rhino, poi dimenticavo, ancora un blend con TurboCad, qualche quotatura con AutoCad: da pazzi! Certo, tutti vorremmo il classico “coltellino svizzero”)… ma alla fine gli stessi sollevano grandi polveroni, e sotto sotto, vorrebbero che funzionassero alla pari di un modellatore solido.
Non so come si comporterà in tal senso Rhino 6, sicuramente meglio, ma staremo a vedere: anche nella nuova versione non mancheranno le solite discussioni (e non parlo di dover eseguire chissà quali mirabolanti raccordi, ma di far funzionare un piccolo raccordo tra due superfici!).
Beh, dall’alto ( ) della mia lunga esperienza di raccordatore … non direi che il problema sia il raccordo tra superfici in se’.
Di solito le superfici di raccordo Rhino le trova senza problemi.
Piu’ che altro mi sembra che Rhino a volte fatichi a trovare il punto esatto in cui deve terminare una superficie di fillet e iniziare quella seguente ( che raccorda una diversa coppia di superfici ), sia che si tratti di troncare con isocurva, sia che si tratti di intersezione tra le superfici di fillet.
Evidentemente la cosa e’ piu’ complicata di quanto sembri.
Per curiosita’ ho provato a unire le superfici incriminate con un bel merge, il fillet funziona !
… E Rhino separa nuovamente le superfici … ma certo in generale non e’ una procedura comoda … ammesso che sia possibile applicarla …
Verissimo David, ma per come è nato rhino e per quelle che sono state le sue caratteristiche vincenti fin da quando ha mosso i suoi primi passi (semplicità di utilizzo e velocità di modellazione per progettisti) io ribadisco che preferirei fosse implementato qualche controllo di creazione ed editing delle superfici, ovvio che sistemare delle lacune esistenti farebbe tutti felici (è come dire io sono contro la guerra, non so se mi spiego…) ma andare ad avvicinarsi a modellatori solidi orientati al cad-cam credo sia quasi una follia pensarlo (poi tanto di cappello se ciò avvenisse ma non ci spero).
Nessuno vuole che Rhino diventi altro da sé! Nessuno chiede che Rhino debba eseguire fillet alla Catia, o faccia render alla Cinema4D, o messa in tavola alla AutoCad. Per la logica di Rhino, credo che vere priorità siano, come dici tu, illo76, la generazione ed editing di superfici (almeno queste che avvengano allo stato dell’arte); per il resto ci si potrebbe pure accontentare!
Se poi arriva un programmino Cad free, sviluppato una manciata di anni fa, o uno che costa un quinto di Rhino, o anche meno, che mi esegue superfici sweep, blend, ecc. di buona qualità (uguali o anche meglio di quelle fatte con Rhino), accompagnate da una discreta possibilità di modifica, allora è logico che girino le balle un po’ a molti! o no?
Un fillet non eseguito, o eseguito maluccio, si può pure comprendere, anche una booleana se vogliamo, o uno shelling; ma se la qualità di un blend, per esempio, lascia a desiderare e la superficie ha poche e non sempre eccellenti possibilità di modifica allora sarebbe un altro paio di maniche! (In effetti, mi domando, che motivo ci sarebbe stato nel realizzare un plug-in come VSR shape modeling, se Rhino fosse stato così perfetto in tal senso?).
dici bene!
magari rhino 6 integrasse queste funzioni! speriamo in bene perchè queste si sarebbero MOLTO aprezzate.