El bloque de código es una función exclusiva de Dynamo que vincula dinámicamente un entorno de programación visual con uno basado en texto. El bloque de código tiene acceso a todos los nodos de Dynamo y puede definir un gráfico completo en un nodo. Lea este capítulo detenidamente, ya que el bloque de código es un elemento fundamental de Dynamo.

Dynamo es un excelente punto de partida para empezar a codificar en el mundo AEC. Puede que le interesen algunas de estas secciones para iniciar su recorrido por la codificación:

• Bloques de código y DesignScript

• Geometría con DesignScript

• Python

En esta sección, encontrará una serie de lecciones sobre la creación de geometría con DesignScript. Para continuar, copie el contenido de DesignScript de ejemplo en bloques de código de Dynamo.

// copy this code into a Code Block
// to start writing DesignScript

x = "Let's create some geometry!";

​Python es un lenguaje de programación muy utilizado cuya popularidad tiene mucho que ver con su estilo de sintaxis. Es altamente legible, lo que hace que su aprendizaje sea más sencillo que el de muchos otros idiomas. Python admite módulos y paquetes, y se puede incrustar en aplicaciones existentes. Para obtener información sobre cómo empezar a trabajar con Python, un buen recurso es la página "Getting Started" (Guía de introducción) de Python.org.

Los bloques de código son una ventana a DesignScript, el lenguaje de programación que es la base de Dynamo. Creado desde cero para admitir flujos de trabajo de diseño exploratorios, DesignScript es un lenguaje legible y conciso que ofrece información inmediata a pequeños fragmentos de código y también se adapta a interacciones grandes y complejas. DesignScript también forma la columna vertebral del motor que impulsa la mayoría de los aspectos subyacentes de Dynamo. Como casi todas las funciones de los nodos y las interacciones de Dynamo tienen una relación de uno a uno con el lenguaje de creación de secuencias de comandos, se ofrecen oportunidades únicas de desplazarse entre secuencias de comandos e interacciones basadas en nodos de forma fluida.

Para los principiantes, los nodos se pueden convertir automáticamente en sintaxis de texto para facilitar el aprendizaje de DesignScript o para reducir el tamaño de secciones de gráficos de mayor tamaño. Esto se realiza mediante un proceso denominado "de nodo a código", que se describe con más detalle en la sección . Los usuarios con más experiencia pueden utilizar bloques de código para crear combinaciones personalizadas de funciones existentes y relaciones creadas por el usuario mediante una gran cantidad de paradigmas de codificación estándar. En un nivel intermedio entre los principiantes y los usuarios avanzados, hay disponibles un gran número de accesos directos y fragmentos de código que agilizarán los diseños. Si bien el término "bloque de código" puede intimidar un poco a los que no son programadores, es una herramienta eficaz y fácil de usar. Un principiante puede utilizar de forma eficaz el bloque de código con una mínima creación de código y un usuario avanzado puede establecer definiciones de secuencias de comandos que se pueden recuperar en cualquier parte de una definición de Dynamo.

Los métodos Intersect, Trim y SelectTrim se utilizan principalmente en geometrías dimensionales inferiores como puntos, curvas y superficies. Por otra parte, la geometría sólida cuenta con un conjunto adicional de métodos para modificar la forma después de su creación, tanto sustrayendo material de forma similar a Trim como combinando elementos para formar un todo mayor.

Unión

El método Union utiliza dos objetos sólidos para crear un único objeto sólido a partir del espacio cubierto por ambos objetos. El espacio solapado entre los objetos se combina en la forma final. Este ejemplo combina una esfera y un cubo en una forma de esfera-cubo sólida:

Las siguientes secuencias de comandos de Python generan matrices de puntos para varios ejemplos. Se deben pegar en un nodo Python Script, como se indica a continuación:

python_points_1

out_points = []

for i in range(11):
	sub_points = []
	for j in range(11):
		z = 0
		if (i == 5 and j == 5):
			z = 1
		elif (i == 8 and j == 2):
			z = 1
		sub_points.append(Point.ByCoordinates(i, j, z))
	out_points.append(sub_points)

OUT = out_points

python_points_2

out_points = []

for i in range(11):
	z = 0
	if (i == 2):
		z = 1
	out_points.append(Point.ByCoordinates(i, 0, z))

OUT = out_points

python_points_3

out_points = []

for i in range(11):
	z = 0
	if (i == 7):
		z = -1
	out_points.append(Point.ByCoordinates(i, 5, z))

OUT = out_points

python_points_4

python_points_5

Punto

El objeto geométrico más sencillo de la biblioteca de geometría estándar de Dynamo es un punto. Toda la geometría se crea mediante funciones especiales denominadas constructores, que devuelven un nuevo ejemplar de ese tipo de geometría específico. En Dynamo, los constructores empiezan por el nombre del tipo de objeto, en este caso, "Point", seguido del método de construcción. Para crear un punto tridimensional especificado con las coordenadas cartesianas X, Y y Z, utilice el constructor ByCoordinates:

Los constructores de Dynamo se designan normalmente con el prefijo By y, al invocar estas funciones, se devuelve un objeto recién creado de ese tipo. Este objeto recién creado se almacena en la variable designada a la izquierda del signo igual.

Los objetos de los diseños computacionales rara vez se crean explícitamente en su posición y forma finales y, con mayor frecuencia, se convierten, se giran y se colocan de cualquier otro modo a partir de la geometría existente. Las matemáticas vectoriales sirven como una especie de andamiaje geométrico para proporcionar dirección y orientación a la geometría, así como para conceptualizar movimientos a través del espacio 3D sin representación visual.

Como elemento más básico, un vector representa una posición en el espacio 3D y a menudo se considera el punto final de una flecha desde la posición (0, 0, 0) hasta esa posición. Los vectores se pueden crear con el constructor ByCoordinates utilizando la posición X, Y y Z del objeto vectorial que se acaba de crear. Observe que los objetos vectoriales no son objetos geométricos y no aparecen en la ventana de Dynamo. Sin embargo, la información sobre un vector recién creado o modificado se puede imprimir en la ventana de la consola:

Un conjunto de operaciones matemáticas se define en objetos vectoriales, lo que permite sumar, restar, multiplicar y, en general, desplazar objetos en un espacio 3D, tal y como desplazaría números reales en un espacio unidimensional en una línea numérica.

En los diseños computacionales, las curvas y las superficies se utilizan con frecuencia como el andamiaje subyacente para crear la geometría posterior. Para que esta geometría inicial se pueda utilizar como base para la geometría posterior, la secuencia de comandos debe poder extraer cualidades como, por ejemplo, la posición y la orientación en toda el área del objeto. Tanto las curvas como las superficies admiten esta extracción y este proceso se denomina parametrización.

Todos los puntos de una curva se pueden considerar como si tuvieran un parámetro único que oscila entre 0 y 1. Si creáramos una NurbsCurve a partir de varios puntos de control o interpolación, el primer punto tendría el parámetro 0 y el último, el parámetro 1. Es imposible saber por adelantado cuál es el parámetro exacto para cualquier punto intermedio, lo que puede parecer una limitación grave, aunque se mitiga mediante una serie de funciones de utilidad. Las superficies tienen una parametrización similar a la de las curvas, aunque con dos parámetros en lugar de uno, denominados u y v. Si creáramos una superficie con los siguientes puntos:

p1 tendría el parámetro u = 0 v = 0, mientras que p9 tendría los parámetros u = 1 v = 1.

La parametrización no resulta especialmente útil a la hora de determinar los puntos utilizados para generar curvas. Su principal finalidad es determinar las ubicaciones si se utilizan los puntos intermedios generados por los constructores NurbsCurve y NurbsSurface.

Las curvas presentan el método PointAtParameter, que utiliza un único argumento doble entre 0 y 1, y devuelve el objeto de punto en ese parámetro. Por ejemplo, esta secuencia de comandos busca los puntos en los parámetros 0, 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9 y 1:

El componente análogo bidimensional a una NurbsCurve es la NurbsSurface y, al igual que la NurbsCurve de forma libre, las NurbsSurfaces se pueden crear con dos métodos básicos: la introducción de un conjunto de puntos base y la interpolación entre ellos por parte de Dynamo, y la especificación explícita de los puntos de control de la superficie. Al igual que las curvas de forma libre, las superficies interpoladas son útiles cuando un diseñador conoce con precisión la forma que debe adoptar una superficie o si un diseño requiere que la superficie pase por los puntos de restricción. Por otra parte, las superficies creadas mediante puntos de control pueden ser más útiles para los diseños exploratorios a través de varios niveles de suavizado.

