Comunque, meno release rilascia la McNeel e meno soldi prende…
Sotto un certo punto di vista pagare un unico aggiornamento che ne contiene 3 - 4 è economicamente più vantaggioso per l’utente (lo svantaggio sta nell’attesa).
cioè creare strumenti che permettano parallelamente lo sviluppo indipendente da piattaforma. Se si strumenti saranno come devono essere (leggi fra le righe quanto infinitamente meno del previsto ha impiegato GH a spuntare in Mac) vedrai che qualcuno che si propone per Rhinux salta fuori. Calcola che è successo per Mac senza che noi facessimo niente.
Ma alla fine poi nemmeno quello perchè l’utente usa da sempre la beta se vuole strumenti nuovi.
Diciamo che far passare tutto quel tempo, oltre a essere un problema economico, come ha sottolineato giustamente, non sta bene…
Paradossalmente, non chiedere soldi fino a quando si abbia la ragionevolezza che lo spettacolo vale il biglietto… non è percepito dal mercato. E’ un “errore”. Certo se fossimo stati quotati in borsa una roba del genere non si sarebbe mai vista.
Infatti…
Per alcuni utenti non serve vedere in cosa consiste l’aggiornamento… basta dire di aver l’ultima versione e sei più figo…
Un pò come quelli che davanti un preventivo ti chiedono sempre lo sconto, a prescindere, senza considerare il prezzo:
- se sei stato basso e non puoi fare sconti ci rimangono male
- se sei stato alto e gli fai il 30% di sconto allora sono contenti… anche se magari pagano di più del primo caso…
Io personalmente però rientro in quelli che se una nuova sr non mi convince per novità mantengo la versione precedente e aspetto anche la successiva sr…
Thanks !
Mah … una beta fresca fresca non ha la stabilita’ di una release ufficiale.
E se io preferisco aspettare 5 anni per avere piu’ migliorie allo stesso prezzo, basta che salto un aggiornamento.
Mentre chi vuole puo’ pagare due aggiornamenti ma avere un programma stabile con alcune migliorie in meta’ tempo.
Senza intenzione di criticare McNeel certo.
Forse rilasciare una release ha un costo non trascurabile, e McNeel fa bene a risparmiare le forze per concentrarle sullo sviluppo.
Oppure no, questo non c’entra niente, non lo so …
Vedremo … 
Giuseppe, sò de coccio …
Quindi il sub-d non serve per l’ediit locale delle surface …
Il passaggio a destra -> mesh - quad mesh - nurbs
ha una logica ma quello a sinistra non ha senso!
Probabilmente non sono così navigato. Cosa cambia da 1 a 5?
L’aver ricavato un’unica nurbs?
rispondo subito: non è unica nurbs.
Ciao Sergì.
Mi serviva solo a dimostrare un flusso di lavoro che parte da una NURBS e fa il viaggio completo fino a una SubD passando da mesh e con poca perdita di dettaglio. Diciamo che chi fa reverse un certo tipo di attenzione per questo processo confido che la abbia. A oggi resta un bagno di sangue anche con T-Spline e VRShape.
Secondo me, l’aspetto poco convincente della conversione da T-Splines alle Nurbs di Rhino, è quello di generare troppe superfici singole, cioè una forma composta da tante superfici spezzettate, poco gestibile poi con gli strumenti nurbs di Rhino.
Se le subD riusciranno a risolvere anche questo problema, allora sì che rappresenteranno davvero una novità, per cui vale la pena attendere un po’ di tempo per vederle integrate come si deve all’interno di Rhino.
Estratto da questo post http://discourse.mcneel.com/t/rhino-wip-subdivision-surface-project/16562
> Rhino subdivision objects will be automatically converted to cubic NURBS polysurfaces or meshes when a subdivision object is selected as input to a command that is expecting a polysurface or mesh. The customer experience we want is that if a command expects a surface and something looks like a surface, then the object works in the command. (This is the way extrusion objects behave in Rhino 5)
Quindi sara’ (forse) possibile fare il _join tra superfici e Sub-d
Aggiungo una mia perplessità, dato che il titolo di questa discussione si chiama, appunto, “perplessità”.
Domando: “Come mai dopo tante versioni, non hanno mai voluto implementare certe caratteristiche, a mio avviso utili e quasi fondamentali?”. Mi riferisco al “multiblend” (come quello del plug-in Autodesk shape modeling), il quale sarebbe stato utilissimo in tante situazioni, oltretutto, evitando di utilizzare il comando “patch” , strumento dalla dubbia qualità (anche se un po’ migliorato rispetto al passato).
Altre caratteristiche utili e da sempre molto richieste: raccordi di tipo “setback” (da aggiungere ai fillet già presenti; Alias li ha implementati già da un po’ di tempo) e “chamfer edge” con angoli diversi da 45°; lo so, forse più difficili da gestire per un modellatore non parametrico come Rhino.
Ok, hanno introdotto dopo tante versioni lo strumento “shell” (una grande novità, molto utile davvero, questo sì)…
Ecco che la vera novità saranno le subD, che per forza di cose, limiteranno lo sviluppo di molti comandi (tra cui quelli da me sopra elencati), almeno credo.
Pertanto, cosa ne pensate? Siete d’accordo col fatto di sviluppare le subD dando a queste una forte priorità?
Beh, è una mia osservazione, nessuna critica o condanna… alla fine si tratta di fare delle scelte, di seguire certe strategie o richieste da più fronti…
Beh, le SubD le vedo molto favorevolmente.
Ne avevamo anche discusso io e Giorgio Gurioli neanche tantissimo tempo fa, non ricordo se qui o su MXP …
L’integrazione Nurbs-SubD ci sembrava un’utopia da lontano futuro, invece … sono quasi qui. 
L’impressione continua ad essere quella che abbiano una cronica scarsita’ di risorse ( ore programmatore ) e che quindi debbano scegliere di volta in volta su cosa lavorare e cosa invece trascurare.
In una discussione che hai aperto sul forum USA, Pascal fa riferimento a due wish inseriti nel bug tracker (riguardo a splittare la parte nuova quando si estende una superficie o una curva), dai un’occhiata alla data di uo dei due wish: 2004
Mi ricordo che per le curve una volta questa possibilita’ c’era (molto comoda), poi, credo con Rhino 3, e’ scomparsa. Allora ne avevo parlato anche con Giuseppe, che era d’accordo nel chiederne il ripristino … forse e’ quello il wish che dorme dal 2004.
A me sembra chiaro che McNeel non riesca a rifinire i comandi che appaiono in Rhino con le varie release.
Si passa subito a lavorare su altre cose (come le SubD ad esempio)
Sono rari i casi in cui siano ritornati su vecchi comandi per migliorarli.
Sembra che questo accada solo in casi di ‘furoro di popolo’ … ;), cioe’ di richieste numerose e ripetute.
Vedi le toolbar per Rhino 5, e vedi Make2D per Rhino 6.
Per Rhino 6 c’e’ anche la modifica del raggio di fillet, in certe condizioni. Credo dovuta alle numerose richieste sul parametrico.
Credo che questa situazione sia un punto di equilibrio trovato da Bob tra costo e utilita’ del programma.
Potrebbero raddoppiare o triplicare il costo e dare a Rhino un’aspetto piu’ … civilizzato 
Ma forse gli utilizzatori non lo comprerebbero.
Tieni anche conto del fatto che Rhino fa molte cose abbastanza bene. Non fa una sola cosa benissimo.
Stesso discorso: forse gli utilizzatori preferiscono cosi’ ( io di sicuro ).
Per ora teniamoci il solito Rhino che riesce a fare quasi tutto, ma mettendoci un certo tempo e parecchia inventiva da parte nostra … e una buona dose di pazienza naturalmente. 
Certo sulla scelta di cosa sviluppare e cosa no ognuna avra’ la sua personale opinione e quindi non sara’ contento al 100 %.
Ad esempio a me vengono sempre in mente i Rhino Polyhedra … mentre il multiblend aspetta …
( Non so cosa siano i fillet setback, sorry )
Grazie
P.S.
Suppongo di dover chiedere scusa per aver la mia invadenza:
Big Brother Discourse mi avvisa che non lascio tempo agli altri per le risposte.
Comprendo tutta la faccenda.
Ma, stranamente, rimango ancora più perplesso per il fatto che, nelle varie versioni di Rhino, non si riescano a definire dei punti fermi. Da versione in versione cambiano alcune caratteristiche, appunto, come fai notare tu, prima esistevano, poi scompaiono, e forse, ritornano. Tutto questo esprime un senso di aleatorietà che non fa bene ad alcun programma, specie in ambito CAD, in cui le aspettative di funzionamento sono molto alte.
Io in un’altra discussione ho espresso il mio punto di vista, e lo ribadisco: secondo me, una software house di un certo valore e di fama mondiale (Mcneel), seppur non ai livelli della Autodesk, non si può permettere di sviluppare i propri prodotti attraverso il lavoro di una trentina di programmatori, troppo pochi! (scusate l’ossimoro).
Mi meraviglio un poco, in quanto se ci trovassimo in Italia sarebbero pure tanti (la cultura italiana è quella dei tagli, di ridurre tutto ai minimi termini), ma parliamo degli USA…
…Il signore si che se ne intende…
Giusto per dare un confronto http://blogs.msdn.com/b/e7/archive/2008/08/18/windows_5f00_7_5f00_team.aspx
per fare un os come windows 7 hanno lavorato in circa 1000 persone (28 gruppi per una media di 40 persone per gruppo)
30 sviluppatori per rhino mi sembra un buon numero quindi.
Intanto è un confronto non molto equilibrato: parliamo di un sistema operativo (qualcosa di molto complesso e articolato) e di un CAD. Avrei preferito che si facesse un raffronto tra sistemi di pari entità e categoria, tipo “Altair Company” vs “McNeel”, per esempio (non parliamo della Autodesk, della Dassault Systemes o della Siemens, nemmeno a nominarle!)
In ogni caso, pur non essendo niente e nessuno per poter stabilire certe questioni interne, ribadisco che qualche manciata di sviluppatori in più darebbe più vigore, quindi, nuova linfa al team McNeel, se non altro ne guadagnerebbero i tempi di sviluppo (modesto parere).
ma che davero? 
daje! 
Si’, in effetti non hai mica torto …
Mi sa che ci avete abituato troppo bene.
… Anche se non sono convinto che la V6 sia cosi’ scarsa di miglioramenti, ma non avendola provata e’ solo un’impressione …
Ciao !