Questa parte della guida introduttiva è organizzata come una raccolta di procedure ottimali. Evidenzia diverse strategie apprese, attraverso l'esperienza e la ricerca, per favorire workflow parametrici di qualità. In qualità di progettisti e programmatori, la metrica di qualità è principalmente interessata alla manutenibilità, all'affidabilità, all'usabilità e all'efficienza degli strumenti. Benché queste procedure ottimali presentino esempi specifici per lo scripting basato su testo o visivo, i principi sono applicabili a tutti gli ambienti di programmazione e possono caratterizzare molti workflow computazionali.

Lavorare all'interno di un processo di programmazione visiva può essere una potente attività creativa, ma molto rapidamente il flusso di programma e gli input utente chiave possono essere oscurati dalla complessità e/o dal layout dell'area di lavoro. Saranno esaminate alcune procedure ottimali per la gestione del programma.

Allineamento

Dopo aver aggiunto più di qualche nodo all'area di lavoro, è possibile riorganizzare il layout dei nodi per maggiore chiarezza. Selezionando più nodi e facendo clic con il pulsante destro del mouse sull'area di lavoro, nella finestra a comparsa è disponibile un menu Allinea selezione con le opzioni di giustificazione e distribuzione in X e Y.

1. Selezionare più di un nodo.

2. Fare clic con il pulsante destro del mouse sulla area di lavoro.

3. Utilizzare le opzioni di Allinea selezione.

Note

Avendo maturato un po' di esperienza, si potrebbe "leggere" il programma visivo esaminando i nomi dei nodi e seguendo il flusso di programma. Per gli utenti di tutti i livelli di esperienza, è inoltre consigliabile includere etichette e descrizioni con linguaggio semplice. A tale scopo, in Dynamo è disponibile un nodo delle note con un campo di testo modificabile. È possibile aggiungere note all'area di lavoro in due modi:

1. Individuare il menu Modifica > Crea nota.

2. Utilizzare il tasto di scelta rapida da tastiera CTRL+W.

Una volta aggiunta la nota all'area di lavoro, verrà visualizzato un campo di testo che consente di modificare il testo nella nota. Una volta creata, è possibile modificare la nota facendo doppio clic o facendo clic con il pulsante destro del mouse sul nodo della nota.

Raggruppamento

Quando le dimensioni del programma visivo aumentano, è utile identificare i passaggi più lunghi che verranno eseguiti. È possibile evidenziare raccolte di nodi di dimensioni maggiori con un gruppo per etichettarle con un rettangolo colorato nello sfondo e un titolo. Esistono tre modi per creare un gruppo con più di un nodo selezionato:

1. Individuare il menu Modifica > Crea gruppo.

2. Utilizzare il tasto di scelta rapida da tastiera CTRL+G.

3. Fare clic con il pulsante destro del mouse sull'area di lavoro e selezionare Crea gruppo.

Una volta creato un gruppo, è possibile modificarne le impostazioni, come titolo e colore.

Ecco un esempio di programma a cui sono stati aggiunti gruppi e note:

1. Nota: "Grid Parameters"

2. Nota: "Grid Points"

3. Gruppo: "Create a Grid of Points"

4. Gruppo: "Create an Attractor Point"

5. Nota: "Calibrate Distance Values"

6. Nota: "Variable Grid of Circles"

Questa pagina di riferimento estende le procedure ottimali descritte in Strategie di scripting con maggiori dettagli su librerie di codici, etichettatura e applicazione di stili. Per illustrare i concetti riportati di seguito, verrà utilizzato Python, ma gli stessi principi si applicano a Python e C# (zero-touch) ma con una sintassi diversa.

Quali librerie utilizzare

Le librerie standard sono esterne a Dynamo e sono presenti nei linguaggi di programmazione Python e C# (zero-touch). Dynamo dispone anche di un suo gruppo di librerie che corrispondono direttamente alla gerarchia dei nodi, consentendo all'utente di creare qualsiasi elemento nel codice che potrebbe essere creato con nodi e fili. Di seguito è riportata una guida per gli elementi a cui ciascuna libreria di Dynamo consente di accedere e per quando utilizzarne una standard.

Librerie standard e librerie di Dynamo

• Le librerie standard di Python e C# possono essere utilizzate per creare strutture avanzate di flussi e dati nell'ambiente Dynamo.

• Le librerie di Dynamo corrispondono direttamente alla gerarchia dei nodi per la creazione della geometria e di altri oggetti di Dynamo.

Librerie di Dynamo

1. ProtoGeometry*

   • Funzionalità: arco, riquadro di delimitazione, cerchio, cono, sistema di coordinate, cuboide, curva, cilindro, spigolo, ellisse, arco di ellisse, faccia, geometria, elica, gruppo di indici, linea, mesh, curva NURBS, superficie NURBS, piano, punto, poligono, rettangolo, solido, sfera, superficie, topologia, TSpline, UV, vettore, vertice.

   • Modalità di importazione: import Autodesk.DesignScript.Geometry

   ``

2. DSCoreNodes

   • Funzionalità: colore, intervallo di colori 2D, data e ora, intervallo di tempo, IO, formula, logica, elenco, matematica, Quadtree, stringa, filettatura.

   • Modalità di importazione: import DSCore

3. Tassellamento

   • Funzionalità: superficie convessa, Delaunay, Voronoi.

   • Modalità di importazione: import Tessellation

4. DSOffice

   • Funzionalità: Excel.

   • Modalità di importazione: import DSOffice

Etichettatura con attenzione

Durante lo scripting, vengono costantemente utilizzati identificatori per denotare elementi quali variabili, tipi, funzioni e altre entità. Attraverso questo sistema di notazione simbolica, mentre si creano algoritmi si può comodamente fare riferimento alle informazioni tramite etichette, solitamente composte da una sequenza di caratteri. L'assegnazione di nomi alle cose gioca un ruolo significativo nella scrittura di un codice che possa essere facilmente letto e compreso da altri e in futuro anche dal programmatore stesso. Di seguito sono riportati alcuni suggerimenti da tenere presenti durante la denominazione di elementi nello script:

È possibile utilizzare abbreviazioni, ma spiegare l'abbreviazione con un commento:

### BAD
csfX = 1.6
csfY= 1.3
csfZ = 1.0

### GOOD
# column scale factor (csf)
csfX = 1.6
csfY= 1.3
csfZ = 1.0