Superficie interpolada

Para crear una superficie interpolada, simplemente genere una colección bidimensional de puntos que se aproxime a la forma de una superficie. La colección debe ser rectangular, es decir, no irregular. El método NurbsSurface.ByPoints crea una superficie a partir de estos puntos.

CoordinateSystem

Aunque Dynamo puede crear diversas formas geométricas complejas, las primitivas geométricas simples forman la espina dorsal de cualquier diseño computacional: expresadas directamente en la forma diseñada final o utilizadas como andamiaje a partir del que se genera geometría más compleja.

Aunque no es estrictamente una parte de la geometría, CoordinateSystem es una herramienta importante para crear geometría. Un objeto CoordinateSystem realiza un seguimiento de las transformaciones geométricas y de posición, como la rotación, el corte y la escala.

Para crear un CoordinateSystem centrado en un punto con x = 0, y = 0 y z = 0 sin transformaciones de rotación, escala o corte, basta con llamar al constructor Identity:

Los objetos CoordinateSystem con transformaciones geométricas se encuentran fuera del ámbito de este capítulo, aunque otro constructor permite crear un sistema de coordenadas en un punto específico, CoordinateSystem.ByOriginVectors:

Punto

La primitiva geométrica más sencilla es un punto, que representa una ubicación de cero dimensiones en un espacio tridimensional. Como se ha mencionado anteriormente, existen varias formas diferentes de crear un punto en un sistema de coordenadas específico: Point.ByCoordinates crea un punto con las coordenadas X, Y y Z especificadas; Point.ByCartesianCoordinates crea un punto con las coordenadas X, Y y Z especificadas en un determinado sistema de coordenadas; Point.ByCylindricalCoordinates crea un punto en un cilindro con un radio, un ángulo de rotación y una altura, y Point.BySphericalCoordinates crea un punto en una esfera con un radio y dos ángulos de rotación.

En este ejemplo, se muestran puntos creados en varios sistemas de coordenadas:

Línea

La siguiente primitiva de Dynamo dimensional superior es un segmento de línea, que representa un número infinito de puntos entre dos puntos finales. Las líneas se pueden crear indicando explícitamente los dos puntos de contorno con el constructor Line.ByStartPointEndPoint o especificando un punto inicial, una dirección y una longitud en esa dirección, Line.ByStartPointDirectionLength.

Primitivas 3D: cubo, cono, cilindro, esfera, etc.

Dynamo tiene objetos que representan los tipos más básicos de primitivas geométricas en tres dimensiones: cubos, creados con Cuboid.ByLengths; conos, creados con Cone.ByPointsRadius y Cone.ByPointsRadii; cilindros, creados con Cylinder.ByRadiusHeight, y esferas, creadas con Sphere.ByCenterPointRadius.

Con Dynamo 2.0, podemos especificar una plantilla por defecto (.py extension) para utilizarla al abrir la ventana de Python por primera vez. Esta ha sido una petición deseada durante mucho tiempo, ya que agiliza el uso de Python en Dynamo. La capacidad de utilizar una plantilla nos permite disponer de importaciones por defecto listas para usar cuando deseamos desarrollar una secuencia de comandos de Python personalizada.

Esta plantilla se encuentra en la ubicación APPDATA de la instalación de Dynamo.

Por lo general, suele ser ( %appdata%\Dynamo\Dynamo Core\{version}\ ).

Configuración de la plantilla

Para utilizar esta función, debemos añadir la siguiente línea en el archivo DynamoSettings.xml. (Edítelo en el Bloc de notas).

Cuando aparece <PythonTemplateFilePath />, solo tenemos que sustituir esto por lo siguiente:

A continuación, debemos crear una plantilla con la funcionalidad integrada que deseamos utilizar. En este caso, insertaremos las importaciones relacionadas con Revit y algunos de los demás elementos habituales al trabajar con Revit.

Puede iniciar un documento del Bloc de notas en blanco y pegar el siguiente código:

Una vez hecho esto, guarde este archivo como PythonTemplate.py en la ubicación APPDATA.

Comportamiento posterior de la secuencia de comandos de Python

Una vez que se haya definido la plantilla de Python, Dynamo la buscará cada vez que se coloque un nodo de Python. Si no se encuentra, se mostrará la ventana de Python por defecto.

Si se encuentra la plantilla de Python (como, por ejemplo, nuestra plantilla de Revit), aparecerán todos los elementos por defecto integrados.

Aquí encontrará información adicional (de Radu Gidei) sobre esta excelente incorporación. https://github.com/DynamoDS/Dynamo/pull/8122

Existen dos formas fundamentales de crear curvas de forma libre en Dynamo: especificar una colección de puntos y conseguir que Dynamo interpole una curva suavizada entre ellos, o un método de nivel más bajo mediante la especificación de los puntos de control subyacentes de una curva de un determinado grado. Las curvas interpoladas son útiles cuando un diseñador conoce exactamente la forma que debe adoptar una línea o si el diseño tiene restricciones específicas en cuanto a la ubicación que la curva puede o no atravesar. Las curvas especificadas mediante puntos de control son, en esencia, una serie de segmentos de línea recta que un algoritmo suaviza para formar una curva final. La especificación de una curva mediante puntos de control puede resultar útil para explorar formas de curva con diferentes grados de suavizado o cuando se requiere una continuidad suave entre segmentos de curva.

Curva interpolada

Para crear una curva interpolada, simplemente transfiera un conjunto de puntos al método NurbsCurve.ByPoints.

Muchos de los ejemplos mostrados hasta ahora se han centrado en la creación de geometría dimensional superior a partir de objetos dimensionales inferiores. Los métodos de intersección permiten que esta geometría dimensional superior genere objetos dimensionales inferiores, mientras que los comandos de recorte y de selección de recorte permiten que el archivo de comandos modifique las formas geométricas una vez creadas.

El método Intersect se define en todas las partes de la geometría de Dynamo, lo que significa que, en teoría, cualquier elemento de geometría se puede intersecar con cualquier otro. Naturalmente, algunas intersecciones no tienen sentido, como las intersecciones que involucran puntos, ya que el objeto resultante siempre será el propio punto de entrada. Las demás combinaciones posibles de intersecciones entre objetos se describen en el siguiente gráfico. En la siguiente tabla, se muestra el resultado de varias operaciones de intersección:

Intersecar

En el siguiente ejemplo muy sencillo, se muestra la intersección de un plano con una NurbsSurface. La intersección genera una matriz de NurbsCurves, que se puede utilizar como cualquier otra NurbsCurve.

El método Trim es muy similar al método Intersect, ya que se define para casi cada elemento de geometría. Sin embargo, existen muchas más limitaciones en el método Trim que en Intersect.

Recortar

Algo que se debe tener en cuenta en los métodos Trim es el requisito de un punto de "selección", un punto que determina la geometría que se descartará y las partes que se deben conservar. Dynamo busca y descarta la geometría recortada más cercana al punto de selección.

Algunos objetos de geometría se pueden crear indicando de forma explícita las coordenadas X, Y y Z en un espacio tridimensional. Sin embargo, con mayor frecuencia, la geometría se desplaza a su posición final mediante transformaciones geométricas en el propio objeto o en su CoordinateSystem subyacente.

Traducción

La transformación geométrica más sencilla es una traslación, que desplaza un objeto un número determinado de unidades en las direcciones X, Y y Z.

Rotación

Aunque todos los objetos de Dynamo se pueden trasladar mediante la adición del método .Translate al final del nombre del objeto, las transformaciones más complejas requieren transformar el objeto de un CoordinateSystem subyacente a un nuevo CoordinateSystem. Por ejemplo, para girar un objeto 45 grados alrededor del eje X, debemos transformar el objeto de su CoordinateSystem existente sin rotación a un CoordinateSystem que se había girado 45 grados alrededor del eje X con el método .Transform:

Escala

Además de trasladarse y rotarse, los objetos CoordinateSystem también se pueden crear cortados o con su escala ajustada. Se puede ajustar la escala de un CoordinateSystem con el método .Scale:

