Ciao a tutti
qualcuno sa come evitare che l’esecuzione rhinoscriptsyntax.RotateObject crei la geometria anche nello spazio modello di rhino?
Allego lo script
brep_comparison.gh (810,2 KB)
Ciao Sandra,
provo a dire qualcosa, ma tieni conto che non lavoro su Rhino da 4 anni, conoscevo poco GH anche allora e sto provando su Rhino 6 … sorry. 
Vedo nello script queste istruzioni:
old_sc_doc = sc.doc
sc.doc = Rhino.RhinoDoc.ActiveDoc
Se non ricordo male, questo dice a GH di lavorare sulla ObjectTable di Rhino (non su quella ausiliaria di GH).
Quindi gli oggetti creati penso siano caricati nell’ambiente Rhino.
O a te risulta una cosa diversa ? 
Tra l’altro l’input brep_ref qui risulta vuoto.
Non so, forse questioni di versioni diverse …
Vedo che anche il componente script e’ un po’ diverso da quello che ricordo io.
P.S.
In ogni caso secondo me usare rhinoscriptsyntax in GH ha poco senso … e puo’ portare a situazioni come questa.
Opinione personale, eh.
Ciao Emilio
grazie per la risposta.
In questo script ho come obiettivo confrontare delle geometrie.
Questo lo faccio in parte calcolando dei numeri (inerzie) usando sia la geometria che ricevo in input, sia una geometria derivata nello script (ruotando quelle in input).
E’ qui che uso rhinoscriptsyntax per ruotare l’oggetto. Non so se ci sia una alternativa più furba, senz’altro.
Le impostazioni iniziali relative al Rhino.RhinoDoc.ActiveDoc non le conosco a fondo, ma le avevo inserite per far funzionare una funzione che in rhinoscriptsyntax non c’è. Forse potrei toglierle ora.(Vedo togliendole che in seguito alle rotazioni sono comunque create delle copie)
Se manca la Brep_ref poco male, era un solido.
Mi interessa molto l’osservazione finale che fai, rhinoscriptsyntax in GH. Quale sarebbe l’impiego di rhinoscriptsyntax? Oppure, come potrei richiamare le funzioni di rhino in GHpython?
Grazie
Ciao
Sandra
Provo a spiegare con parole mie …
rhinoscriptsyntax era stato sviluppato da McNeel quando furono introdotti gli script in Python per Rhino.
( Parlo di script per l’ambiente Rhino, non per GH ).
Ma partiamo dall’inizio, piu’ o meno 
.
Prima di allora si potevano solo utilizzare gli script in VBscript, la cui libreria era (ed e’ tuttora) chiamata RhinoScript.
RhinoScript, parlando di oggetti geometrici, permette di lavorare solo con gli oggetti che vediamo a video, cioe’ quelli salvati nel database di Rhino.
E per manipolare questi oggetti usa dei Guid, che sono quelli salvati nel database Rhino per gli oggetti in questione.
Ovviamente questo comporta dei limiti, ad esempio non puoi ricavare l’intersezione di due linee se prima non le disegni. Non puoi cioe’ lavorare con oggetti geometrici teorici, diciamo cosi’, ma solo con quelli disegnati nel documento Rhino.
Comunque RhinoScript era utilissimo lo stesso e molti si erano abituati ad utilizzarlo.
Ad un certo punto (non ricordo se Rhino 4 o Rhino 5) McNeel introdusse una libreria in C# chiamata RhinoCommon, ricavata principalmente dalla storica libreria C++ (OpenNurbs).
Questa libreria e’ molto piu’ vicina a OpenNurbs rispetto a RhinoScript, cioe’ permette di definire oggetti geometrici a piacere, di utilizzare i relativi metodi geometrici su di essi ecc.
In sostanza permette di fare molte piu’ cose rispetto a RhinoScript.
Contemporaneamente a RhinoCommon, McNeel rese disponibili gli script in Python (IronPython per la precisione), che possono utilizzare RhinoCommon.
Il ‘trucco’ (tipico di McNeel, direi ) era utilizzare IronPython, che e’ un interprete Python che gira in ambiente dotNET, e che puo’ utilizzare le librerie dotNET, come RhinoCommon.
A dir la verita’ utilizzare RhinoCommon da Python puo’ a volte essere un po’ scomodo, ma generalmente va tutto liscio.
Qui non so (o non ricordo) come fosse la storia esattamente, cioe’ se fu McNeel di sua iniziativa a scrivere rhinoscriptsyntax o se furono alcuni utilizzatori di RhinoScript a chiedere una libreria piu’ semplice e comoda di RhinoCommon da utilizzare con Python …
Comunque McNeel sviluppo una cosa che era quasi un clone di RhinoScript, ma per Python.
Cosa che naturalmente facilita chi gia’ conosce RhinoScript.
Pero’ ovviamente cosi’ facendo rhinoscriptsyntax soffre delle stesse limitazioni di RhinoScript, cioe’ puo’ lavorare solo sugli oggetti presenti nel database di Rhino, in pratica in una ObjectTable.
Quanto detto finora riguarda gli script per Rhino.
E la cosa ha un suo senso secondo me, perche’ ad esempio si puo’ portare su Python copiando quasi parola per parola un vecchio script VBScript (almeno per quanto riguarda Rhino), e poi eventualmente aggiungere altre feature sfruttando la potenza di RhinoCommon.
Il discorso cambia per GH.
GH tratta oggetti geometrici ‘astratti’, cioe’ senza doverli prima salvare in una ObjectTable.
Questo gli permette di essere piu’ veloce.
Per salvarli nella ObjectTable di Rhino c’e’ il Bake.
Quando nacquero gli script Python per GH, Python utilizzava RhinoCommon.
Come gia’ detto, RhinoCommon utilizza oggetti geometrici ‘astratti’, quindi si adatta perfettamente all’ambiente GH.
Tutto bene quindi… O no ?
Pare che qualcuno abbia chiesto di poter utilizzare rhinoscriptsyntax con GH, e McNeel si e’ convinto …
Per cui, dato che in GH non c’era nessuna ObjectTable che consentisse l’utilizzo di rhnioscriptsyntax, ne e’ stata fatta una apposta.
Quindi in GH adesso c’e’ una ObjectTable che serve solo per poter utilizzare rhinoscriptsyntax.
E per distinguere la ObjectTable di GH da quella di Rhino, negli script in GH, si usa la variabile scriptcontext.doc, come hai fatto tu.
Per questo dicevo che, a mio parere, usare rhinoscriptsyntax in GH, se non c’e’ un motivo particolare, mi sembra una complicazione inutile.
Dico come funzionamento ‘interno’, cioe’ si salvano oggetti in una ObjecTable ‘fantasma’, solo per poter usare i Guid per manipolare le geometrie.
Dal punto di vista di chi scrive lo script puo’ invece essere in po’ piu’ semplice, soprattutto all’inizio, dato che RhinoCommon e’ molto piu’ estesa rispetto a rhinoscriptsyntax, quindi puo’ volerci piu’ tempo per imparare a ‘orientarsi’.
Resta pero’ la possibile confusione tra le due ObjectTable: Rhino e GH.
Per cui la mia opinione e’ che, salvo casi particolari, per gli script GH sia meglio utilizzare RhinoCommon.
( Parlando di script GH in Python, perche’ per gli script GH in C# ovviamente il problema non si pone. )
… Salvo correzioni da parte di Giuseppe o di qualcuno con memoria migliore della mia, ci vuole poco …
Ciao
P.S.
Per avere un’idea del confronto tra le due librerie, puo’ essere utile ‘sbirciare’ come e’ scritta rhinoscriptsyntax.
rhinoscriptsyntax e’ scritta utilizzando RhinoCommon.
E la trovi qui:
La documentazione di RhinoCommon invece la trovi qui:
https://developer.rhino3d.com/api/rhinocommon/
5 Mi Piace
Che bella risposta. Sei stato estremamente chiaro, mi serviva questo inquadramento. Rileggerò ancora la risposta per riordinare le idee.
Stando a quello che dici, assolutamente devo evitare rhnioscriptsyntax, per poter lavorare su oggetti astratti. Quindi cercherò di virare sul Rhino.Common
Grazie mille Emilio
Buon proseguimento
1 Mi Piace