Qualcuno usa Eto?

Scripting e Programmazione
21

Ciao Riccardo,

scusa la domanda da ex-scriptomane curioso con strane idee … :blush:
Lo script editor di Rhino 8 ha la possibilita di caricare velocemente il testo dello script da un file esterno ?
Perche’ se utilizzarlo per scrivere risulta scomodo forse si potrebbe usare un text editor indipendente e poi caricare lo script su Rhino, se l’operazione e’ veloce, certo.
Non credo sia una soluzione per tutti perche’ so che molti si trovano male senza i suggerimenti sui metodi (ammesso che non si possa fare per un editor esterno).
Ma forse nel frattempo, intanto che McNeel ci lavora su … :thinking:

Grazie, ciao !

22

Eh, è proprio quello il punto… è impossibile sapere a memoria tutti i metodi e i vari overload.
Su 7 è veramente tutto immediato, facilissimo e velocissimo.
Esplori i metodi+overload , le proprietà, ecc ecc … tutto con descrizioni compatte ed esaustive. Funziona veramente bene!
Su 8 è peggiorato tutto. Ancora oggi ho la sensazione che chi lo ha creato poi non lo ha mai effettivamente usato, quindi le funzionalità sono state implementate solo a livello teorico, ma mai pratico.
Mi bastano pochi secondi di utilizzo e trovo problemi ovvi e banalissimi… “0-day” feature mancanti.

La mia soluzione attualmente mi permette di fare tutto al massimo della velocità: rimanere sul 7.

È stata reinventata la ruota. Quadrata.

… bastava mantenere l’editor del 7.

1 Mi Piace
23

ragazzi ma alla fine questo script a Giuseppe lo si vuole fare?

ci provo io spero che vada bene e sia di gradimento:

Size-Ring.rvb (1,0 KB)

poi se serve ETO mi fai sapere, nel frattempo Auguri a tutti :slight_smile:

24

ben ritrovatooo!!!

Grazie comunque! Mi spiace che ti sei pure disturbato a farlo ma sono sicuro che farai felice anche altri utenti

Beh diciamo che con Python me la cavicchio… :wink: ero solo curioso di sapere se qualcuno aveva sentito la necessità di dare un minimo di interfaccia al proprio lavoro (extra GH). oppure tutti linea di comando “duri e puri”

quando parlo di minimo intendo questo:

Screenshot 2025-12-22 202731
Screenshot 2025-12-22 202731808×564 46 KB

1 Mi Piace
25

Be’, certo.
Senza quelle info senza dubbio la velocita’ di scrittura si riduce.
E se uno scrive script per ore la differenza si fa sentire.

La mia esperienza e’ stata abbastanza diversa, anche se a volte mi capitava di provare qualcosa alla veloce con l’editor di Rhino, e vedere le info sui metodi era in effetti molto comodo.
Ma di solito usavo un editor esterno, anche perche’ essendo abituato a Vim il modo di funzionare dell’editor Rhino mi faceva sclerare in pochi minuti. :smile:
Quindi non avevo scelta.
E tenendo aperto il browser sulla documentazione delle API McNeel era abbastanza veloce controllare o cercare le informazioni del caso.
Penso anche che non avendo l’abitudine a vedere le info nell’editor, ci si abitua abbastanza in fretta a ricordarsi almeno le cose che si usano piu’ spesso. :grinning:
… O a copiare parti di vecchi script.
Inoltre nel mio caso il tempo che avrei potuto risparmiare con le info sui metodi era relativo …
Penso che di aver trascorso decisamente piu’ tempo a pensare a come impostare lo script (e a capire come funziona RhinoCommon in quella circostanza particolare) e fare test e debugging che a scrivere.
Ma questo vale per me. :blush:

Questo a me e’ capitato abbastanza regolarmente nell’utilizzo di Rhino, fin dall’inizio … :smile:

Vero, anche se perdi l’utilizzo dei metodi introdotti con Rhino 8 …
Penso che sarebbe decisamente meglio conservare, quando possibile, le vecchie versioni dei comandi che sono stati rifatti.
Non e’ raro che in questi casi si perdano feature che per qualcuno erano molto utili.

26

…. se ce ne fossero di interessanti.
Ogni tanto mi imbatto in qualche funzionalità che c’è solo su 8 (ma appunto, lavorando dal 7 mi capita raramente, solo quando cerco dalla documentazione online…)
Quello che mi interesserebbe di più sarebbe il creare nuovi tool per modificare le SubD… cosa che in parte ci stanno già lavorando i dev, ma per Rhino 9…. dall’altro lato lo sviluppo di Rhinocommon per le SubD è fermo, ci sta lavorando Pierre ma è da solo… non posso fare altro che aspettare.

È da due anni ormai che il grosso dei miei lavori su grasshopper ruota tutto attorno alle mesh.
Ormai scrivo in c# il 90% del mio codice, tutto per lavorare le mesh, e uso grasshopper solo come “scheletro” per passare i dati da uno c# all’altro (struttura imbattibile secondo me: flessibilità di un visual language con la potenza di uno hard typed).

Sono ampiamente OT, scusate.

1 Mi Piace
27