Evitare l'etichettatura ridondante:

### BAD
import car
seat = car.CarSeat()
tire = car.CarTire()

### GOOD
import car
seat = car.Seat()
tire = car.Tire()

Utilizzare la logica positiva per i nomi delle variabili anziché la logica negativa:

### BAD
if 'mystring' not in text:
    print 'not found'
else:
    print 'found'
    print 'processing'

### GOOD
if 'mystring' in text:
    print 'found'
    print 'processing'
else:
    print 'not found'

Preferire la "notazione inversa":

### BAD
agents = …
active_agents = …
dead_agents ...

### GOOD
agents = …
agents_active = …
agents_dead = ...

È più adatta, in termini strutturali.

Per accorciare le catene troppo lunghe e spesso ripetute, è necessario utilizzare alias:

### BAD
from RevitServices.Persistence import DocumentManager

DocumentManager = DM

doc = DM.Instance.CurrentDBDocument
uiapp = DM.Instance.CurrentUIApplication

### GOOD
from RevitServices.Persistence import DocumentManager as DM

doc = DM.Instance.CurrentDBDocument
uiapp = DM.Instance.CurrentUIApplication

L'aliasing può portare rapidamente a programmi molto confusi e non standard.

Utilizzare solo parole necessarie:

### BAD
rotateToCoord = rotateFromCoord.Rotate(solid.ContextCoordinateSystem.Origin,Vector.ByCoordinates(0,0,1),5)

### GOOD
toCoord = fromCoord.Rotate(solid.ContextCoordinateSystem.Origin,Vector.ByCoordinates(0,0,1),5)

"Tutto dovrebbe essere reso il più semplice possibile, ma non più semplice." – Albert Einstein

Stile coerente

In generale, esistono più modi per programmare qualsiasi cosa, quindi lo "stile personale" di scripting è il risultato delle innumerevoli piccole decisioni che si è scelto di prendere (o di non prendere) lungo la strada. Detto questo, la leggibilità e la gestibilità del codice sono un risultato diretto della sua coerenza interna e della sua conformità alle convenzioni stilistiche generali. Come regola generale, anche il codice che risulta identico in due punti dovrebbe funzionare allo stesso modo. Di seguito sono riportati alcuni suggerimenti per la scrittura di un codice chiaro e coerente.

Convenzioni di denominazione: scegliere una delle convenzioni riportate di seguito per ogni tipo di entità nel codice e attenersi ad essa.

• Variabili, funzioni, metodi, pacchetti, moduli: lower_case_with_underscores

• Classi ed eccezioni: CapWords

• Metodi protetti e funzioni interne: _single_leading_underscore(self, ...)

• Metodi privati: __double_leading_underscore(self, ...)

• Costanti: ALL_CAPS_WITH_UNDERSCORES

Suggerimento: evitare variabili con una lettera (soprattutto l, O, I) tranne che in blocchi molto corti, quando il significato è chiaramente visibile dal contesto immediato.

Utilizzo di righe vuote:

• Circondare le definizioni di classi e funzioni di livello superiore con due righe vuote.

  • Le definizioni dei metodi all'interno di una classe sono circondate da una singola riga vuota.

  • È possibile utilizzare (con moderazione) righe vuote aggiuntive per separare gruppi di funzioni correlate.

Evitare spazi estranei:

• Immediatamente all'interno delle parentesi tonde, quadre o graffe:

  Copy

  ### BAD
  function( apples[ 1 ], { oranges: 2 } )

  Copy

  ### GOOD:
  function(apples[1], {oranges: 2})

• Subito prima di una virgola, un punto e virgola o due punti:

  Copy

  ### BAD
   if x == 2 : print x , y ; x , y = y , x

  Copy

  ### GOOD
    if x == 2: print x, y; x, y = y, x

• Subito prima della parentesi aperta che inizia l'elenco di argomenti di una chiamata di funzione:

  Copy

  ### BAD
  function (1)

  Copy

  ### GOOD
  function(1)

• Subito prima della parentesi aperta che inizia un'indicizzazione o un sezionamento:

  Copy

  ### BAD
  dict ['key'] = list [index]

  Copy

  ### GOOD
  dict['key'] = list[index]

• Circondare sempre questi operatori binari con uno spazio su entrambi i lati:

  Copy

  assignment ( = )
  augmented assignment ( += , -= etc.)
  comparisons ( == , < , > , != , <> , <= , >= , in , not in , is , is not )
  Booleans ( and , or , not )

Controllare la lunghezza della riga:

• Non superare circa i 79 caratteri.

• Limitare la larghezza richiesta per la finestra dell'editor consente di mostrare diversi file aperti affiancati e funziona bene quando si utilizzano gli strumenti di verifica del codice che presentano le due versioni in colonne adiacenti.

• Le righe lunghe possono essere suddivise su più righe con il ritorno a capo delle espressioni tra parentesi:

Evitare commenti ovvi e ridondanti:

• A volte meno commenti creano codice più leggibile. Soprattutto se obbliga ad utilizzare nomi di simboli significativi.

• L'adozione di buone abitudini di codifica riduce la dipendenza dai commenti:

  Copy

  ### BAD
    # get the country code
    country_code = get_country_code(address)
  
    # if country code is US
    if (country_code == 'US'):
      # display the form input for state
      print form_input_state()

  Copy

  ### GOOD
    # display state selection for US users
    country_code = get_country_code(address)
    if (country_code == 'US'):
      print form_input_state()

Suggerimento: i commenti indicano perché, il codice indica come.

Verificare il codice open source:

• I progetti open source sono realizzati grazie alle iniziative collaborative di molti sviluppatori. Questi progetti devono mantenere un elevato livello di leggibilità del codice, in modo che il team possa collaborare nel modo più efficiente possibile. È pertanto consigliabile esaminare il codice sorgente di questi progetti per osservare le attività di questi sviluppatori.

• Migliorare le convenzioni:

  • Chiedersi se ciascuna convenzione soddisfa o meno le esigenze imminenti.

  • Le funzionalità/L'efficienza sono compromesse?

Standard di C# (zero-touch)

Consultare queste pagine Wiki per indicazioni sulla scrittura di C# per la funzionalità zero-touch e sul contributo a Dynamo:

• Questa Wiki illustra alcuni standard di codifica generali per la documentazione e il test del codice: https://github.com/DynamoDS/Dynamo/wiki/Coding-Standards.