Los objetos CoordinateSystem cortados se crean mediante la introducción de vectores no ortogonales en el constructor CoordinateSystem.

La escala y el corte son transformaciones geométricas más complejas que la rotación y la traslación, por lo que no todos los objetos de Dynamo pueden someterse a ellas. En la siguiente tabla, se describen los objetos de Dynamo que pueden tener objetos CoordinateSystem con escala no uniforme y cortados.

Las funciones se pueden crear en un bloque de código y recuperar en cualquier parte de una definición de Dynamo. Esto crea otra capa de control en un archivo paramétrico y se puede ver como una versión de texto de un nodo personalizado. En este caso, se puede acceder fácilmente al bloque de código "principal", que se encuentra en cualquier parte del gráfico. No se necesitan cables.

Elemento principal

En la primera línea, aparece la palabra clave "def", después el nombre de la función y, a continuación, los nombres de las entradas entre paréntesis. Las llaves definen el cuerpo de la función. Se devuelve un valor con "return =". Los bloques de código que definen una función no tienen puertos de entrada o salida porque se invocan desde otros bloques de código.

Abreviatura

Existen varios métodos básicos de abreviatura en el bloque de código que, sencillamente, facilitan mucho la administración de datos. A continuación, vamos a desglosar los conceptos básicos y analizar cómo se puede utilizar la abreviatura para crear y consultar datos.

Sintaxis adicional

Rangos y secuencias

El método para definir rangos y secuencias se puede reducir a un método básico de abreviatura. Utilice la imagen siguiente como guía de la sintaxis "..." para definir una lista de datos numéricos con un bloque de código. Una vez que aprendemos a utilizar esta notación, crear datos numéricos es un proceso realmente eficaz:

1. En este ejemplo, un rango de números se sustituye por una sintaxis de bloque de código que define beginning..end..step-size;. Representados numéricamente, obtenemos lo siguiente: 0..10..1;.

2. Observe que la sintaxis 0..10..1; es equivalente a 0..10;. Un tamaño de paso de 1 es el valor por defecto de la notación de abreviatura. Por lo tanto, 0..10; proporciona una secuencia de 0 a 10 con un tamaño de paso de 1.

Rangos avanzados

La creación de rangos avanzados nos permite trabajar con listas de listas de una forma sencilla. En los ejemplos siguientes, se aísla una variable de la notación de rango principal y se crea otro rango de dicha lista.

1. Mediante la creación de rangos anidados, compare la notación con el símbolo "#" frente a la notación sin este símbolo. Se aplica la misma lógica que en los rangos básicos, pero se vuelve un poco más compleja.

2. Podemos definir un subrango en cualquier lugar dentro del rango principal; observe que también podemos tener dos subrangos.

3. Al controlar el valor "fin" de un rango, se crean más rangos de longitudes diferentes.

Como ejercicio lógico, compare las dos abreviaturas anteriores e intente analizar el modo en que los subrangos y la notación # controlan la salida.

Crear listas y obtener elementos de una lista

Además de crear listas con la función de abreviatura, también podemos crear listas sobre la marcha. Estas listas pueden contener una amplia gama de tipos de elementos y también se pueden consultar (recuerde que las listas son objetos en sí mismas). En resumen, con el bloque de código se crean listas y se consultan los elementos de una lista con corchetes.

1. Cree listas rápidamente con cadenas y consulte las listas mediante el índice de elementos.

2. Cree listas con variables y realice consultas mediante la notación de abreviatura de rango.

Además, el proceso de gestión con listas anidadas es similar. Tenga en cuenta el orden de la lista y recuerde utilizar varios conjuntos de corchetes:

1. Defina una lista de listas.

2. Consulte una lista con notación de un solo corchete.

3. Consulte un elemento con notación de doble corchete.

Ejercicio: superficie sinusoidal

Descargue el archivo de ejemplo. Para ello, haga clic en el vínculo siguiente.

En el Apéndice, se incluye una lista completa de los archivos de ejemplo.

En este ejercicio, vamos a poner en práctica nuestras nuevas habilidades de abreviación para crear una superficie de cáscaras de huevo con mucho estilo y definida por rangos y fórmulas. A lo largo de este ejercicio, observe cómo utilizamos el bloque de código y los nodos existentes en Dynamo en tándem: se utiliza el bloque de código para la elevación de datos pesados mientras que los nodos de Dynamo se disponen visualmente para determinar la legibilidad de la definición.

Comience por crear una superficie conectando los nodos anteriores. En lugar de utilizar un nodo numérico para definir la anchura y la longitud, haga doble clic en el lienzo y escriba 100; en un bloque de código.

1. Defina un rango entre 0 y 1 con 50 divisiones. Para ello, escriba 0..1..#50 en un bloque de código.

2. Conecte el rango en Surface.PointAtParameter, que toma los valores u y v entre 0 y 1 a lo largo de la superficie. No olvide cambiar el encaje a Producto vectorial. Para ello, haga clic con el botón derecho en el nodo Surface.PointAtParameter.

En este paso, utilizamos nuestra primera función para mover la rejilla de puntos hacia arriba en el eje Z. Esta rejilla controlará una superficie generada a partir de la función subyacente. Añada nuevos nodos, como se muestra en la imagen siguiente.

