Salve a tutti. Vorrei parlare di questo argomento perchè dopo anni di attesa della nuova versione del rinoceronte sono abbastanza deluso per la compatibilità dei plug in. Non voglio essere polemico amo questo programma (lo utilizzo tutti i giorni ormai da 8 anni) però non riesco proprio a capire perchè hanno fatto questa scelta.Non sò se centra il fatto che hanno riscritto il codice del programma per inserire le “sub division” (che su rhino6 non sono ufficiali) o altro, stà di fatto che nel mio upgrade a rhino 6 mi sono ritrovato con un software vuoto senza i miei amati plug in che utilizzo tutti i giorni. Mi ricordo come pubblicizzavano le vecchie versioni di rhino sbandierando il fatto che il programma si poteva personalizzare con una marea di plug in esterni. Infatti per rhino5 ne sono stati sviluppati molti di più o meno utili e funzionanti. Poi negli anni molti sono stati abbandonati ,forse perchè non apprezzati dagli utenti o non redditizi per le software house produttrici,ed ecco che non troveremo mai una versione aggiornata per rhino6 ;ad esclusione dei piu’ importanti (rhino gold / bongo2 / Brazil ecc). Nel sito di rhino si può scaricare un file “cpp-migrator” per convertire i vecchi plug in… ma la cosa non è cosi’ semplice. Bisogna installare Visual Studio le librerie di rhino usare il CMD di windows ecc… sinceramente roba da smanettoni non alla mia portata… e ho letto che non sempre la procedure và a buon fine. In definitiva per ora continuerò ad utilizzare il buon vecchio rhino 5 che nel complesso può ancora soddisfare le mie esigenze rinunciando alle(poche) migliorie di rhino 6.
Secondo voi sarà possibile in futuro riabilitare tramite service release la compatibilità ?
Ci sono altri modi per migrare i plug in vecchi?
Cosa ne pensate?
Ciao Sandro
Purtroppo non ho suggerimenti su come poter utilizzare i ‘vecchi’ plug-in … mi spiace.
Posso solo dirti che a me sembra inevitabile che di tanto in tanto si perda la compatibilita’ con i plug-in.
Gia’ Rhino 5, a quel che so io, aveva mantenuto la compatibilita’ con Rhino 4.
Per forza di cose, se il software deve evolversi, capita di perdere la possibilita’ di usare i vecchi plug-in.
( Non so se anche aziende molto piu’ grandi di McNeel siano in grado di mantenere tale compatibilita’ … poi credo che non varrebbe la pena comunque … )
Purtroppo i plug-in sono un’arma a doppio taglio.
Fanno vendere piu’ licenze perche’ permettono un uso piu’ esteso del software …
Ma rischiano di causare grosse difficolta’ agli utilizzatori quando spariscono o non si adeguano alle nuove versioni … ( o vengono comprati, ad esempio, da Autodesk … 
)
E’ il rischio calcolato che ogni utilizzatore corre se decide di affidarsi a un plug-in esterno.
Io infatti, vedendo che il plug-in per il taglio laser non si metteva in pari con le versioni di rhino, ho optato per farmi il programma internamente… scelta faticosa ma che mi ha permesso di passare facilmente da una versione all’altra… e anche con la v6 mi pare girare tutto senza problemi.
Confermo comunque che ho anch’io la sensazione che i plug-ins abbiano rallentato rispetto all’inizio… ma forse mi sbaglio…
Sono pienamente d’accordo Emilio con l evoluzione del programma ecc…
Non sò a livello software quanto può essere complesso aggiungere la compatibilità dei plug in però mi sembra una cosa abbastanza importante. Non tutti siamo in grado di fare come Lucio_Zadra che si crea il suo programma 
Quello che ho notato è che in generale le nuove versioni dei software tendono a dare priorità a una serie di cose che alla fine possono andare in contrasto con le vecchie che funzionavano bene. Io immagino la nuova versione come la vecchia con in più delle novità non un programma nuovo dove si perdono “pezzi” del vecchio a favore di una grafica migliore e poco altro. (parlo in generale,rhino a parte i plug-in è abbastanza coerente in questo)
Se qualcuno utilizza i programmi autodesk powermill o powerhape (ex delcam) sa di cosa parlo e sarete indignati e rassegnati ad utilizzare un software totalmente nuovo e incoerente con il vecchio… altro che upgrade… (autodesk fa il buono e il cattivo tempo) Tornando a rhino alla fine per usare il 6 sarò costretto a fare qualche script per ovviare ad alcune funzioni dei plug in quindi spero che qualcuno mi aiuti nella sezione
script e programmazione ( Lucio tieniti pronto 
)
Concordo.
A volte riesci a trovare il modo di usare un comando in modo molto utile …
E poi te lo vedi stravolgere perche’ a qualcuno serve che funzioni diversamente.
E’ una cosa che non capisco.
( Non so se hai visto sul forum USA, avevano deciso di abbandonare BackgroundBitmap perche’ hanno migliorato Picture … alcuni si sono inca**ati di brutto (giustamente) cosi’ pare che manterranno anche in ‘vecchio’ comando. )
Se a qualcuno serve che un comando lavori in un certo modo, bene, aggiungi un’opzione o al limite aggiungi un altro comando … SENZA incasinare la vita al prossimo togliendogli uno strumento che gli serve.
Quanto alla 6 … non ho avuto modo di esplorare le novita’ … ma di solito con Rhino la cosa richiede almeno un investigatore privato …
Ma credo che le migliorie ci siano e siano parecchie … solo, come ho detto … molte non so dove siano 
Per gli script, sono sicuro che qui troverai l’aiuto che ti serve. 
… Certo, c’e’ plug-in e plug-in … per alcuni … hai voglia a scriptare .
Ciao Lucio
Non mi e’ mai piaciuta ‘sta solfa sui plug-in da parte di RMA …
E’ chiaro che i plug-in vanno e vengono quando gli pare … e con il prezzo di Rhino non e’ facile trovare gente che spende per un plug-in piu’ di quanto ha pagato Rhino …
Se non sbaglio, si diceva che RMA non sviluppa certi argomenti per non interferire con un plug-in …
Bella pensata … mi fa piacere che si preoccupino piu’ dei plug-in esterni che degli utilizzatori di Rhino …
Cosi’ poi i plug-in spariscono … e spariscono anche gli utilzzatori che ne avevano bisogno …
Per me sarebbe meglio lasciare ai plug-in le funzionalita’ piu’ avanzate ma prevedere comunque dei comandi ‘di base’ che permettano alla gente di arrangiarsi alla buona in caso di bisogno.
Poi se si vogliono prestazioni elevate, OK, ci si compra un bel plug-in con tutti i costi e i rischi del caso … se il plug-in c’e’ ancora …
E in fondo e’ quello che RMA fa gia’ per i render, se non erro, quindi lascerei perdere la ‘propaganda’ sui plug-in ‘salvifici’ … che lascia il tempo che trova …
I plug-in sono utilissimi, si’, ma quelli che le aziende si fanno internamente per loro uso e consumo.
Quelli si’ convinvono la gente a prendersi Rhino …
Ringrazia lo spostamento del target McNeel verso gli architetti… da li sono nate tutte le rogne.
Quando si doveva discutere con gente che faceva auto, barche, stampi, strutture in generale non c’erano problemi, ma quando hanno introdotto il paneling ed il freeform per gli edifici… sono partiti con tutte le richieste tipiche di chi arriva da programmi che non centrano niente con Rhino, con dei workflow osceni, e, piuttosto di adattarsi a Rhino, hanno chiesto che quest’ultimo assomigliasse di più al loro.
Come dare torto agli sviluppatori che devono investire su progetti legati a Rhino…
… stampiiiii … ?
Hai detto “stampi” ?
… Ma quando mai ? … Va va … solo dopo (tanto) prosecco senti RMA parlare di stampi …
PRRRRRRRR 
Dai che ti ho fatto ridere di Lunedì! 
Il problema è proprio questo che purtroppo hanno deciso di puntare a cose in cui Rhino può dire la sua ( architettura, paneling grasshopper ecc…) congelando tutto il resto. Perché diciamoci la verità rhino è un software che ha una marea di comandi per svariati settori che promette di fare un po’ di tutto ma che in realtà non è specializzato in niente. Non è per la meccanica ma è precisissimo… è facile da utilizzare… per le cose semplici!! per cose “serie” sappiamo quanto manico serve!!! Ha più di 1000 comandi che se usati con esperienza possono portare a buoni risultati come un artigiano che lavora nel garage di casa! E per certi aspetti insieme al costo sono proprio questi i suoi vantaggi. Il problema è che gli altri software cad parametrici negli anni si sono evoluti al tal punto da sorpassare i loro limiti introducendo ambienti per la modellazione delle superfici (anche organiche) colmando il gap con i modellatori diretti. Rhino è rimasto a guardare e ora è normale che chi deve fare auto, barche, stampi ecc… scelga direttamente altri software : autodesk, cimatron, Solid edge, creo parametric, Solidworks, Catia ecc… Lo farei anche io ma per il mio lavoro rhino è ancora valido … anche se sinceramente pensare che con le poche novità di rhino 6 devo resistere per altri 5/6 anni… 
mi prende lo sconforto per il futuro 
giusto per info:
tempo fa nel forum si è parlato della programmazione di VBS e PY in Rhino
con la differenza che quet’ultimo avesse la possibilità di poter creare PlugIn
quindi da quello che ho capito questi cambiamenti della versione sei
escludono anche questa possibiltà di creare/si dei PlugIn personali?
Se parli del compilatore per gli script, non credo.
Steve nel forum ha ribadito recentemente che il compilatore di script funziona sia per Rhino 5 che per Rhino 6.
… Ma non posso dire di piu’, non lo ho mai usato …
Concordo … anche se ci sono ‘nicchie ecologiche’ per cosi’ dire, in cui gente in gamba riesce a usare Rhino anche per cose del genere, vedi il nostro amico Lucio.
Certo servono, direi, condizioni particolari, ma in fondo ogni tipo di lavoro e’ particolare, per cui a volte si riesce, con impegno e capacita’, ad utilizzarlo anche in ambiti … snobbati da Seattle …
E, a quanto dici, pare sia anche il tuo caso, almeno per ora …
Poi, dire che e’ stato a guardare non vuol dire che lo sviluppo non sia proseguito, ovviamente.
Solo che la direzione presa … porta da un’altra parte.
Dciamo verso ambiti in cui l’estetica e’ fondamentale, architettura compresa.
… E in cui l’uso del CAD puo’ anche richiedere un po’ di tempo … ( anche se su questo mi pare che non tutti gli utilizzatori siano d’accordo )
Io direi anche che l’architectural shift … ( vi piace la definizione ? ) e’ nato con GH.
Da come la vedo io, GH ha salvato Rhino, dandogli … uno scopo nella vita … nonche’ creando un ambiente amichevole e dinamico, accattivante e orientato alla sperimentazione, in cui ogni smanettone si trova a proprio agio.
Da cui la miriade di Add-on che continuano a comparire e il fatto che spesso GH sia scelto come ambiente di sviluppo anche per progetti che con l’architettura non c’entrano un fico secco.
GH mi sembra il vero “Rhino 2.0” , cioe’ non la stessa minestra scaldata e riscaldata, ma un concetto originale e stimolante. Proprio come era Rhino alle origini.
Certo, GH lo devi programmare, non puoi usarlo in modo interattivo, quindi cosi’ com’e’ non puo’ sostituire Rhino. Ma se in qualche modo integrassero i due ambienti …
( Magari facendo anche una bella cura ricostituente al kernel geometrico … )
P.S.
Grazie per aver accennato a Cimatron … mi hai fatto ricordare quando lo usavo 25 anni fa (su una macchina con hard disk da 400 mega ) …
Bel post, concordo sulla rinascita di Rhino legata a GrassHopper.
Non sono per niente d’accordo che non è per la meccanica. Io l’ho utilizzato dalla versione 1 proprio nel settore della meccanica in quanto insegnavo nell’istituto tecnico di Bassano del Grappa ai periti meccanici che hanno fatto lavori notevoli. Dalla mia scuola si è diffuso nel territorio a raggiera proprio nel settore della meccanica . Chi sa usare bene Rhino lo può impiegare in qualsiasi settore con ottimi risultati.
Vittorio
Prendo atto del discorso e delle considerazioni.
Un punto:
- Mi sfugge il motivo per il quale il problema dovrebbe essere risolto da questo lato e non dagli sviluppatori dei plugin…stante che hanno in mano la SDK di Rhino 6.
Io continuo a non capire la scelta di McNeel di agevolare gli architetti e non i “meccanici”.
Rhino non solo è molto adatto e preciso per lavori anche di micromeccanica di precisione ma è anche una piattaforma di disegno molto rapida.
Ed è talmente adatto alla meccanica che abbiamo scritto un PLM di prodotto appoggiato a Rhino proprio per avere una piattaforma di produzione completa, efficiente e facile da usare.
Io credo che se McNeel lo promuovesse tra i Cad meccanici farebbe un bel salto di qualità.
Per quanto riguarda i plug in sono d’accordo suil fatto che McNeel dovrebbe mantenere la compatibilità con le vecchie release per non rischiare di perdere utenti che vista la natura di Rhino se si trovano “male” se ne vanno o lo considerano un gioco per passarci qualche ora la domenica!
Noi continuiamo a credere nella piattaforma che abbinata al PLM è strategica per il mondo manifatturiero in abbinata alla stampa 3D, speriamo che prima o poi McNeel si ravveda…
Perché uno sviluppatore cerca id migliorare quello che fa aggiungendo funzionalità utili senza dover perdere tempo nel dover riscrivere qualcosa che esiste già, questa in genere è la filosofia dello sviluppatore.
Nessuno vuole perdere tempo. Non è che scriviamo noi stessi una SDK nuova perchè amiamo perdere tempo.
E non è che per portare alla SDK di Rhino 6 si debba riscrivere tutto di sana pinanta…eddai…
Con il passaggio Rh4-5 dato che si parlava di 32 e 64 bit abbiamo rilasciato una versione 32 bit che garantisse di caricare i plugin di Rh4. Secondo te quanto è durato prima che i plugin aggiornassero a 64 bit?
E quello si che era un salto.
Sono pienamente d’accordo e spero che ci sia un motivo valido per la scelta che hanno fatto. Potrebbe essere colpa dell’ introduzione delle nuove superfici subdivision? 