• Questa Wiki illustra in particolare gli standard di denominazione per librerie, categorie, nomi di nodi, nomi di porte e abbreviazioni: https://github.com/DynamoDS/Dynamo/wiki/Naming-Standards.

Oggetti non gestiti:

Quando si utilizza la libreria della geometria di Dynamo (ProtoGeometry) da Python o C#, gli oggetti della geometria che si creano non verranno gestiti dalla macchina virtuale e la memoria di molti di questi oggetti dovrà essere pulita manualmente. Per eliminare oggetti nativi o non gestiti, è possibile utilizzare il metodo Dispose o la parola chiave using. Per una panoramica, vedere questa voce Wiki: https://github.com/DynamoDS/Dynamo/wiki/Zero-Touch-Plugin-Development#dispose--using-statement.

È sufficiente eliminare le risorse non gestite che non vengono restituite nel grafico o in cui non viene memorizzato un riferimento. Per il resto di questa sezione, si farà riferimento a questi oggetti come geometria intermedia. Nell'esempio di codice riportato di seguito è mostrato un esempio di questa classe di oggetto. Questa funzione di C# zero-touch singleCube restituisce un singolo cubo, ma crea 10000 cubi aggiuntivi durante l'esecuzione. Si può far finta che quest'altra geometria sia stata utilizzata come geometria di costruzione intermedia.

Questa funzione zero-touch probabilmente provocherà un arresto anomalo di Dynamo. E ciò perché sono stati creati 10000 solidi, ma ne è stato memorizzato solo uno e ne è stato restituito solo uno. Si dovrebbero invece eliminare tutti i cubi intermedi, tranne quello restituito. Non si desidera eliminare ciò che viene restituito, perché verrà propagato nel grafico e utilizzato da altri nodi.

public Cuboid singleCube(){

  var output = Cuboid.ByLengths(1,1,1);

  for(int i = 0; i<10000;i++){
    output = Cuboid.ByLengths(1,1,1);
  }
  return output;
}

Il codice corretto avrà un aspetto simile al seguente:

 public Cuboid singleCube(){

   var output = Cuboid.ByLengths(1,1,1);
   var toDispose = new List<Geometry>();

   for(int i = 0; i<10000;i++){
     toDispose.Add(Cuboid.ByLengths(1,1,1));
   }

   foreach(IDisposable item in toDispose ){
     item.Dispose();
   }

   return output;
 }

In generale, è necessario eliminare solo la geometria come Surfaces, Curves e Solids. Per essere sicuri, tuttavia, è possibile eliminare tutti i tipi di geometria (Vectors, Points, CoordinateSystems).

Prima di questo capitolo, nella guida introduttiva è stato descritto come implementare le potenti funzionalità di scripting visivo di Dynamo. Una buona comprensione di queste funzionalità è una solida base e il primo passo nella compilazione di efficaci programmi visivi. Quando si utilizzano i programmi visivi sul campo, li si condivide con i colleghi, si correggono gli errori oppure si testano i limiti, ci sono altri problemi da risolvere. Se un altro utente sta utilizzando il programma o ci si aspetta di aprirlo tra sei mesi, deve avere un'immediata chiarezza grafica e logica. Dynamo dispone di molti strumenti per gestire la complessità del programma e in questo capitolo sono fornite linee guida su quando utilizzarli.

Riduzione della complessità

Man mano che si sviluppa il grafico di Dynamo e si testano le idee, è possibile che la dimensione e la complessità aumentino rapidamente. Sebbene sia importante creare un programma funzionante, è altrettanto importante farlo il più semplicemente possibile. Non solo il grafico verrà eseguito in modo più rapido e più prevedibile, ma insieme ad altri utenti si potrà comprendere la sua logica in un secondo momento. Di seguito sono riportati diversi modi che consentono di chiarire la logica del grafico.

Modularizzazione con gruppi

• I gruppi consentono di creare parti distinte dal punto di vista funzionale durante la compilazione di un programma.

• I gruppi consentono di spostare parti di grandi dimensioni del programma mantenendo al contempo la modularità e l'allineamento.

• È possibile modificare il colore del gruppo per differenziare l'azione dei gruppi (input e funzioni).

• È possibile utilizzare i gruppi per iniziare a organizzare il grafico per semplificare la creazione di nodi personalizzati.

I colori in questo programma identificano lo scopo di ciascun gruppo. Questa strategia può essere utilizzata per creare la gerarchia in eventuali modelli o standard grafici sviluppati.

1. Gruppo di funzioni (blu)

2. Gruppo di input (arancione)

3. Gruppo di script (verde)

Per informazioni sull'utilizzo dei gruppi, fare riferimento a Gestione del programma.

Sviluppo efficiente con i blocchi di codice

• A volte, è possibile utilizzare un blocco di codice per digitare un metodo di nodo o numero più rapidamente della ricerca (Point.ByCoordinates, Number, String, Formula).

• I blocchi di codice sono utili quando si desidera definire funzioni personalizzate in DesignScript per ridurre il numero di nodi in un grafico.

Entrambi i valori 1 e 2 svolgono la stessa funzione. La scrittura di alcune righe di codice è molto più rapida rispetto alla ricerca e all'aggiunta di ogni nodo singolarmente. Anche il blocco di codice è molto più conciso.

1. Linguaggio DesignScript scritto nel blocco di codice

2. Programma equivalente nei nodi

Per informazioni su come utilizzare il blocco di codice, vedere Che cos'è un blocco di codice.

Compressione con Nodo da aggiungere al codice

• È possibile ridurre la complessità di un grafico utilizzando Nodo da aggiungere al codice, che consente di acquisire una raccolta di nodi semplici e di scrivere il linguaggio DesignScript corrispondente in un unico blocco di codice.

• Nodo da aggiungere al codice può** comprimere il codice senza eliminare la chiarezza del programma.**

• Di seguito sono riportati i vantaggi dell'utilizzo di Nodo da aggiungere al codice:

  • Comprime facilmente il codice in un componente che è ancora modificabile.

  • Può semplificare una parte significativa del grafico.

  • È utile se il "mini-programma" non verrà spesso modificato.

  • È utile per incorporare altre funzionalità del blocco di codice, come le funzioni.

• Di seguito sono riportati gli svantaggi dell'utilizzo di Nodo da aggiungere al codice:

  • La denominazione generica lo rende meno leggibile.

  • È più difficile da comprendere per altri utenti.

  • Non è possibile tornare facilmente alla versione di programmazione visiva.