Riccardo scusami, ma.. usare l’editor di Visual Studio no? Per quanto Mcneel ci possa lavorare non arriverà mai a quei livelli.

Crei il file.cs dall editor e lo riapri da VS referenziando le librerie Rhino e GH.

E hai tutto ciò che ti serve. Puoi creare pure librerie che puoi condividere tra i vari componenti C#. Direi fantastico no?

28

No. VS è troppo lento per fare quello che faccio io.
E non voglio le funzionalità di VS, basterebbe avere l’editor agile e funzionale quanto quello di Rhino 7, niente di più.

Questa è la mia quotidianità:

2025-12-23 00_36_19-Grasshopper - check STL 237_
2025-12-23 00_36_19-Grasshopper - check STL 237_932×835 140 KB

2025-12-23 00_37_03-Grasshopper - check STL 237_
2025-12-23 00_37_03-Grasshopper - check STL 237_1539×866 203 KB

Buona parte dei componenti dove “avviene qualcosa” è c#, ognuno con codice radicalmente diverso dagli altri.
In questo file da solo ci sono più di 100 componenti c# , ciascuno con 50-300+ righe di codice, poco codice in comune, praticamente nessuna classe specifica da ereditare o riutilizzare… e ho decine di file diversi.

Modificare, gestire e manutenere tutto questo codice c# direttamente da Visual Studio significherebbe ridurre enormemente la velocità di sviluppo, praticamente lo renderebbe impossibile.
A me serve il codice nella posizione in cui deve essere eseguito. Letteralmente avere una posizione 2D di un pezzo di codice aiuta moltissimo a non perdersi e poter continuare a lavorare.
Molti script sono simili ma sotto sotto hanno modifiche radicali che li portano ad ottenere risultati completamente diversi, ho provato ad avere classi in comune, ma non mi è mai tornato utile.
Ho una manciata di metodi che restituiscono classi Rhinocommon, quelle ok, me le porto in giro col copia-incolla.
Attualmente modifico il codice, e dopo pochi secondi è già eseguito e funzionante, e quando ci lavoro tutto il giorno anche solo pochi secondi si trasformano in minuti e minuti fino a ore di tempo buttato… impossibile.
Invece lavorando direttamente in gh, ho già un caso specifico che magari mi da problemi, fixo il codice e dopo pochi secondi posso passare al caso successivo, il tempo tra bug, esecuzione, debug è brevissimo.

Assolutamente fantastico. Mi piacerebbe anche a me usare quelle funzionalità.
Ma prima mi serve avere funzionalità di base, come l’identazione automatica, metodi con descrizioni leggibili e senza avere tendine inutili che si aprono a tradimento, ecc ecc…

—

E in generale, McNeel deve puntare ad un pubblico che è già stato filtrato più volte, fino agli script qualcuno c’è, quelli che si spingono oltre sono ancora meno:

  • 1: utenti di Rhino, non sono infiniti
  • 2: utenti di Rhino che fanno un po di programmazione e provano grasshopper, una minoranza
  • 3: utenti che provano grasshopper e poi provano c# o python, una minoranza delle minoranze
  • 4: utenti che provano pure Visual Studio, una minoranza^3

Certo, serve anche il pt 4. Ma non si va da nessuna parte se gli utenti che arrivano al pt 3 hanno una brutta esperienza e rinunciano in toto.

1 Mi Piace
29

grazie :+1:

io tempo fa mi ero cimentato ad usare ETO e a dir il vero ci stavo quasi prendendo la mano, come hai detto per alcune cose un minimo di interfaccia grafica a volte aiuta (e non poco) ma purtroppo debbo confermare tutto quello che ha sottolineato Riccardo la programmazione con la nuova veste sia per C# che Py non rende piacevole per nulla esperienza e anzi la stronca.

anche in questo caso ho usato RScript anche se potevo scrivere quasi lo stesso codice con Py credevo che fosse un problema del mio pc ma a come vedo se anche Riccardo riscontra le stesse problematiche e frustrazioni ci rimane solo dire “mal comune mezzo gaudio“

ps nello script che ho postato avevo anche provato ad usare solo la riga di comando utilizzando rhino.getstring ma da problemi con inserimento dei valore tramite gli array e quindi in questa situazione ETO sarebbe stato lo strumento adatto per far questo, ma appunto per quanto detto prima e dovendo escludere la riga di comando ho optato per delle soluzioni grafiche fai da me.

:waving_hand: :waving_hand:

30

Ti capisco Ricc, faccio la stessa cosa anche io, ma in un settore diverso. In una definizione gh metto tanti componenti C# custom perché non conosco gli altri plugin e con RhinoCommon si fa prima, generalmente, e meglio. Come te alla fine mi ritrovo a scrivere megliaia di righe, come per il caso delle strutture fotovoltaiche ( Home - Studio Filippone ), ma VS lo trovo imbattibile e non sento molto il bisogno di avere un editor Rhino. Per carità se migliorano è meglio,.. ma vado avanti. È anche vero che il mio sviluppo non è quotidiano però, quindi forse per questo lo sento meno, ma secondo me con VS puoi aprire enne file.cs e modificare da VS tutti gli script insieme senza fare entra ed esci dal componente e potresti essere molto veloce.