¡De nuevo con Dynamo! Y es que hay infinidad de aplicaciones que le podemos dar a esta herramienta. A diferencia de en las anteriores entradas donde veíamos cómo realizar comprobaciones normativas (¿Por qué Dynamo? Vol. II: Comprobación Normativa) o cómo cambiar los valores de un determinado parámetro (Automatización de tareas repetitivas, ¿por qué Dynamo?) en este caso veremos varias rutinas sencillas que nos permitan gestionar nuestro modelo.
Antecedentes
Es habitual intervenir en proyectos en los que el nivel de madurez BIM de los colaboradores se encuentra polarizado. Unos tienen mucha experiencia y otros poco o ninguna. Como consultores, confiamos en las automatizaciones para realizar muchas tareas que son importantes para el comportamiento del modelo. Esto permite que ellos puedan centrarse en el proyecto mientras garantizamos que los modelos se estructuran de una forma correcta con los scripts.
En los siguientes posts veremos algunas ideas que a través de Dynamo nos podrían permitir aplicar buenas prácticas para la estructuración de un modelo BIM.
Controlar el peso del modelo
En concreto, en este hablaremos de herramientas que nos permitan controlar el peso del modelo.
Es común oír la importancia que tiene mantener un determinado peso en el modelo. Algunos dicen 150, 200, 250 MB… pero la realidad es que nos encontramos con modelos que pesan más.
Puede ser debido a que el modelo tenga una gran extensión (lo cual no tiene otra solución que segregar el modelo), un exceso de información (tanto geométrico como no geométrico), que tenga configuraciones o familias cargadas que no estén en uso o bien que haya un exceso de vistas en el modelo.
Peso en las Familias
Hay un eterno debate entre las familias genéricas y las familias de fabricante. ¿Debo usar familias genéricas propias y asociar la información del elemento que se ha instalado en obra, o bien he de descargarme familias realizadas por el fabricante que ya incorporen la información del elemento?
Bajo mi punto de vista hemos de usar las familias genéricas propias ya que es la única manera de controlar la estructura de la base de datos (que todos los parámetros se llamen igual, que tengan uso específico, conozcamos el funcionamiento de la familia, etc). A menudo nos descargamos familias de internet y nos encontramos que estas familias están creadas con taxonomías, parámetros y estrategias distintas. E incluso con parámetros que no nos interesa incorporar a nuestro modelo y que queremos eliminar. Dicha información a parte de desestructurar la base de datos añade peso a nuestros ficheros. Por ejemplo, la siguiente familia descargada de la red:
Observamos que hay una serie de parámetros relacionados a la disponibilidad del producto en los distintos continentes que no nos interesa añadir al modelo (por razón x). Por lo que deberíamos suprimirlos antes de cargar la familia a nuestro proyecto. Como ya sabéis realizar esto es muy tedioso y hay que invertir mucho tiempo. A través de automatizaciones podríamos llegar a eliminar varios parámetros de una determinada familia. Como vemos a continuación, el primer vídeo muestra cómo eliminar parámetros de una determinada familia.
Vistas
Otro punto importante para controlar el peso de los modelos son la cantidad de vistas que se alojan en nuestros archivos. Cuantas más vistas en el modelo más tamaño tendrán los archivos. Solemos organizar nuestros navegadores de proyecto para tenerlas debidamente agrupadas, pero sin darnos cuenta generamos vistas y vistas y eso afecta al rendimiento de nuestros modelos. Cada vez que accedemos a una zona del modelo necesitamos crear vistas para poder ver en verdadera magnitud aquello que se está modelando y luego nos olvidamos de suprimirlas. Es recomendable realizar un control periódico de las vistas que se generan en el modelo para poder eliminar aquellas vistas que no tienen un uso específico en el modelo y que se ha pasado por alto su existencia.
Para todo lo anterior podemos usar dos rutinas:
- La primera es un sencillo script
que nos permite eliminar las vistas que no se encuentran correctamente
ordenadas. Cualquier vista que se pretenda conservar debe estar correctamente
organizada y agrupada en el Project browser. Por lo que si no se
encuentra correctamente organizada se sobreentiende que no tiene un objetivo
establecido y que puede ser eliminada. Normalmente usamos 4 tipos de
agrupación:
- WIP
- CONTROL
- EXPORTACIÓN
- IMPRESIÓN
Si alguna vista no se encuentra en ninguna de las anteriores (es decir que se encuentra agrupada en: ???) solemos eliminarla en el plazo de una semana. A continuación, se muestra un vídeo que nos enseña cómo eliminar vistas que no se encuentran ordenadas.
El Script funciona extrayendo información de todas las vistas agrupables en el Project Browser (excluyendo en este caso tablas y leyendas) y comprueba que en los parámetros de agrupación exista algún valor asociado. En caso que no haya ningún valor asociado se eliminarán las vistas.
- El segundo, es un script que nos permite eliminar todas las vistas que no se encuentran en los planos del proyecto. Al hacer entrega de un modelo en cualquier fase de proyecto solemos eliminar las vistas de trabajo (que corresponden a nuestra forma de trabajar) y dejamos solo aquellas que se usan para extraer la documentación del proyecto. Esta función se puede realizar también a través de Etransmit. De estas dos maneras podremos suprimir todas las vistas de trabajo o control que no forman parte de la entrega y liberar peso del archivo. Como se muestra a continuación, en el vídeo se enseña a eliminar vistas que no se encuentran en los planos.
Esta rutina se basa en nodos de Orchid y Datashapes para extraer los parámetros de una familia y crear un front end o cuadro de diálogo en el que el usuario pueda seleccionar los parámetros que posteriormente se eliminarán.
Conclusiones
A través de estos Scripts seremos capaces de gestionar nuestros modelos aplicando buenas prácticas en lo que respecta el tamaño de nuestros modelos. En el próximo post veremos más Scripts que nos permitan gestionar nuestros modelos desde otras vertientes de los modelos BIM.