1. Programma esistente

2. Blocco di codice creato da Nodo da aggiungere al codice

Per informazioni su come utilizzare Nodo da aggiungere al codice, vedere Sintassi di DesignScript.

Accesso flessibile ai dati con List@Level

• L'utilizzo di List@Level può aiutare a ridurre la complessità del grafico sostituendo i nodi List.Map e List.Combine che potrebbero occupare una notevole quantità di spazio nell'area di disegno.

• List@Level offre un** modo più rapido rispetto a List.Map/List.Combine per costruire la logica dei nodi**, consentendo di accedere ai dati a qualsiasi livello in un elenco direttamente dalla porta di input di un nodo.

Si può verificare quanti valori True BoundingBox.Contains restituisce e in quali elenchi attivando List@Level per l'input "list" di CountTrue. List@Level consente all'utente di determinare da quale livello l'input acquisirà i dati. L'utilizzo di List@Level è flessibile, efficiente e altamente incoraggiato rispetto ad altri metodi che coinvolgono List.Map e List.Combine.

1. Conteggio dei valori true al livello di elenco 2

2. Conteggio dei valori true al livello di elenco 3

Per informazioni su come utilizzare List@Level, fare riferimento a Elenchi di elenchi.

Mantenimento della leggibilità

Oltre a rendere il grafico il più semplice ed efficiente possibile, è necessario puntare alla chiarezza grafica. Nonostante i grandi sforzi compiuti per rendere il grafico intuitivo con raggruppamenti logici, le relazioni potrebbero non essere subito visibili. Una semplice nota all'interno di un gruppo o la ridenominazione di un dispositivo di scorrimento consente all'utente corrente o ad un altro utente di evitare un'inutile confusione o panoramica del grafico. Di seguito sono riportati diversi modi per applicare la coerenza grafica tra i grafici e al loro interno.

Continuità visiva con l'allineamento dei nodi

• Per ridurre il lavoro dopo aver completato la creazione del grafico, è necessario provare ad assicurarsi che il layout del nodo sia leggibile tramite l'allineamento di nodi spesso e mentre si procede.

• Se altri utenti lavoreranno con il grafico, è necessario verificare che il layout nodo-collegamento fluisca facilmente prima del rilascio.

• Per semplificare l'allineamento, utilizzare la funzionalità Semplifica layout nodi per allineare automaticamente il grafico, anche se in modo meno preciso rispetto a quello eseguito manualmente.

1. Grafico non organizzato

2. Grafico allineato

Per informazioni sull'utilizzo dell'allineamento dei nodi, fare riferimento a Gestione del programma.

Assegnazione di etichette descrittive mediante ridenominazione

• La ridenominazione degli input consente ad altri utenti di comprendere facilmente il grafico, in particolare se ciò in cui questi si inseriranno sarà fuori dallo schermo.

• È consigliabile rinominare i nodi diversamente dagli input. In alternativa, è possibile creare un nodo personalizzato da un cluster di nodi e rinominarlo. Si capirà che contiene qualcos'altro.

1. Input per la manipolazione della superficie

2. Input per i parametri architettonici

3. Input per lo script di simulazione del drenaggio

Per rinominare un nodo, fare clic con il pulsante destro del mouse sul nome e scegliere "Rinomina nodo...".

Spiegazione con delle note

• Se un elemento del grafico richiede una spiegazione in un linguaggio semplice che i nodi non possono esprimere, è necessario aggiungere una nota.

• Se una raccolta di nodi o un gruppo è troppo grande o complesso e non può essere facilmente compreso immediatamente, è necessario aggiungere una nota.

1. Una nota che descrive la parte del programma che restituisce le distanze di traslazione non elaborate

2. Una nota che descrive il codice che associa tali valori a un'onda sinusoidale

Per informazioni su come aggiungere una nota, fare riferimento a Gestione del programma.

Flessibilità continua

Durante la compilazione dello script visivo, è importante verificare che ciò che viene restituito sia quello previsto. Non tutti gli errori o i problemi causano immediatamente la mancata esecuzione del programma, in particolare valori nulli o pari a zero che potrebbero influire più a valle. Questa strategia viene inoltre discussa nel contesto dello scripting di testo in Strategie di scripting. La seguente procedura consentirà di assicurarsi di ottenere quanto previsto.

Monitoraggio dei dati con i simboli circolari di anteprima e controllo

• Durante la compilazione del programma, utilizzare i simboli circolari di anteprima o controllo per** verificare che gli output chiave restituiscano ciò che è previsto.**

I nodi Watch vengono utilizzati per confrontare:

1. Le distanze di traslazione non elaborate

2. I valori passati tramite l'equazione in seno

Per informazioni su come utilizzare Watch, fare riferimento a Libreria.

Garanzia di riutilizzabilità

È molto probabile che qualcun altro stia aprendo il programma in un certo punto, anche se si lavora in modo indipendente. Deve essere in grado di comprendere rapidamente cosa il programma richiede e produce dai relativi input e output. Ciò è particolarmente importante quando si sviluppa un nodo personalizzato da condividere con la community di Dynamo e utilizzarlo nel programma di qualcun'altro. Queste pratiche portano a programmi e nodi solidi e riutilizzabili.

Gestione dell'I/O

• Per garantire la leggibilità e la scalabilità, è necessario provare a ridurre al minimo input e output il più possibile.

• È necessario tentare di pianificare la modalità di compilazione della logica creando innanzitutto una descrizione approssimativa di come la logica potrebbe funzionare anche prima di aggiungere un singolo nodo all'area di disegno. Mentre si sviluppa la descrizione approssimativa, è necessario tenere traccia degli input e degli output che verranno inseriti negli script.

Uso delle preimpostazioni per incorporare i valori di input

• Se nel grafico sono presenti determinate opzioni o condizioni che si desidera incorporare, è necessario utilizzare le preimpostazioni per l'accesso rapido.

• È inoltre possibile utilizzare le preimpostazioni per ridurre la complessità memorizzando nella cache valori specifici del dispositivo di scorrimento in un grafico con tempi di esecuzione lunghi.

Per informazioni sull'uso delle preimpostazioni, fare riferimento a Gestione dei dati con le preimpostazioni.

Contenimento di programmi con nodi personalizzati

• È necessario utilizzare un nodo personalizzato se è possibile raccogliere il programma in un unico contenitore.