1. Utilizamos un bloque de código con la línea: (0..Math.Sin(x*360)..#50)*5;. Para descomponerlo rápidamente, vamos a definir un rango con una fórmula dentro de él. Esta fórmula es la función de seno. La función de seno recibe entradas de grado en Dynamo, por lo que, para obtener una onda sinusoidal completa, multiplicamos los valores x (es decir, la entrada de rango de 0 a 1) por 360. A continuación, queremos que haya el mismo número de divisiones que de puntos de rejilla de control para cada fila, por lo que definimos cincuenta subdivisiones con #50. Por último, el multiplicador de 5 simplemente aumenta la amplitud de la traslación para que podamos ver el efecto en la vista preliminar de Dynamo.

1. Aunque el bloque de código anterior, no era totalmente paramétrico. Deseamos controlar sus parámetros de forma dinámica, por lo que reemplazaremos la línea del paso anterior por (0..Math.Sin(x*360*cycles)..#List.Count(x))*amp;. Esto nos permite definir estos valores en función de las entradas.

Al cambiar los controles deslizantes (de 0 a 10), obtenemos resultados interesantes.

1. Al realizar una transposición en el rango de números, se invierte la dirección de la onda cortina: transposeList = List.Transpose(sineList);.

1. Se obtiene una superficie de cáscara de huevo distorsionada al añadir los elementos sineList y transposeList: eggShellList = sineList+transposeList;.

Cambiemos los valores de los controles deslizantes especificados a continuación para "calmar las aguas" de este algoritmo.

Por último, vamos a consultar las partes aisladas de los datos con el bloque de código. Para regenerar la superficie con un rango específico de puntos, añada el bloque de código anterior entre los nodos Geometry.Translate y NurbsSurface.ByPoints. Tiene la siguiente línea de texto: sineStrips[0..15..1];. De este modo, se seleccionarán las primeras 16 filas de puntos (de 50). Al volver a crear la superficie, podemos ver que hemos generado una parte aislada de la rejilla de puntos.

1. En el paso final, para que este bloque de código sea más paramétrico, la consulta se controla mediante un control deslizante que va de 0 a 1. Para ello, utilizaremos esta línea de código: sineStrips[0..((List.Count(sineStrips)-1)*u)];. Esto puede resultar confuso, pero la línea de código nos proporciona una forma rápida de modificar la longitud de la lista con un multiplicador entre 0 y 1.

Un valor de 0.53 en el control deslizante crea una superficie justo después del punto medio de la rejilla.

Como se puede esperar, un control deslizante de 1 crea una superficie a partir de la rejilla completa de puntos.

En el gráfico visual, podemos resaltar los bloques de código y ver cada una de sus funciones.

1. El primer bloque de código sustituye al nodo Number.

2. El segundo bloque de código sustituye al nodo Number Range.

3. El tercer bloque de código sustituye a los nodos List.Transpose, List.Count y Number Range.

4. El cuatro bloque de código consulta una lista de listas y sustituye al nodo List.GetItemAtIndex.

Es posible que haya observado que en los nombres de los nodos de Dynamo se da un elemento común: cada nodo utiliza una sintaxis ".". Esto se debe a que el texto de la parte inicial de cada nodo representa la sintaxis real para las secuencias de comandos y "." (o notación de puntos) separa un elemento de los posibles métodos a los que es posible invocar. Esto permite traducir fácilmente las secuencias de comandos visuales a secuencias de comandos basadas en texto.

Como analogía general para la notación de puntos, ¿cómo podemos tratar una manzana paramétrica en Dynamo? A continuación se indican algunos métodos que ejecutaremos en la manzana antes de decidir consumirla. (Nota: estos no son métodos reales de Dynamo):

Python y Revit

Ahora que hemos mostrado cómo utilizar las secuencias de comandos de Python en Dynamo, vamos a echar un vistazo a la conexión de bibliotecas de Revit en el entorno de secuencias de comandos. Recuerde que hemos importado los nodos estándar de Python y nuestros nodos centrales de Dynamo con las tres primeras líneas del bloque de código mostrado a continuación. Para importar los nodos de Revit, los elementos de Revit y el administrador de documentos de Revit, solo hemos de añadir algunas líneas más:

Esto nos permite acceder a la API de Revit y disponer de secuencias de comandos personalizadas para cualquier tarea de Revit. La combinación del proceso de programación visual con las secuencias de comandos de la API de Revit, mejora significativamente la colaboración y el desarrollo de herramientas. Por ejemplo, un administrador de BIM y un diseñador de esquemas pueden trabajar juntos en el mismo gráfico. En esta colaboración, pueden mejorar el diseño y la ejecución del modelo.

API específicas de plataforma

El plan tras el proyecto de Dynamo es ampliar el alcance de la implementación de plataformas. A medida que Dynamo añada más programas a la lista, los usuarios obtendrán acceso a las API específicas de plataforma desde el entorno de secuencias de comandos de Python. Aunque Revit representa el caso real de esta sección, podemos prever más capítulos en el futuro que ofrecerán módulos de aprendizaje completos sobre secuencias de comandos en otras plataformas. Además, hay muchas bibliotecas de a las que se puede acceder ahora y que se pueden importar a Dynamo.

En los siguientes ejemplos, se muestran métodos para implementar operaciones específicas de Revit desde Dynamo mediante el uso de Python. Para obtener una descripción más detallada de la relación de Python con Dynamo y Revit, consulte la . Otro recurso útil para Python y Revit es el proyecto .

Ejercicio 1

Cree un nuevo proyecto de Revit.

Descargue el archivo de ejemplo. Para ello, haga clic en el vínculo siguiente.

En el Apéndice, se incluye una lista completa de los archivos de ejemplo.

En estos ejercicios, vamos a explorar secuencias de comandos básicas de Python en Dynamo for Revit. El ejercicio se centrará en el uso de los archivos y elementos de Revit, así como en la comunicación entre Revit y Dynamo.

Este es un método sencillo para recuperar los elementos doc, uiapp y app del archivo de Revit vinculado a la sesión de Dynamo. Es posible que los programadores que hayan trabajado antes en la API de Revit reconozcan los elementos de la lista de inspección. Si estos elementos no le resultan familiares, no hay problema; vamos a usar otros ejemplos en los ejercicios siguientes.

A continuación, se indica cómo vamos a importar los servicios de Revit y recuperar los datos del documento en Dynamo.

Eche un vistazo al nodo de Python en Dynamo. También puede encontrar el código a continuación:

Ejercicio 2

Descargue el archivo de ejemplo. Para ello, haga clic en el vínculo siguiente.

En el Apéndice, se incluye una lista completa de los archivos de ejemplo.

En este ejercicio, crearemos una curva de modelo simple en Revit mediante el nodo de Dynamo Python.

Empiece creando una nueva familia de masas conceptuales en Revit.

Abra la carpeta de masas conceptuales y utilice el archivo de plantilla Metric Mass.rft.

En Revit, utilice el método abreviado de teclado un para que se muestre la configuración de unidades del proyecto y cambie la unidad de longitud a metros.

Inicie Dynamo y cree el conjunto de nodos de la imagen siguiente. Crearemos primero dos puntos de referencia en Revit a partir de los nodos de Dynamo.

1. Cree un bloque de código y asígnele el valor "0;".

2. Conecte este valor a un nodo ReferencePoint.ByCoordinates para las entradas X, Y y Z.

3. Cree tres controles deslizantes que vayan de -100 a 100 con un tamaño de paso de 1.

Eche un vistazo al nodo de Python en Dynamo. A continuación, se muestra el código completo.

1. System.Array: Revit necesita una matriz del sistema como entrada (en lugar de una lista de Python). Esta es solo una línea de código más, pero prestar atención a los tipos de argumentos facilitará la programación de Python en Revit.

En Dynamo, hemos creado dos puntos de referencia con una línea que los conecta mediante Python. Vamos a ir un poco más lejos en el siguiente ejercicio.

Ejercicio 3

Descargue el archivo de ejemplo. Para ello, haga clic en el vínculo siguiente.

En el Apéndice, se incluye una lista completa de los archivos de ejemplo.

Este es un ejercicio sencillo, pero hace hincapié en la conexión de los datos y la geometría de Revit con Dynamo y viceversa. Comencemos abriendo Revit-StructuralFraming.rvt. Una vez abierto, inicie Dynamo y abra el archivo Revit-StructuralFraming.dyn.

Este archivo de Revit es totalmente básico. Dos curvas de referencia: una dibujada en el nivel 1 y la otra dibujada en el nivel 2. Queremos llevar estas curvas a Dynamo y mantener una conexión activa.

En este archivo, tenemos un conjunto de nodos conectados a cinco entradas de un nodo de Python.

1. Nodos Select Model Element: pulse el botón de selección para cada uno de ellos y seleccione la curva correspondiente en Revit.

2. Code Block: mediante la sintaxis 0..1..#x;, conecte un control deslizante de enteros que abarque de 0 a 20 en la entrada x. De este modo, se designa el número de vigas que se dibujarán entre las dos curvas.

3. Structural Framing Types: en el menú desplegable, elija la viga por defecto W12x26.

Este código de Python es un poco más denso, pero los comentarios del código describen lo que sucede en el proceso.

En Revit, tenemos una matriz de vigas que abarca las dos curvas como elementos estructurales. Nota: Este no es un ejemplo realista; los elementos estructurales se utilizan como ejemplo de ejemplares nativos de Revit creados a partir de Dynamo.

En Dynamo, también podemos ver los resultados. Las vigas del nodo Watch3D hacen referencia a la geometría consultada desde los elementos de Revit.

Observe que existe un proceso continuo de traslación de datos del entorno de Revit al entorno de Dynamo. En resumen, así es como se desarrolla el proceso:

1. Se selecciona el elemento de Revit.

2. Se convierte el elemento de Revit en curva de Dynamo.

3. Se divide la curva de Dynamo en una serie de puntos de Dynamo.

4. Se utilizan los puntos de Dynamo entre dos curvas para crear líneas de Dynamo.

Esto puede parecer un poco pesado, pero la secuencia de comandos hace que sea tan sencillo como editar la curva en Revit y volver a ejecutar el solucionador (aunque es posible que deba suprimir las vigas anteriores al hacerlo). Esto se debe al hecho de que hemos colocado vigas en Python, lo que rompe la asociación que tienen los nodos OOTB.

Con una actualización de las curvas de referencia de Revit, obtenemos una nueva matriz de vigas.

¿Por qué habría que utilizar la programación textual en el entorno de programación visual de Dynamo? La programación visual tiene muchas ventajas. Permite crear programas sin necesidad de aprender sintaxis especial en una interfaz visual intuitiva. Sin embargo, un programa visual se puede sobrecargar y, a veces, su funcionalidad puede ser reducida. Por ejemplo, Python ofrece métodos mucho más eficaces para escribir instrucciones condicionales (if/then) y bucles. Python es una potente herramienta que permite ampliar las funciones de Dynamo y reemplazar muchos nodos por unas pocas líneas de código concisas.

Programa visual:

Programa textual:

El nodo de Python

Al igual que los bloques de código, los nodos de Python son una interfaz de secuencias de comandos dentro de un entorno de programación visual. El nodo de Python se encuentra en la biblioteca, en Secuencias de comandos > Editor > Secuencia de comandos de Python.

Al hacer doble clic en el nodo, se abre el editor de secuencias de comandos de Python (también puede hacer clic con el botón derecho en el nodo y seleccionar Editar). Observará que aparece texto modelo en la parte superior como ayuda para hacer referencia a las bibliotecas necesarias. Las entradas se almacenan en la matriz IN. Los valores se devuelven a Dynamo asignándolos a la variable OUT.

La biblioteca Autodesk.DesignScript.Geometry permite utilizar la notación de puntos como ocurre con los bloques de código. Para obtener más información sobre la sintaxis de Dynamo, consulte y la (Para descargar este documento PDF, haga clic con el botón derecho en el vínculo y seleccione "Guardar vínculo como"). Al escribir un tipo de geometría como, por ejemplo, "Point.", se muestra una lista de métodos para crear y consultar puntos.

Los métodos incluyen constructores como ByCoordinates, acciones como Add y consultas como las coordenadas X, Y y Z.

Ejercicio: nodo personalizado con secuencia de comandos de Python para crear patrones a partir de un módulo sólido

Parte I: configurar la secuencia de comandos de Python

Descargue el archivo de ejemplo. Para ello, haga clic en el vínculo siguiente.

En el Apéndice, se incluye una lista completa de los archivos de ejemplo.

En este ejemplo, vamos a escribir una secuencia de comandos de Python que crea patrones a partir de un módulo sólido y lo vamos a convertir en un nodo personalizado. Vamos a crear primero nuestro módulo sólido mediante nodos de Dynamo.

1. Rectangle.ByWidthLength: cree un rectángulo que será la base del sólido.

2. Surface.ByPatch: conecte el rectángulo con la entrada "closedCurve" para crear la superficie inferior.

1. Geometry.Translate: conecte el rectángulo a la entrada "geometry" para desplazarlo hacia arriba y utilice un bloque de código para especificar el grosor de base del sólido.

2. Polygon.Points: consulte el rectángulo trasladado para extraer los puntos de esquina.

3. Geometry.Translate: utilice un bloque de código para crear una lista de cuatro valores correspondientes a los cuatro puntos y traslade una esquina del sólido hacia arriba.

Ahora que tenemos las superficies superior e inferior, solevaremos los dos perfiles para crear los lados del sólido.

1. List.Create: conecte el rectángulo inferior y el polígono superior a las entradas de índice.

2. Surface.ByLoft: soleve los dos perfiles para crear los lados del sólido.

3. List.Create: conecte las superficies superior, lateral e inferior a las entradas de índice para crear una lista de superficies.

Ahora que ya tenemos el sólido, soltaremos un nodo de secuencia de comandos de Python en el espacio de trabajo.

1. Para añadir entradas adicionales al nodo, haga clic en el icono + del nodo. Las entradas se denominan IN[0], IN[1] y así sucesivamente para indicar que representan elementos de una lista.

Empezaremos definiendo las entradas y la salida. Haga doble clic en el nodo para abrir el editor de Python. Siga el código mostrado a continuación para modificarlo en el editor.

Este código cobrará más sentido a medida que avancemos en el ejercicio. A continuación, debemos pensar en qué información se requiere para disponer la matriz de nuestro módulo sólido. En primer lugar, es necesario conocer las dimensiones del sólido para determinar la distancia de traslación. Debido a un error del cuadro delimitador, tendremos que utilizar la geometría de curva de borde para crear un cuadro delimitador.

Eche un vistazo al nodo de Python en Dynamo. Observe que estamos utilizando la misma sintaxis que vemos en los títulos de los nodos de Dynamo. Eche un vistazo al código comentado que aparece a continuación.

Ya que vamos a trasladar y girar los módulos sólidos, vamos a utilizar la operación Geometry.Transform. Al observar el nodo Geometry.Transform, vemos que vamos a necesitar un sistema de coordenadas de origen y un sistema de coordenadas de destino para transformar el sólido. El origen es el sistema de coordenadas de contexto del sólido, mientras que el destino será un sistema de coordenadas diferente para cada módulo de matriz. Esto significa que tendremos que crear un bucle a través de los valores de X e Y para transformar el sistema de coordenadas de forma diferente en cada caso.

Haga clic en Ejecutar y, a continuación, guarde el código. Conecte el nodo de Python con la secuencia de comandos existente como se indica a continuación.

1. Conecte la salida de Solid.ByJoinedSurfaces como la primera entrada para el nodo de Python y utilice un bloque de código para definir las demás entradas.

2. Cree un nodo Topology.Edges y utilice la salida del nodo de Python como entrada.

3. Por último, cree un nodo Edge.CurveGeometry y utilice la salida de Topology.Edges como entrada.

Pruebe a cambiar el valor de semilla para crear patrones diferentes. También puede cambiar los parámetros del módulo sólido para obtener distintos efectos.

Parte II: convertir el nodo de la secuencia de comandos de Python en un nodo personalizado

Ahora que hemos creado una secuencia de comandos de Python útil, vamos a guardarla como un nodo personalizado. Seleccione el nodo de la secuencia de comandos de Python, haga clic con el botón derecho en el espacio de trabajo y seleccione "Crear nodo personalizado".

Asigne un nombre, una descripción y una categoría.

Se abrirá un nuevo espacio de trabajo en el que se puede editar el nodo personalizado.

1. Inputs: cambie los nombres de las entradas para que sean más descriptivos y añada tipos de datos y valores por defecto.

2. Output: cambie el nodo de la salida.

Guarde el nodo como un archivo .dyf; debería ver que el nodo personalizado refleja los cambios que acabamos de realizar.

La sección Cambios en el lenguaje proporciona una descripción general de las actualizaciones y modificaciones realizadas en el lenguaje de Dynamo en cada versión. Estos cambios pueden afectar a la funcionalidad, el rendimiento y el uso, y esta guía ayudará a los usuarios a comprender cuándo y por qué adaptarse a estas actualizaciones.

Cambios en el lenguaje de Dynamo 2.0

1. Cambio en la sintaxis de list@level de "@-1" a "@L1"

• Nueva sintaxis de list@level para usar list@L1 en lugar de list@-1.

• Motivo: alinear la sintaxis del código con la vista previa y la interfaz de usuario; las pruebas de usuario muestran que esta nueva sintaxis es más comprensible.

1. Implementación de los tipos Int y Double en TS para que coincidan con los tipos de Dynamo

2. No se permiten las funciones sobrecargadas en las que los argumentos solo difieren por cardinalidad

• Los gráficos antiguos que utilizan sobrecargas que se han eliminado deben usar por defecto las sobrecargas de mayor rango.

• Motivo: eliminar la ambigüedad sobre qué función específica se está ejecutando.

1. Desactivación de la promoción de matriz con guías de replicación

2. Conversión de las variables de los bloques imperativos en locales al ámbito del bloque imperativo

• Los valores de variable definidos dentro de los bloques de código imperativo no se verán alterados por los cambios realizados dentro de los bloques imperativos que hacen referencia a ellos.

1. Conversión de las variables en inmutables para desactivar la actualización asociativa en los nodos de bloque de código

2. Compilación de todos los nodos de la interfaz de usuario en métodos estáticos

3. Admisión de sentencias de retorno sin asignación

• "=" no es necesario ni en definiciones de función ni en código imperativo.

1. Migración de los nombres de métodos antiguos en CBN

• Se ha cambiado el nombre de muchos nodos para mejorar la legibilidad y la ubicación en la interfaz de usuario del navegador de biblioteca.

1. Lista como limpieza de diccionario

Problemas conocidos:

• Los conflictos de espacio de nombres en los bloques imperativos provocan la aparición de puertos de entrada inesperados. Consulte el para obtener más información. Para evitar esto, defina la función fuera del bloque imperativo de la siguiente manera:

Explicación de los cambios en el lenguaje de Dynamo 2.0

Se han realizado varias mejoras en el lenguaje de la versión 2.0 de Dynamo. El principal motivo para hacerlo fue simplificar el lenguaje. Se ha hecho hincapié en hacer que DesignScript sea más comprensible y fácil de usar con el objetivo de hacerlo más eficaz y flexible y mejorar la comprensibilidad por parte del usuario final.

A continuación se muestra la lista de cambios de la versión 2.0 explicada:

• Sintaxis de List@Level simplificada

• Los métodos sobrecargados con parámetros que solo difieren por rango no son válidos

• Compilación de todos los nodos de la interfaz de usuario como métodos estáticos

• Desactivada la promoción a lista cuando se utiliza con guías de replicación/encaje

1. Sintaxis de list@level simplificada

Nueva sintaxis de list@level para usar list@L1 en lugar de list@-1

2. Las funciones sobrecargadas con parámetros que solo difieren por rango no son válidas

Las funciones sobrecargadas son problemáticas por varios motivos:

• Es posible que una función sobrecargada indicada por un nodo de interfaz de usuario en el gráfico no sea la misma sobrecarga que se ejecuta en tiempo de ejecución.

• La resolución del método es costosa y no funciona bien para funciones sobrecargadas.

• Es difícil comprender el comportamiento de replicación de funciones sobrecargadas.

Tomemos BoundingBox.ByGeometry como ejemplo (había dos funciones sobrecargadas en versiones anteriores de Dynamo); en un caso toma un argumento de un solo valor y en el otro toma una lista de geometrías como argumento:

Si el usuario coloca el primer nodo en el lienzo y conecta una lista de geometrías, espera que la replicación se active, pero esto nunca sucede porque se llamará a la segunda sobrecarga en tiempo de ejecución, como se muestra a continuación:

En la versión 2.0, no se permiten las funciones sobrecargadas que solo difieren en la cardinalidad de los parámetros por este motivo. Esto significa que, para las funciones sobrecargadas que tienen el mismo número y tipo de parámetros, pero que tienen uno o más parámetros que difieren solo en el rango, la sobrecarga que se define primero siempre se impone, mientras que el resto las descarta el compilador. La principal ventaja de realizar esta simplificación es la de simplificar la lógica de resolución del método al tener una ruta rápida para seleccionar las funciones candidatas.

En la biblioteca de geometría de la versión 2.0, la primera sobrecarga del ejemplo d BoundingBox.ByGeometry se retiró y la segunda se conservó, por lo que si el nodo estuviera destinado a replicarse, es decir, a usarse en el contexto de la primera, tendría que usarse con la opción de encaje más corta (o más larga), o en un bloque de código con guías de replicación:

Podemos ver en este ejemplo que el nodo de mayor rango se puede usar tanto en una llamada replicada como en una no replicada y, por lo tanto, siempre se prefiere a una sobrecarga de menor rango. Por lo tanto, como regla general, siempre se recomienda a los autores de nodos que descarten las sobrecargas de menor rango en favor de los métodos de mayor rango, de modo que el compilador de DesignScript siempre llame al método de mayor rango al ser el primero y único que encuentra.

Ejemplos:

En el ejemplo siguiente, se han definido dos sobrecargas de la función foo. En las versiones 1.x, no está claro qué sobrecarga se ejecuta en tiempo de ejecución. El usuario podría esperar que se ejecute foo(a:int, b:int) de la segunda sobrecarga, en cuyo caso se esperaría que el método se replicara tres veces y devolviese un valor de 10 tres veces. En realidad, lo que se devuelve es un único valor de 10, ya que lo que se invoca es la primera sobrecarga con el parámetro list.

La segunda sobrecarga se omite en 2.0:

En la versión 2.0, siempre se elige el primer método definido sobre el resto. Se hace valer el orden de llegada.

En cada uno de los siguientes casos, se toma la primera sobrecarga definida. Tenga en cuenta que se considera exclusivamente el orden de definición de las funciones, y no el rango de los parámetros, aunque se recomienda dar preferencia a los métodos con parámetros de mayor rango en el caso de los nodos definidos por el usuario y los nodos Zero-Touch.

3. Compilación de todos los nodos de la interfaz de usuario en métodos estáticos

En Dynamo 1.x, los nodos de la interfaz de usuario (bloques sin código) se compilaban en métodos y propiedades de ejemplar respectivamente. Por ejemplo, el nodo Point.X se compilaba en pt.X y Curve.PointAtParameter se compilaba en curve.PointAtParameter(param). Este comportamiento presentaba dos problemas:

A. La función que representaba el nodo de la interfaz de usuario no siempre era la misma función que se ejecutaba en tiempo de ejecución.

Un ejemplo típico es el nodo Translate. Hay varios nodos Translate que toman el mismo número y tipos de argumentos, tales como: Geometry.Translate, Mesh.Translate y FamilyInstance.Translate. Debido al hecho de que los nodos se compilaban como métodos de ejemplar, la acción de pasar un FamilyInstance a un nodo Geometry.Translate sorprendentemente funcionaba, ya que en tiempo de ejecución enviaba la llamada al método de instancia Translate en un FamilyInstance. Obviamente, esto era engañoso para los usuarios, ya que el nodo no hacía lo que decía.

B. El segundo problema era que los métodos de ejemplar no funcionaban con matrices heterogéneas.

En tiempo de ejecución, el motor de ejecución necesita averiguar a qué función se debe enviar. Si la entrada es una lista, digamos list.Translate(), ya que es costoso revisar cada elemento de una lista y buscar métodos en su tipo, la lógica de resolución del método simplemente asumía que el tipo de destino era el mismo que el tipo del primer elemento e intentaba buscar el método Translate() definido en ese tipo. De esta forma, si el tipo del primer elemento no coincidía con el tipo objetivo del método (o incluso si era null o una lista vacía), se producía un error en toda la lista, incluso si había otros tipos en la lista que coincidiesen.

Por ejemplo, si se pasaba una entrada de lista con los siguientes tipos [Arc, Line] a Arc.CenterPoint, el resultado contenía un punto central para el arco y un valor de null para la línea según lo previsto. Sin embargo, si se invertía el orden, todo el resultado era nulo, ya que el primer elemento no superaba la comprobación de resolución del método:

Dynamo 1.x: prueba solo el primer elemento de la lista de entrada en la comprobación de resolución del método

En la versión 2.0, ambos problemas se resuelven mediante la compilación de los nodos de interfaz de usuario como propiedades estáticas y métodos estáticos.

Con los métodos estáticos, la resolución del método en tiempo de ejecución es más sencilla y se repiten todos los elementos de la lista de entrada. Por ejemplo:

La semántica de foo.Bar() (método de ejemplar) debe verificar el tipo de foo y también comprobar si es una lista o no y, luego, compararlo con las funciones candidatas. Esto es mucho trabajo. Por otro lado, la semántica de Foo.Bar(foo) (método estático) solo necesita verificar una función con el tipo de parámetro foo.

Esto es lo que sucede en la versión 2.0:

• Un nodo de propiedad de la interfaz de usuario se compila en un getter estático: el motor genera una versión estática de un getter para cada propiedad. Por ejemplo, un nodo Point.X se compila en un captador estático Point.get_X(pt). Tenga en cuenta que también se puede llamar al getter estático mediante su alias: Point.X(pt) en un nodo de bloque de código.

• Un nodo de método de interfaz de usuario se compila en la versión estática: el motor genera el método estático correspondiente para el nodo. Por ejemplo, el nodo Curve.PointAtParameter se compila en Curve.PointAtParameter(curve: Curve, parameter:double) en lugar de curve.PointAtParameter(parameter)

Nota: No hemos eliminado la compatibilidad con el método de ejemplar con este cambio, por lo que los métodos de ejemplar existentes utilizados en CBN, como pt.X y curve.PointAtParameter(parameter) en los ejemplos anteriores, seguirán funcionando.

Este ejemplo funcionaba anteriormente en la versión 1.x, ya que el gráfico se compilaba en point.X; y encontraba la propiedad X en el objeto de punto. Ahora falla en la versión 2.0, ya que el código compilado Vector.X(point) solo espera un tipo de Vector:

Ventajas:

Coherente/comprensible: los métodos estáticos aclaran cualquier ambigüedad sobre qué método se ejecutará en tiempo de ejecución. El método siempre coincide con el nodo de la interfaz de usuario utilizado en el gráfico que el usuario espera que se llame.

Compatible: existe una mejor correlación entre el código y el programa visual.

Informativo: el paso de entradas de lista heterogéneas a los nodos ahora produce valores no nulos para los tipos que acepta el nodo y valores nulos para los tipos que no implementan el nodo. Los resultados son más predecibles y proporcionan una mejor indicación de cuáles son los tipos permitidos para el nodo.

Advertencia: ambigüedades no resueltas en los métodos sobrecargados

Dado que Dynamo admite sobrecargas de funciones en general, aún puede confundirse si hay otra función sobrecargada con la misma cantidad de parámetros. Por ejemplo, en el siguiente gráfico, si conectamos un valor numérico a la entrada direction de Curve.Extrude y un vector a la entrada distance de Curve.Extrude, ambos nodos continúan funcionando, lo cual no es un comportamiento esperado. En este caso, aunque los nodos se compilan en métodos estáticos, el motor sigue sin poder establecer una diferencia en tiempo de ejecución y elige cualquiera de ellos en función del tipo de entrada.

Problemas resueltos:

El cambio a la semántica del método estático introdujo los siguientes efectos secundarios que vale la pena mencionar aquí como cambios relacionados con el lenguaje de la versión 2.0.

1. Pérdida del comportamiento polimórfico:

Consideremos un ejemplo de nodos TSpline en ProtoGeometry (tenga en cuenta que TSplineTopology se hereda del tipo de Topology base): el nodo Topology.Edges que se antes se compilaba en el método de ejemplar, object.Edges, ahora se compila en el método estático, Topology.Edges(object). La llamada antes se resolvía polimórficamente en el método de clase derivada, TsplineTopology.Edges, después de enviarse el método mediante el tipo de objeto del tiempo de ejecución.

Por su parte, el nuevo comportamiento estático se veía forzado a llamar al método de clase base, Topology.Edges. De este modo, este nodo devolvió objetos Edge de clase base en lugar de los objetos de clase derivada de tipo TSplineEdge.

Se trata de una regresión, ya que los nodos TSpline descendentes que esperaban la presencia de TSplineEdges comenzaron a fallar.

El problema se solucionó añadiendo una verificación de tiempo de ejecución en la lógica de envío del método para contrastar el tipo de ejemplar con el tipo o un subtipo del primer parámetro del método. En el caso de una lista de entrada, hemos simplificado el envío del método para comprobar simplemente el tipo del primer elemento. Por lo tanto, la solución final resulta del equilibrio de una búsqueda de método en parte estática y en parte dinámica.

Nuevo comportamiento polimórfico en la versión 2.0:

En este caso, dado que el primer elemento a es una TSpline, es el método derivado TSplineTopology.Edges el que se invoca en tiempo de ejecución. De este modo, devuelve null para el tipo de Topology base b.

En el segundo caso, dado que el tipo de Topology general b es el primer elemento, se llama al método de Topology.Edges base. Dado que Topology.Edges también acepta el tipo de TSplineTopology derivado, usar a como entrada devuelve Edges tanto para la entrada a como para la b.

2. Regresiones por la generación de listas externas redundantes

Hay una diferencia principal entre los métodos de ejemplar y los métodos estáticos en lo que respecta al comportamiento de la guía de replicación. Con los métodos de ejemplar, las entradas de un solo valor con guías de replicación no se promueven a listas, mientras que en los métodos estáticos sí se promueven.

Considere el ejemplo del nodo Surface.PointAtParameter con encaje cruzado, una sola entrada de superficie y matrices de valores de parámetros de u y v. El método de ejemplar lo compila en:

lo que genera una matriz de puntos 2D.

El método estático lo compila en:

lo que genera una lista de puntos 3D con una lista exterior redundante.

Este efecto secundario de compilar nodos de interfaz de usuario en métodos estáticos podría provocar regresiones en los casos de uso existentes. Este problema se ha solucionado desactivando la promoción de las entradas de un solo valor a listas cuando se utilizan con guías de replicación o encaje (consulte el siguiente punto).

4. Desactivada la promoción a lista con guías de replicación/encaje

En la versión 1.x había dos casos en los que los valores únicos se promovían a listas:

• Cuando las entradas de menor rango se pasaban a funciones que esperaban entradas de mayor rango.

• Cuando las entradas de menor rango se pasaban a funciones que esperaban el mismo rango, pero donde los argumentos de entrada iban acompañados de guías de replicación o utilizaban encaje.

En la versión 2.0, ya no se admite este último caso al impedir la promoción a lista en tales escenarios.

En el siguiente gráfico de la versión 1.x, una guía de nivel de replicación por cada uno de los elementos y e z forzaba la promoción de matriz de rango 1 para cada uno de ellos, razón por la cual el rango de resultado era de 3 (1 por cada elemento x, y y z). En realidad, el usuario esperaría que el resultado fuera de rango 1, ya que no es del todo obvio que la presencia de guías de replicación para entradas de un solo valor añada niveles al resultado.

Dynamo 1.x: lista de puntos 3D

En la versión 2.0, la presencia de guías de replicación por cada uno de los argumentos de valor único y y z no provoca una promoción que dé como resultado una lista con la misma dimensión que la lista 1D de entrada de x.

Dynamo 2.0: lista de puntos 1D

La regresión mencionada anteriormente y causada por la compilación de métodos estáticos con la generación de listas externas redundantes también se ha abordado con este cambio de lenguaje.

Continuando con el mismo ejemplo anterior, vimos que una llamada a un método estático, como:

generaba una lista de puntos 3D en Dynamo 1.x. Esto sucedía debido a la promoción de la primera superficie de argumento de valor único a una lista cuando se usaba con una guía de replicación.

Dynamo 1.x: promoción a lista de argumentos con guía de replicación

En la versión 2.0, hemos deshabilitado la promoción de argumentos de valor único a listas cuando se usan con guías de replicación o encaje. Así que ahora la llamada a:

simplemente devuelve una lista 2D, ya que la superficie no se promueve.

Dynamo 2.0: desactivada la promoción a lista de los argumentos de valor único con guía de replicación

Este cambio elimina ahora la adición de un nivel de lista redundante y también resuelve la regresión causada por la transición a la compilación de método estático.

Ventajas:

Legible: los resultados se ajustan a las expectativas del usuario y son más fáciles de comprender.

Compatible: los nodos de interfaz de usuario (con opción de encaje) y los CBN que utilizan guías de replicación ofrecen resultados compatibles.

Coherente:

• Los métodos de ejemplar y los métodos estáticos son coherentes (se solucionan los problemas relacionados con la semántica del método estático).

• Los nodos con entradas y con argumentos predeterminados se comportan de forma coherente (consulte el punto siguiente).

5. Las variables son inmutables en los nodos de bloque de código para evitar la actualización asociativa

DesignScript ha admitido tradicionalmente dos paradigmas de programación: la programación asociativa y la programación imperativa. El código asociativo crea un gráfico de dependencias a partir de las sentencias del programa en las que las variables tienen una dependencia entre sí. La actualización de una variable puede activar actualizaciones para todas las demás variables que dependen de ella. Esto significa que la secuencia de ejecución de sentencias en un bloque asociativo no se basa en su orden, sino en las relaciones de dependencia entre las variables.

En el siguiente ejemplo, la secuencia de ejecución del código son las líneas 1 -> 2 -> 3 -> 2. Dado que b tiene una dependencia de a, cuando a se actualiza en la línea 3, la ejecución salta a la línea 2 nuevamente para actualizar b con el nuevo valor de a.

Por el contrario, si el mismo código se ejecuta en un contexto imperativo, las sentencias se ejecutan en un flujo lineal de arriba hacia abajo. Por lo tanto, los bloques de código imperativos son adecuados para la ejecución secuencial de construcciones de código, como bucles y condiciones if-else.

Ambigüedades de la actualización asociativa:

1. Variables con dependencia cíclica:

En ciertos casos, una dependencia cíclica entre variables puede no ser tan obvia, como ocurre en el caso siguiente. En los casos en los que el compilador no puede detectar el ciclo estáticamente, podría darse un ciclo de tiempo de ejecución indefinido.

2. Variables dependientes de sí mismas:

Si una variable depende de sí misma, ¿debe acumularse su valor o debe restablecerse a su valor original en cada actualización?

En este ejemplo de geometría, dado que el valor b del cubo depende de sí mismo y del cilindro, a, al mover el control deslizante, ¿debería moverse agujero a lo largo del bloque o debería crearse un efecto acumulativo por el que se añadieran varios agujeros a lo largo de la ruta por cada actualización de la posición del control deslizante?

3. Actualización de propiedades de variables:

4. Actualización de funciones:

A partir de la experiencia, hemos comprobado que la actualización asociativa no resulta útil en los nodos de bloque de código dentro de un contexto de gráfico de flujo de datos basado en nodos. Antes de que estuviesen disponibles los entornos de programación visual, la única forma de explorar las opciones era cambiar explícitamente los valores de algunas de las variables en el programa. Los programas basados en texto mantienen un historial completo de las actualizaciones de una variable, mientras que, en un entorno de programación visual, solo se muestra el último valor de una variable.

Si lo ha utilizado algún usuario, lo más probable es que haya sido sin saberlo, lo que provoca más daño que beneficio. Por lo tanto, en la versión 2.0, decidimos ocultar la asociatividad en el uso de nodos de bloque de código haciendo que las variables sean inmutables, mientras que seguimos conservando la actualización asociativa solo como característica nativa del motor DS. Este es otro cambio realizado con la idea de simplificar la experiencia del usuario a la hora de crear secuencias de comandos.

La actualización asociativa se ha deshabilitado en los CBN al impedir la redefinición de variables:

La indexación de listas aún se permite en los bloques de código

Se ha realizado una excepción para la indexación de listas y todavía se permite en la versión 2.0 con la asignación de operadores de índice.

En el siguiente ejemplo, se observa que la lista a se inicializa, pero se puede sobrescribir posteriormente con una asignación de operador de índice, y que las variables que dependen de a se actualizarían asociativamente, como se ve en el valor de c. Además, la vista preliminar del nodo muestra los valores actualizados de a tras la redefinición de uno o varios de sus elementos.

6. Las variables de los bloques imperativos son locales al ámbito del bloque imperativo

Hemos realizado cambios en la regla sobre el ámbito imperativo en la versión 2.0 para desactivar escenarios complicados de actualización entre lenguajes diferentes.

En Dynamo 1.x, la secuencia de ejecución de la siguiente secuencia de comandos se daría desde las líneas 1 -> 2 -> 4 -> 6 -> 4, donde un cambio se propaga desde el ámbito del lenguaje externo al interno. Dado que y se actualiza en el bloque asociativo externo y dado que x en el bloque imperativo tiene una dependencia de y, el control se pasa del programa asociativo externo al lenguaje imperativo en la línea 4.

La secuencia de ejecución en el siguiente ejemplo sería la de las líneas: 1 -> 2 -> 4 -> 2, donde el cambio se propagaría desde el ámbito del lenguaje interno al externo.

Los escenarios anteriores hacen referencia a la actualización entre lenguajes, que, al igual que la actualización asociativa, no es muy útil en los nodos de bloque de código. Para deshabilitar los escenarios complejos de actualización entre lenguajes, hemos hecho que las variables en el ámbito imperativo sean locales.

En el siguiente ejemplo de Dynamo 2.0:

• La variable x definida en el bloque imperativo ahora es local al ámbito imperativo.

• Los valores de x e y en el ámbito externo siguen siendo 1 y 2 respectivamente.

Cualquier variable local dentro de un bloque imperativo debe devolverse si se va a acceder a su valor en un ámbito externo.

Véase el siguiente ejemplo:

• y se copia localmente dentro del ámbito imperativo.

• El valor de x local para el ámbito imperativo es 4.

• La actualización del valor de y en el ámbito externo sigue provocando la actualización de x debido a la actualización entre lenguajes, pero está desactivada en los bloques de código de la versión 2.0 debido a la inmutabilidad de las variables.

7. Listas y diccionarios

En Dynamo 1.x, las listas y los diccionarios se representaban mediante un único contenedor unificado que se podía indexar mediante un índice entero o mediante una clave no integral. En la siguiente tabla se resume la separación entre listas y diccionarios en la versión 2.0 y las reglas del nuevo tipo de datos Dictionary:

Nueva sintaxis de lista de []

La sintaxis de inicialización de la lista se ha cambiado de llaves {} a corchetes [] en la versión 2.0. Todas las secuencias de comandos de la versión 1.x se migran automáticamente a la nueva sintaxis cuando se abren en la versión 2.0.

Nota sobre los atributos de argumento por defecto en los nodos Zero Touch:

Tenga en cuenta que la migración automática no funciona con la sintaxis antigua utilizada en los atributos de argumento por defecto. Los autores de nodos tendrían que actualizar manualmente las definiciones de método de Zero-Touch para utilizar la nueva sintaxis en los atributos de argumento por defecto DefaultArgumentAttribute si fuera necesario.

Nota sobre la indexación:

El nuevo comportamiento de indexación ha cambiado en algunos casos. La indexación en una lista/diccionario con una lista arbitraria de índices/claves mediante el operador [] ahora conserva la estructura de listas de la lista de entrada de índices/claves. Anteriormente, siempre devolvía una lista de valores 1D:

Sintaxis de inicialización del diccionario:

Las {} (sintaxis de llaves) para la inicialización del diccionario solo se pueden utilizar en el

formato de par clave-valor, en el que solo se permite una cadena para <key> y los pares clave-valor múltiples se separan mediante comas.

El método Zero-Touch Dictionary.ByKeysValues se puede utilizar como una forma más versátil de inicializar un diccionario pasando una lista de claves y valores respectivamente con todas las comodidades que ofrece el uso de métodos Zero-Touch, como las guías de replicación, etc.

¿Por qué no se han utilizado expresiones arbitrarias para la sintaxis de inicialización del diccionario?

Experimentamos con la idea de usar expresiones arbitrarias para las claves en la sintaxis de inicialización de clave-valor del diccionario y descubrimos que podía conducir a resultados confusos, especialmente cuando una sintaxis como {keys : vals} (tanto keys como vals representaban listas) interfería con otras características del lenguaje de DesignScript, como la replicación, y producía resultados diferentes desde el nodo inicializador de Zero Touch.

Por ejemplo, podría haber otros casos, como esta sentencia, en los que sería difícil definir el comportamiento esperado:

Añadir más sintaxis de guía de replicación, etc., a la mezcla, no solo identificadores, iría en contra de la idea de simplificar el lenguaje.

Podríamos ampliar las claves del diccionario para admitir expresiones arbitrarias en el futuro, pero también tendremos que asegurarnos de que la interacción con otras características del lenguaje sea coherente e inteligible a costa de añadir complejidad en lugar de hacer que el sistema sea un poco menos potente pero simple de entender. Siempre hay una forma alternativa de abordar esto mediante el uso del método Dictionary.ByKeysValues(keyList, valueList), lo cual no es tan exagerado.

Interacción con nodos Zero Touch:

1. Nodo Zero-Touch que devuelve un diccionario de .NET como un diccionario de Dynamo.

Veamos el siguiente método de C# de Zero-Touch que devuelve un IDictionary:

El valor de retorno del nodo ZT correspondiente se calcula según las referencias de un diccionario de Dynamo:

2. Los nodos de retorno múltiple se previsualizan como diccionarios.

El nodo Zero Touch que devuelve IDiccionario con el atributo de retorno múltiple devuelve un diccionario de Dynamo:

3. El diccionario de Dynamo se puede transferir como entrada al nodo Zero-Touch que acepta diccionarios .NET.

Método ZT con un parámetro IDictionary:

El nodo ZT acepta el diccionario de Dynamo como entrada:

Vista preliminar de diccionario en nodos de retorno múltiple

Los diccionarios son pares clave-valor sin ordenar. De acuerdo con esta idea, no se garantiza que las vistas previas de los pares clave-valor de los nodos que devuelven diccionarios sigan el orden de los valores devueltos por los nodos.

Sin embargo, hemos hecho una excepción con los nodos de retorno múltiple que tienen definidos MultiReturnAttribute. En el siguiente ejemplo, el nodo DateTime.Components es un nodo de "retorno múltiple" y la vista preliminar del nodo refleja sus pares clave-valor para que estén en el mismo orden que el de los puertos de salida del nodo, que también es el orden en que se especifican las salidas en función de los MultiReturnAttribute en la definición del nodo.

Tenga en cuenta también que las vistas preliminares de los bloques de código no se ordenan, a diferencia del nodo de interfaz de usuario, ya que la información del puerto de salida (en forma de atributo de retorno múltiple) no existe para el nodo de bloque de código: