è una di quelle giornate dove non riesco a cavare un ragno dal buco, oppure
col metodo EvaluateCurve non’è possibile inserire una lista come valore “t”?
purtroppo no Giuseppe 
anzi appunto, mi domandavo come mai essendo che in Py RhinoScriptSyntax gestisce le liste
mi meraviglio che in questo caso non posso fare proprio quello che tu hai mostrato. . . .
edit:
per funzionare debbo indicare ogni singolo valore alla volta tramite index[*]
Salvio … ti sei troppo Grasshopperizzato ! 
Se parli di rhinoscriptsyntax, ci sono alcune funzioni che accettano sia liste che valori singoli, per certi parametri. Credo soprattutto ObjectIds e quindi liste di questi, ma non e’ una regola generale.
Inoltre credo che capiti quando questo non complica il valore restituito e i valori degli altri parametri.
In ogni caso basta vedere la documentazione delle singole funzioni.
EvaluateCurve(curve_id, t, segment_index=-1)
Evaluates a curve at a parameter and returns a 3D point
Parameters:
curve_id (guid): identifier of the curve object
t (number): the parameter to evaluate
segment_index (number, optional): the curve segment index if curve_id identifies a polycurve
Returns:
point: a 3-D point if successful
None: if not successful
Dice che t e’ un numero.
Suppongo che per comportarsi come GH le funzioni rhinoscriptsyntax dovrebbero utilizzare gli alberi GH anziche’ i tipi di dati tradizionali.
Probabilmente sono io che ormai sono un po’ troppo rimbambito, ma il pensiero mi da’ una certa ansia …
confermo Emilio 
è un bel po di tempo che mi sono dedicato quasi totalmente a Gh ed ho perso quel poco acquisito 
proprio per questo chiedevo conferma che fosse cosi, essendo che avevo dei dubbi sul mio operato
ps per evitare i limiti mi sa che prima o poi mi dovrò cimentare con RhCommon 
(oppure direttamente col C# cosi tagliamo definitivamente la testa al toro/rinoceronte ahahahah)
Hehe … per quanto ne so, Rhino 8 introdurra’ anche gli script in C#, quindi mi sembra una buona idea.
Se hai la WIP, prova il comando RhinoCode.
… Ma credo che per ora sia ancora piuttosto … acerbo. 
1 Mi Piace
Emilio indenti direttamente in Rh?
Si’, certo.
Script per Rhino.
Quelli per GH ci sono da parecchi anni, lo sai anche tu. 
a ok mi ha sviato la parola “script”:
col termine script ho sempre inteso un modo minore di scrivere codici,
che differisce dalla programmazione vera, più complessa della prima.
in pratica avevo quasi sperato ad un C# alla mia portata 
Scusa Salvio, non capisco cosa intendi … 
A che tipo di script pensavi ?
Io mi riferisco a uno script in C# in tutto simile agli script in Python o in VBS per Rhino.
… Che come sappiamo possono essere script con una sola istruzione … oppure contenerne migliaia … 
Emilio mi sa che è solo una distinzione che mi ero fatto nella mia testa
in pratica come hai evidenziato sia Rhino.Python che Rhino.VBS io li categorizzavo come script
una versione facilitata di una vera programmazione fatta invece con il C/C#
tanto per fare un paragone:
è come fare differenza tra chi guidava in F1 50anni fa con cambio di marce manuale,
e chi invece oggi in F1 con auto super tecnologiche, riceve un forte aiuto per guidarle.
(per lo meno questo era il mio pensiero 
)
ps tornando alla domanda e allacciandomi alle varie programmazione,
usando Rhino.Common si avrebbe lo stesso risultato di EvaluateCurve?
Si’, e’ vero.
Di solito con script si intende un programmino, spesso ausiliario all’interno di un altro programma (come Rhino).
E in effetti il VBScript, come dice il suo nome, e’ un linguaggio pensato appositamente per gli script.
Python … non saprei quale fosse l’idea iniziale, ma ormai e’ utilizzato per fare di tutto, esclusi solo i casi in cui sia molto importante la velocita’ di esecuzione.
C#, e’ vero, a quanto ne so non e’ nato per gli script, ma nulla vieta di utilizzarlo per quello.
Con le macchine moderne compilare uno script non e’ un problema.
Dal nostro punto di vista di scriptomani per Rhino e GH, direi che usare un linguaggio o l’altro cambia poco (se ci sono le librerie).
Cambia certamente il modo di scrivere le varie istruzioni, ma la logica rimane praticamente la stessa.
Per quanto riguarda il C#, non so se ci sara’ anche per lui una libreria rhinoscriptsyntax, come per Python.
Ma per quanto riguarda RhinoCommon, sara’ meglio che utilizzarla con Python, dato che RhinoCommon e’ scritta originariamente in C#. E usandola con Python qualche piccolo intoppo puo’ venir fuori.
Qui c’e’ la documentazione per il metodo corrispondente
Curve.PointAt Method (rhino3d.com)
Come puoi vedere, anche qui e’ necessario passare un numero, niente liste.
Anzi, direi che questo succede a maggior ragione.
In C# i parametri con cui chiami una funzione devono avere un tipo preciso, non e’ come Python dove puoi passare quello che vuoi e poi decidere dopo come operare.
Quindi se un parametro e’ un numero non puo’ essere una lista.
Allora dovresti passare sempre una lista, anche quando contiene un solo numero.
Non ha senso: complica tutto quanto per … niente.
GH e’ una cosa diversa: deve usare dati composti perche’ non prevede i cicli,
ma in ambiente Rhino puoi fare tutti i cicli che vuoi, quindi e’ meglio se le funzioni della libreria sono piu’ semplici possibile.
Se sono semplici sono versatili e tu le puoi usare come vuoi, anche se ti tocca scrivere un ciclo …
3 Mi Piace
grazie Emilio per la dettagliata spiegazione
anche perché, stavo iniziando a pensare che mi ero fatto tutto un film nella mia testa. meglio così
beh in VBS come hai detto, è incorporato nell’acronimo la parola script
in Python invece viene specificato nel nome della libreria: “rhinoscriptsyntax”
oltre a questo, proprio pochi giorni fa mi sono imbattuto in una discussione nel forum internazionale
dove se ho capito bene dalla traduzione, agli inizi di Rhino gli utenti chiedevano ai sviluppatori di aggiungere sempre nuovi comandi per venire incontro alle loro esigenze. quindi quando questa cosa iniziò a diventare troppo laborioso si è pensato di dotare un modo che fossero stessi gli utenti a realizzare i propri script, e quindi pensarono di adattare il linguaggio VB per interagire con Rhino chiamandolo appunto VBS. col passare del tempo c’erano anche tanti utilizzatori di Rhino che sapendo usare Python ma dovevano imparare anche VBS, e da lì si pensò di adattare Python per gli script in Rhino come faceva appunto VBS.
(non a caso la sintassi di Python e speculare a quella di VBS l’intento era quello, avere gli stessi mezzi)
ma Emilio è come penso? per il metodo postato, tutte quelle righe per ricavare i punti su una curva? ? ?
(anzi mi correggo “il punto”)
senza contare che per la versione Python nell’esempio si è dovuto richiamare sei librerie. . . .
vedi questo era quello che intendevo e cioè: un codice simile per riportare un punto è programmazione,
tu usi il termine scriptomani, per come scrivo io i codici, mi considero più uno scribacchino 
Mi sa che questo non e’ cambiato per niente … 
VBscript e’ un linguaggio fatto da Microsoft. McNeel lo ha utilizzato per gli script per Rhino.
Se non sbaglio il VBS era nato come linguaggio per gli script per le pagine HTML per il Web, come concorrente di Javascript.
Non so se il problema fosse imparare il VBScript …
Gli script in Python sono nati, piu’ o meno, quando McNeel ha deciso di utilizzare dotNET e di scrivere una libreria per dotNET utile sia per gli script (tramite IronPython) che per i plug-in, cioe’ RhinoCommon.
Credo che almeno parte del merito per gli script in Python vada a Steve, che apprezza molto Python,
a quanto credo di capire. 
Ti riferisci a rhinoscriptsyntax, OK.
rhinoscriptsyntax e’ stata fatta apposta per avere le stesse funzioni di RhinoScript.
Ma il grande pregio degli script in Python e’ un altro: poter accedere a RhinoCommon, che in quanto libreria per i plug-in e’ molto piu’ estesa di RhinoScript e quindi ti consente di fare molto di piu’ di quello che puoi fare con RhinoScript o rhinoscriptsyntax.
No, quali righe ?
Se, per esempio, tu hai la curva salvata nella variabile crv e il valore del parametro in par, basta scrivere
var pnt = cur.PointAt( par );
(se non faccio errori) e ti ritrovi il tuo bel punto dentro pnt
Mi sembra piu’ lungo
pnt = rs.EvaluateCurve( cur, par )
… no ?
E’ una scelta. Volendo bastano Rhino e scriptcontext
Inoltre quell’esempio si riferisce ad un plug-in o ad uno script completo che (se capisco bene) serve a ricavare la curvatura in un punto della curva.
Direi che fa parecchio di piu’ che valutare la curva in un punto.
Soprattutto gestisce gli input da parte dell’utilizzatore e verifica alcune cose
… Poi che problema hai con le librerie ?
Guarda che non devi mica pagare per richiamarle.
facevo bene ad avere un forte dubbio su questo, ma non avevo mai approfondito la questione
mi sembrava strano tutto quel “papiello” per trovare un singolo punto su di una curva.
ma se debbo dire la mia, gli esempi della guida linkata sono molto molto furvianti
ad inizio metodo c’é il nome del metodo e la descrizione di cosa esegue, poi mostra un fiume di codice
mentre a differenza della guida di VBS/PYS invece mostrano solo la parte essenziale che serve
ahahahah verissimo, “forse” potrei dire che l’esecuzione si rallenti oppure appesantisce il codice
ma diciamo che sono più paletti che mi impongo. (tendo a seguire la filosofia del minimo essenziale)
a parte che già cosi, e complico le cose, figuriamoci se inizierei a cimentarmi con più librerie
ma più di tutte e che mi dico, ma tanto alla fine mica debbo scrivere un codice per gestire una navicella spaziale, quindi fino a che posso eliminare quante più righe possibili cerco di farlo. pensa che oltre a non mettere nessun parametro per la gestione di errori, non metto nemmeno righe per spiegare cosa fanno,
e non ti dico quante volte mi è capitato di riprendere codici scritti molto tempo prima, e non ricordando la sequenza precisa di cosa e dove cliccare mi da vari errori e mi debbo mettere li con pazienza
poi proprio in questo caso potrei andare a richiamare la libreria “ghpythonlib” sempre in Python
ed usando il metodo “Evaluate Curve” in queto caso mi ritorna la lista punti dei valori nel parametro t
in pratica con questa libreria e come usare Gh tramite codice, secondo me Emilio, potrebbe essere una linea d’incontro tra te e Giuseppe mi ricordo che un tempo lui ti invogliava a fare il salto tra lo scrivere codici e collegare gli “spaghetti” e tu viceversa lo incoraggiavi nello a fare l’incontratio 
beh secondo me, Giuseppe con questa libreria sarebbe molto invogliato avendo la stessa dinamica. . . .
(Giuseppe non mi mandare a quel paese )
Hahahaha … hai ragione, Salvio.
A quanto ne so, il nostro amico Giuseppe e’ molto a suo agio con GH, forse un po’ meno con gli script tradizionali, ma conosce bene anche quelli.
Io sono rimasto ‘invischiato’ nel vecchio andazzo degli script per Rhino, ma non e’ piu’ un problema.
Non lavoro piu’ quindi Rhino mi interessa solo … per divertirmi a rompere le scatole qui sul forum
Sono esempi di tipo diverso.
RhinoCommon serve anche per i plug-in, quindi McNeel ha preparato tutta una serie di esempi riguardanti molte operazioni che cui chi usa RhinoCommon puo’ incontrare.
Come vedrai se ti cimenterai con RhinoCommon, le cose che puoi fare sono molte, e anche piu’ complesse di quanto possibile con rhnioscriptsyntax.
Quindi e’ utile per una particolare operazione, come ad esempio trovare un’intersezione, avere l’esempio che mostri chiaramente la procedura richiesta.
RhinoCommon e’ piu’ potente e quindi necessariamente piu’ articolato e flessibile.
Questa flessibilita’ a volte richiede di dover usare non una, ma una serie di istruzioni per raggiungere l’obiettivo.
Vedrai che quegli esempi si riveleranno molto utili.
… Anzi, a volte ne vorresti di piu’ di esempi e documentazione …
2 Mi Piace