• È necessario utilizzare un nodo personalizzato quando una parte del grafico verrà riutilizzata spesso in altri programmi.

• È necessario utilizzare un nodo personalizzato se si desidera condividere una funzionalità con la community di Dynamo.

La raccolta del programma di traslazione dei punti in un nodo personalizzato rende un programma affidabile, unico e molto più facile da comprendere. Le porte di input con nome significativo consentono ad altri utenti di comprendere come utilizzare il nodo. Ricordarsi di aggiungere le descrizioni e i tipi di dati richiesti per ogni input.

1. Programma dell'attrattore esistente

2. Nodo personalizzato che raccoglie questo programma, PointGrid

Per informazioni sull'utilizzo dei nodi personalizzati, fare riferimento a Introduzione ai nodi personalizzati.

Creazione di modelli

• È possibile creare modelli per stabilire standard grafici nei grafici visivi al fine di garantire che i collaboratori abbiano un metodo standardizzato di comprensione del grafico.

• Durante la creazione di un modello, è possibile standardizzare i colori dei gruppi e le dimensioni dei font per suddividere in categorie i tipi di workflow o le azioni di dati.

• Durante la creazione di un modello, è anche possibile standardizzare il modo in cui si desidera etichettare, colorare o applicare stili alla differenza tra i workflow front-end e back-end nel grafico.

1. L'interfaccia utente, o front-end, del programma include un nome di progetto, dispositivi di scorrimento di input e geometria di importazione.

2. Il back-end del programma.

3. Categorie di colori dei gruppi (progettazione generale, input, scripting Python, geometria importata).

Esercizio - Tetto architettonico

Scaricare il file di esempio facendo clic sul collegamento seguente.

Un elenco completo di file di esempio è disponibile nell'Appendice.

Ora che sono state definite diverse pratiche ottimali, è possibile applicarle ad un programma che è stato realizzato rapidamente. Sebbene il programma possa generare il tetto, lo stato del grafico è una "mappa mentale" del programmatore. Non è presente alcuna organizzazione o descrizione del suo utilizzo. Si esamineranno le procedure ottimali per organizzare, descrivere e analizzare il programma in modo che altri utenti possano comprendere come utilizzarlo.

Il programma funziona, ma il grafico è disorganizzato.

Iniziare determinando i dati e la geometria restituiti dal programma.

Comprendere quando si apportano modifiche importanti ai dati è fondamentale per stabilire le divisioni logiche o la modularità. Provare a controllare il resto del programma con i nodi Watch per verificare se è possibile determinare i gruppi prima di andare al passaggio successivo.

1. Questo Code Block con un'equazione matematica è un elemento cruciale del programma. Un nodo Watch visualizza ciò che restituisce elenchi di distanze di traslazione.

2. Lo scopo di quest'area non è immediatamente ovvio. La disposizione dei valori True al livello di elenco L2 di BoundingBox.Contains e la presenza di List.FilterByBoolMask suggeriscono che si sta campionando una parte della griglia di punti.

Una volta comprese le parti elementari del programma, si possono inserirle in gruppi.

I gruppi consentono all'utente di differenziare visivamente le parti del programma.

1. Importare il modello della planimetria 3D

2. Convertire la griglia di punti in base all'equazione in seno

3. Parte campione della griglia di punti

4. Creare una superficie del tetto architettonico

5. Creare una facciata continua in vetro

Con i gruppi stabiliti, allineare i nodi per creare una continuità visiva nel grafico.

La continuità visiva consente all'utente di vedere il flusso del programma e le relazioni implicite tra i nodi.

Rendere il programma più accessibile aggiungendo un altro livello di miglioramenti grafici. Aggiungere note per descrivere il funzionamento di una specifica area del programma, assegnare nomi personalizzati agli input e assegnare colori a diversi tipi di gruppi.

Questi miglioramenti grafici consentono all'utente di conoscere meglio le attività del programma. I diversi colori dei gruppi consentono di distinguere gli input dalle funzioni.

1. Note

2. Input con nomi descrittivi

Prima di iniziare a comprimere il programma, è necessario individuare una posizione strategica per introdurre il simulatore di drenaggio dello script Python. Inserire l'output della prima superficie del tetto in scala nel rispettivo input di scripting.

Si è scelto di integrare lo scripting in questo punto del programma in modo che la simulazione del drenaggio possa essere eseguita sulla superficie originale del tetto singolo. Questa superficie specifica non viene visualizzata in anteprima, ma consente di evitare di scegliere la superficie superiore della PolySurface smussata.

1. Geometria di origine per l'input dello script

2. Nodo Python

3. Dispositivi di scorrimento di input

4. "Interruttore" attivato/disattivato

Si può semplificare il grafico ora che tutto è pronto.

La compressione del programma con Nodo da aggiungere al codice e Nodo personalizzato ha ridotto notevolmente la dimensione del grafico. I gruppi che creano la superficie del tetto e i muri sono stati convertiti in codice poiché sono molto specifici di questo programma. Il gruppo di traslazione dei punti è contenuto in un nodo personalizzato, in quanto potrebbe essere utilizzato in un altro programma. Nel file di esempio, creare il proprio nodo personalizzato dal gruppo di traslazione dei punti.

1. Nodo personalizzato per contenere il gruppo di "traslazione della griglia di punti"

2. Nodo da aggiungere al codice per comprimere i gruppi di "creazione della superficie del tetto architettonico e della facciata continua"

Come passaggio finale, creare preimpostazioni per forme di tetto esemplificative.

Questi input sono i fattori principali della forma del tetto e consentiranno agli utenti di vedere il potenziale del programma.

Il programma con le viste di due preimpostazioni.

I modelli di drenaggio del tetto offrono all'utente una vista analitica delle rispettive preimpostazioni.

Lo scripting basato su testo all'interno dell'ambiente di creazione di scripting visivo consente relazioni potenti e visive utilizzando DesignScript, Python e ZeroTouch (C#). L'utente può esporre elementi quali dispositivi di scorrimento di input, comprimere operazioni di grandi dimensioni in DesignScript e accedere a potenti strumenti e librerie tramite Python o C#, tutto nella stessa area di lavoro. Se gestita in modo efficace, la combinazione di queste strategie può conferire un elevato livello di personalizzazione, chiarezza ed efficienza al programma generale. Di seguito è riportato un insieme di linee guida per ottimizzare lo script visivo con lo script testuale.

Sapere quando eseguire lo script

Lo scripting di testo può stabilire relazioni di maggiore complessità rispetto alla programmazione visiva, ma anche le loro funzionalità si sovrappongono in modo significativo. Ciò è utile perché i nodi sono di fatto codice preconfezionato e probabilmente si potrebbe scrivere un intero programma Dynamo in DesignScript o Python. Tuttavia, si utilizza lo scripting visivo perché l'interfaccia di nodi e collegamenti crea un flusso intuitivo di informazioni grafiche. Sapere dove le funzionalità dello scripting di testo vanno oltre lo scripting visivo fornirà importanti dettagli su quando deve essere utilizzato senza dover dimenticare la natura intuitiva di nodi e collegamenti. Di seguito sono riportate le linee guida su quando eseguire lo script e su quale linguaggio utilizzare.

Utilizzare lo scripting di testo per:

• Loop

• Ricorsione

• Accesso alle librerie esterne

Scegliere una linguaggio:

Pensiero parametrico

Quando si esegue lo scripting in Dynamo, un ambiente inevitabilmente parametrico, è opportuno strutturare il codice in relazione alla struttura dei nodi e dei collegamenti in cui si troverà. Considerare il nodo contenente lo script di testo come se si trattasse di qualsiasi altro nodo del programma con alcuni input specifici, una funzione e un output previsto. In questo modo il codice all'interno del nodo viene immediatamente corredato di un piccolo gruppo di variabili con cui lavorare, la chiave per un sistema parametrico ordinato. Di seguito sono riportate alcune linee guida per una migliore integrazione del codice in un programma visivo.

Identificare le variabili esterne:

• Provare a determinare i parametri specificati nel problema di progettazione in modo da poter costruire un modello che consenta la creazione diretta di tali dati.

• Prima di scrivere il codice, identificare le variabili:

  • Un gruppo minimo di input

  • L'output desiderato

  • Costanti

Prima di scrivere il codice, sono state definite diverse variabili.

1. La superficie su cui verrà simulata la pioggia.

2. Il numero di gocce di pioggia (agenti) desiderato.

3. La distanza percorsa delle gocce di pioggia.

4. Alternare tra scendere nel percorso più ripido e attraversare la superficie.

5. Nodo Python con il rispettivo numero di input.

6. Un blocco di codice per rendere blu le curve restituite.

Progettare le relazioni interne:

• Il parametricismo consente la modifica di determinati parametri o variabili per manipolare o cambiare il risultato finale di un'equazione o un sistema.

• Ogni volta che le entità nello script sono correlate in modo logico, è necessario definirle come funzioni l'una dell'altra. In questo modo, quando una viene modificata, l'altra può essere aggiornata in modo proporzionale.

• Ridurre al minimo il numero di input esponendo solo i parametri chiave:

  • Se è possibile derivare un gruppo di parametri da più parametri principali, esporre solo i parametri principali come input di script. Ciò consente di migliorare la fruibilità dello script riducendone la complessità dell'interfaccia.

I "moduli" del codice dell'esempio nel nodo Python.

1. Input.

2. Variabili interne allo script.

3. Un loop che utilizza questi input e variabili per eseguirne la funzione.

Don't repeat yourself (principio DRY):

• Quando si hanno più modi per esprimere la stessa cosa nello script, ad un certo punto le rappresentazioni duplicate non verranno sincronizzate, cosa che può portare a problemi di manutenzione, scarsa scomposizione in fattori e contraddizioni interne.

• Il principio DRY prevede che "ogni conoscenza deve avere una rappresentazione unica, inequivocabile e autorevole all'interno di un sistema":

  • Se il principio viene applicato correttamente, tutti gli elementi correlati nello script cambiano in modo prevedibile e uniforme e tutti gli elementi non correlati non hanno conseguenze logiche l'uno sull'altro.

### BAD
for i in range(4):
  for j in range(4):
    point = Point.ByCoordinates(3*i, 3*j, 0)
    points.append(point)

### GOOD
count = IN[0]
pDist = IN[1]

for i in range(count):
  for j in range(count):
    point = Point.ByCoordinates(pDist*i, pDist*j, 0)
    points.append(point)

Strutturazione modulare

Man mano che il codice diventa sempre più lungo e più complesso, la "grande idea" o l'algoritmo complessivo diventa sempre più illeggibile. Inoltre, diventa più difficile tenere traccia di quali cose specifiche accadono (e dove), trovare bug quando le cose vanno male, integrare altro codice e assegnare attività di sviluppo. Per evitare questi problemi, è opportuno scrivere il codice in moduli, una strategia organizzativa che suddivide il codice in base all'attività che esegue. Di seguito sono riportati alcuni suggerimenti per rendere gli script più gestibili tramite la modularizzazione.

Scrivere il codice in moduli:

• Un "modulo" è un gruppo di codice che esegue un'attività specifica, simile ad un nodo di Dynamo nell'area di lavoro.

• Può trattarsi di qualsiasi elemento che deve essere separato visivamente dal codice adiacente (una funzione, una classe, un gruppo di input o le librerie che si stanno importando).

• Lo sviluppo di codice nei moduli consente di sfruttare la qualità visiva e intuitiva dei nodi, nonché le complesse relazioni che possono essere ottenute solo tramite lo scripting di testo.

Questi loop chiamano una classe denominata "agente" che verrà sviluppata nell'esercizio.

1. Un modulo del codice che definisce il punto iniziale di ogni agente.

2. Un modulo del codice che aggiorna l'agente.

3. Un modulo del codice che disegna una traccia per il percorso dell'agente.

Individuare il riutilizzo del codice:

• Se il codice esegue la stessa operazione (o molto simile) in più posizioni, trovare modi di raggrupparla in una funzione che può essere chiamata.

• Le funzioni "manager" controllano il flusso del programma e contengono principalmente chiamate alle funzioni "worker" che gestiscono dettagli di basso livello, ad esempio lo spostamento di dati tra le strutture.

In questo esempio vengono create sfere con raggi e colori in base al valore Z dei punti centrali.

1. Due funzioni principali "worker": una che crea sfere con raggi e visualizza i colori in base al valore Z del punto centrale.

2. Una funzione principale "manager" che combina le due funzioni worker. Chiamando questa funzione si chiameranno entrambe le funzioni al suo interno.

Mostrare solo ciò che è necessario vedere:

• Un'interfaccia del modulo esprime gli elementi forniti e richiesti dal modulo.

• Una volta definite le interfacce tra le unità, la progettazione dettagliata di ciascuna unità può procedere separatamente.

Separabilità/Sostituibilità:

• Ogni modulo ignora l'esistenza dell'altro.

Forme generali di modularizzazione:

• Raggruppamento di codici:

  Copy

  # IMPORT LIBRARIES
  import random
  import math
  import clr
  clr.AddReference('ProtoGeometry')
  from Autodesk.DesignScript.Geometry import *
  
  # DEFINE PARAMETER INPUTS
  surfIn = IN[0]
  maxSteps = IN[1]

• Funzioni:

  Copy

  def get_step_size():
    area = surfIn.Area
    stepSize = math.sqrt(area)/100
    return stepSize
  
  stepSize = get_step_size()

• Classi:

  Copy

  class MyClass:
    i = 12345
  
    def f(self):
      return 'hello world'
  
  numbers = MyClass.i
  greeting = MyClass.f

Flessibilità continua

Durante lo sviluppo di script di testo in Dynamo, è opportuno assicurarsi costantemente che ciò che viene creato sia allineato con quello che si prevede. Ciò garantirà che eventi imprevisti, come errori di sintassi, discrepanze logiche, imprecisioni di valore, risultati anomali e così via, vengano rapidamente scoperti e affrontati quando si presentano piuttosto che tutti contemporaneamente alla fine. Poiché gli script di testo sono presenti all'interno dei nodi dell'area di disegno, sono già integrati nel flusso di dati del programma visivo. In questo modo, il monitoraggio consecutivo dello script sarà semplice quanto l'assegnazione di dati di output, l'esecuzione del programma e la valutazione del flusso di dati dello script utilizzando un nodo Watch. Di seguito sono riportati alcuni suggerimenti per un'ispezione continua degli script durante la loro costruzione.

Fare delle prove mentre si procede:

• Ogni volta che si completa un cluster di funzionalità:

  • Tornare indietro e ispezionare il codice.

  • Essere critici. Un collaboratore potrebbe capire cosa sta facendo? Occorre farlo? Questa funzione può essere eseguita in modo più efficiente? Si stanno creando dipendenze o duplicati non necessari?

  • Fare rapidamente delle prove per assicurarsi che restituisca dati "appropriati".

• Assegnare come output i dati più recenti che si stanno utilizzando nello script, in modo che il nodo generi sempre dati pertinenti quando lo script viene aggiornato:

1. Verificare che tutti i bordi del solido vengano restituiti come curve per creare un riquadro di delimitazione attorno.

2. Verificare che gli input del conteggio siano stati convertiti correttamente in intervalli.

3. Verificare che i sistemi di coordinate siano stati correttamente convertiti e ruotati in questo loop.

Prevedere "casi limite":

• Durante lo scripting, aumentare i parametri di input ai valori minimo e massimo del relativo dominio assegnato per verificare se il programma funziona ancora in condizioni estreme.

• Anche se il programma funziona in condizioni estreme, verificare se restituisce valori nulli/vuoti/zero indesiderati.

• Talvolta, i bug e gli errori che evidenziano un problema di base relativo allo script compariranno solo durante questi casi limite.

  • Comprendere la causa dell'errore, quindi decidere se deve essere corretto internamente o se è necessario ridefinire un dominio dei parametri per evitare il problema.

Debug efficiente

Il debug è il processo di eliminazione dei "bug" dallo script. I bug possono essere errori, inefficienze, imprecisioni o eventuali risultati imprevisti. La risoluzione di un bug può essere semplice quanto la correzione di errori di ortografia nel nome di una variabile fino a problemi strutturali più diffusi con lo script. Idealmente, la flessibilità dello script durante la compilazione consentirà di individuare i potenziali problemi in anticipo, anche se non vi è garanzia che sia privo di bug. Di seguito è riportato un riepilogo delle diverse procedure ottimali descritte sopra per aiutare a risolvere i bug in modo sistematico.

Utilizzare il simbolo circolare di controllo:

• Verificare i dati restituiti in posizioni diverse nel codice assegnandoli alla variabile OUT, in modo simile al concetto di flessibilità del programma.

Scrivere commenti significativi:

• Se l'esito previsto è chiaramente descritto, sarà più semplice eseguire il debug di un modulo di codice.

# Loop through X and Y
for i in range(xCount):
  for j in range(yCount):

    # Rotate and translate the coordinate system
    toCoord = fromCoord.Rotate(solid.ContextCoordinateSystem.Origin,Vector.ByCoordinates(0,0,1),(90*(i+j%seed)))
    vec = Vector.ByCoordinates((xDist*i),(yDist*j),0)
    toCoord = toCoord.Translate(vec)

    # Transform the solid from the source coord system to the target coord system and append to the list
    solids.append(solid.Transform(fromCoord,toCoord))

In genere, si tratta di una quantità eccessiva di commenti e righe vuote, ma quando si esegue il debug può essere utile suddividere i dati in parti gestibili.

Sfruttare la modularità del codice:

• L'origine di un problema può essere isolata in determinati moduli.

• Una volta identificato il modulo difettoso, correggere il problema è notevolmente più semplice.

• Quando un programma deve essere modificato, il codice sviluppato in moduli sarà molto più facile da modificare:

  • È possibile inserire moduli nuovi o sottoposti al debug in un programma esistente con la certezza che il resto del programma non cambierà.

Debug del file di esempio del nodo Python.

1. La geometria di input restituisce un riquadro di delimitazione di dimensioni maggiori, come si può vedere dall'assegnazione di xDist e yDist ad OUT.

2. Le curve dei bordi della geometria di input restituiscono un riquadro di delimitazione appropriato con le distanze corrette per xDist e yDist.

3. Il "modulo" del codice inserito per risolvere il problema relativo ai valori xDist e yDist.

Esercizio: Percorso più ripido

Scaricare il file di esempio facendo clic sul collegamento seguente.

Un elenco completo di file di esempio è disponibile nell'Appendice.

Tenendo a mente le procedure ottimali per lo scripting di testo, si scrive uno script di simulazione della pioggia. Sebbene sia stato possibile applicare le procedure ottimali ad un programma visivo disorganizzato in Strategie sui grafici, è molto più difficile farlo con lo scripting di testo. Le relazioni logiche definite nello scripting di testo sono meno visibili e sono quasi impossibile da distinguere in un codice caotico. La potenza dello scripting di testo comporta una responsabilità più grande nell'organizzazione. Si esaminerà ogni passaggio e si applicheranno le pratiche ottimali lungo il percorso.

Lo script è stato applicato ad una superficie deformata dall'attrattore.

La prima cosa da fare è importare le librerie di Dynamo necessarie. Questa prima operazione garantirà l'accesso globale alle funzionalità di Dynamo in Python.

Tutte le librerie che si intende utilizzare devono essere importate qui.

Successivamente dobbiamo definire gli input e l'output dello script, che verranno visualizzati come porte di input sul nodo. Questi input esterni sono la base dello script e la chiave per stabilire un ambiente parametrico.

È necessario definire input corrispondenti alle variabili nello script Python e determinare l'output desiderato:

1. La superficie che si intende percorrere.

2. Il numero di agenti che si desidera far camminare.

3. Il numero massimo di passi che gli agenti possono fare.

4. Un'opzione che consente di fare il percorso più breve lungo la superficie o di attraversarla.

5. Il nodo Python con identificatori di input corrispondenti agli input nello script (IN[0], IN[1]).

6. Le curve di output che possono essere visualizzate con un colore diverso.

Ora, si applicherà la pratica della modularità e verrà creato il corpo dello script. La simulazione del percorso più breve lungo una superficie per più punti iniziali è un'attività significativa che richiede diverse funzioni. Invece di chiamare le diverse funzioni in tutto lo script, è possibile modularizzare il codice raccogliendole in un'unica classe, l'agente. Le diverse funzioni di questa classe o di questo "modulo" possono essere chiamate con variabili differenti o persino riutilizzate in un altro script.

Occorre definire una classe, o cianografia, per un agente con l'intenzione di percorrere una superficie scegliendo di viaggiare nella direzione più ripida possibile ogni volta che fa un passo:

1. Nome.

2. Attributi globali condivisi da tutti gli agenti.

3. Attributi di istanza univoci per ogni agente.

4. Una funzione per fare un passo.

5. Una funzione per la catalogazione della posizione di ciascun passo in un elenco di tracce.

Si inizializzano gli agenti definendo la loro posizione iniziale. Questa è un'ottima opportunità per adattare lo script e verificare che la classe degli agenti funzioni.

Occorre creare un'istanza di tutti gli agenti che si desidera osservare percorrere la superficie e definire i loro attributi iniziali:

1. Un nuovo elenco di tracce vuoto.

2. Dove inizieranno il loro viaggio sulla superficie.

3. È stato assegnato l'elenco degli agenti come output per verificare che lo script venga restituito qui. Viene restituito il numero corretto di agenti, ma sarà necessario adattare nuovamente lo script in un secondo momento per verificare la geometria che restituisce.

Aggiornare ogni agente ad ogni passo. Sarà quindi necessario immettere un loop nidificato where per ogni agente e per ogni passo, quindi aggiornare e registrare la loro posizione nell'elenco delle loro tracce. Ad ogni passo, occorre assicurarsi inoltre che l'agente non abbia raggiunto un punto sulla superficie dove non può fare un altro passo che gli consenta la discesa. Se questa condizione è soddisfatta, finirà il viaggio dell'agente.

Ora che i nostri agenti sono stati completamente aggiornati, si può tornare alla geometria che li rappresenta. Dopo che tutti gli agenti hanno raggiunto il loro limite di discesa o il loro numero massimo di passi, verrà creata una PolyCurve attraverso i punti nell'elenco delle loro tracce e verranno generate le tracce di PolyCurve.

Lo script per trovare i percorsi più ripidi.

1. Una preimpostazione che simula la pioggia sulla superficie sottostante.

2. Anziché trovare il percorso più ripido, gli agenti possono essere attivati per attraversare la superficie sottostante.

Lo script di testo di Python completo.

### STEEPEST PATH ALGORITHM

# IMPORT LIBRARIES
import sys
sys.path.append('C:\Program Files (x86)\IronPython 2.7\Lib')
import random
import math
import clr
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *

# DEFINE PARAMETER INPUTS
surfIn = IN[0]
numAgents = IN[1]
maxSteps = IN[2]
decendBoo = IN[3]


# DEFINE AGENT CLASS
class Agent(object):
    def get_step_size():
        area = surfIn.Area
        stepSize = math.sqrt(area)/100
        return stepSize

    zVec = Vector.ZAxis()
    stepSize = get_step_size()
    dupTol = 0.001


    def __init__(self,u,v):
        self.endBoo = False
        self.U = u
        self.V = v
        self.Z = None
        self.trailPts = []
        self.update_trail()

    def update(self):
        if not self.endBoo:
            positionPt01 = self.trailPts[-1]
            normalVec = surfIn.NormalAtParameter(self.U,self.V)
            gradientVec = Vector.Cross(self.zVec, normalVec)
            if decendBoo:
            	gradientVec = gradientVec.Rotate(normalVec,-90)

            gradientVec = gradientVec.Normalized()
            gradientVec = gradientVec.Scale(self.stepSize)
            positionPt02 = positionPt01.Add(gradientVec)
            newPt = surfIn.ClosestPointTo(positionPt02)
            newUV = surfIn.UVParameterAtPoint(newPt)
            newU, newV = newUV.U, newUV.V
            newZ = newPt.Z

            if decendBoo and (self.Z <= newZ):
            	self.endBoo = True
            else:
	            if ((abs(self.U-newU) <= self.dupTol) and (abs(self.V-newV) <= self.dupTol)):
	                self.endBoo = True
	            else:
	                self.U, self.V = newU, newV
	                self.update_trail()

    def update_trail(self):
        trailPt = surfIn.PointAtParameter(self.U,self.V)
        self.trailPts.append(trailPt)
        self.Z = trailPt.Z


# INITIALIZE AGENTS
agents = []
for i in range(numAgents):
	u = float(random.randrange(1000))/1000
	v = float(random.randrange(1000))/1000
	agent = Agent(u,v)
	agents.append(agent)


# UPDATE AGENTS
for i in range(maxSteps):
	for eachAgent in agents:
		eachAgent.update()

# DRAW TRAILS
trails = []
for eachAgent in agents:
	trailPts = eachAgent.trailPts
	if (len(trailPts) > 1):
		trail = PolyCurve.ByPoints(trailPts)
		trails.append(trail)

# OUTPUT TRAILS
OUT = trails