MIS Digital Builders

¿Qué es un modelo único de documentación?

Post Stieger

Cuando se trabaja en un proyecto con Revit, es común dividir el edificio en distintos archivos. De este modo se consigue no concentrar toda la información en un único modelo que resultaría demasiado pesado como para trabajar cómodamente en él.

En función de las necesidades requeridas en un proyecto, se pude estructurar el trabajo y el desarrollo de un proyecto BIM de varias maneras. Un criterio que se puede seguir para desarrollar los archivos de un proyecto es plantear los modelos siguiendo las distintas disciplinas existentes, dando como resultado un archivo de arquitectura (ARQ), uno de estructuras (STR) y otro de instalaciones (MEP).

Img1 Modelos
Ilustración 1. Ejemplo de distintos archivos incluyendo el de documentación. Fuente propia.

Estos archivos se van desarrollando paralelamente entre sí hasta que llega el momento de documentar el proyecto. Llegados a este punto muchas personas se preguntan qué es mejor, ¿obtener todos los planos de los distintos archivos o generar un cuarto archivo de Revit (DOC) donde generar y gestionar las tablas, planos, imágenes, leyendas, etc. de un proyecto?

Funcionamiento

El funcionamiento de un archivo único de documentación es sencillo. La forma de trabajar en él es el mismo que en un archivo estándar con vínculos de otras disciplinas sólo que en este caso, por lo general, no existirá ningún elemento modelado y todas las labores de documentación se realizarán sobre los modelos vinculados de arquitectura, estructuras e instalaciones.

La idea es agrupar toda la información del modelo en un único archivo donde se encuentren todos los planos de las distintas disciplinas, las vistas gráficas (plantas, secciones, 3D, etc.), tablas de planificación, leyendas, todos los tipos de elementos gráficos como líneas o textos, familias de anotación, imágenes y evidentemente los vínculos.

Es por eso que en este tipo de modelos se debe tener un gran control sobre los vínculos (Insertar>Gestionar vínculos) y sobre el visualizador de gráficos. Es posible que la visualización de ciertos elementos cambie dependiendo de en qué vínculo se encuentre con lo que es muy probable que cada vínculo tenga su propio visualizador de gráficos personalizado.

Img2 VV
Ilustración 2. Paleta de control del visualizador de gráficos para vínculos. Fuente propia.

Sin embargo, no se podrá generar ninguna vista si previamente no se han generado niveles. Para este tipo de elementos (niveles, rejillas, etc.) lo más recomendable es utilizar la herramienta “Copiar y monitorizar” para contar con los mismos elementos de referencia que los archivos que contienen los modelos y además ser avisados si alguno de ellos cambia o se suprime.

Pros y contras

El principal objetivo cuando se recurre a esta solución es mejorar el rendimiento ya no solo del modelo, sino también el del ordenador.

Es bien sabido que, a más elementos en un modelo, peor rendimiento. Cuantas veces nos hemos encontrado modelos donde es prácticamente imposible orbitar alrededor del edificio o donde se ejecuta alguna herramienta y debemos esperar varios minutos hasta que se cumple la orden. Incluso puede darse el caso en el que no sea posible contar con un ordenador suficientemente potente para trabajar con programas tan exigentes como los de modelado BIM. Todos estos problemas pueden resultar especialmente molestos en fases de documentación donde constantemente se están añadiendo elementos como cotas, textos, etiquetas, etc. Separar la documentación de los modelos afecta directamente al rendimiento del ordenador, el cual consumirá menos recursos y funcionará mejor.

Trabajar con un modelo único de documentación también permite definir responsabilidades con más claridad dentro de un proyecto. En algunos casos hemos podido ver equipos que externalizan el trabajo de documentación y que, al tener un modelo a parte y único, evitaba los clásicos problemas que pueden aparecer flujos de trabajo estándar donde se pueden llegar a eliminar o editar elementos del modelo. De esta manera también se consigue tener toda la documentación del proyecto concentrada en un único modelo y no dividida en varios.

El problema lo podemos encontrar en proyectos muy grandes, donde ya de por sí hay varios modelos de cada disciplina y se pueden complicar las labores de gestión de estos. Además, cualquier cambio que se precise en los modelos se deberán hacer desde sus respectivos archivos, con lo cual, si se detectase algún error, se debería cerrar el archivo de documentación o descargar el link, para abrir el archivo que contenga el modelo y cambiarlo.

Cuadro de texto: Ilustración 3 Paleta de control de vínculos, fuente propia
Ilustración 3. Paleta de control de vínculos. Fuente propia.

Por lo general si un vinculo se descarga del archivo de documentación y ya hay cotas o etiquetas colocadas, estas no se pierden siempre que se vuelva a cargar este mediante las opciones “volver a cargar” o “volver a cargar desde”, pero hay que tener en cuenta que estos archivos son más sensibles a cambios y si que se puede llegar a perder alguna información y más aún en casos en que los modelos siguen vivos y se están editando al mismo tiempo que se genera la documentación.

 En cualquier caso, si que se eliminaran las etiquetas o las cotas que hagan referencia a un elemento el cual ha modificado su ID. Esto puede darse cuando un elemento se elimina o se “remodela”. Por eso es importante que los equipos de modelado y documentación estén bien coordinados entre sí y entiendan que un elemento que ya está acotado o etiquetado en el archivo de documentación no se debe suprimir si se quiere modificar, siempre será mejor editarlo.

Por otro lado, se debe preparar muy bien el visualizador de gráficos y hacer uso de los filtros de vista. Es común que estos modelos cuenten con un gran número de filtros de vista para modificar el grafismo de los distintos elementos puesto que no solo basta con configurar la visualización de gráficos de los vínculos como “personalizado”. Esto puede suponer un problema cuando al modelo acceden personas que no conocen bien el funcionamiento de este, y generan más filtros o editan la configuración cuando realmente no es necesario. Esto puede afectar a plantillas de vista o a configuraciones que ya estaban establecidas de una manera determinada y que den como resultado vistas de entrega defectuosas.

Por último, hay que tener presente que los vínculos entre sí no se pueden unir, y que en el caso de distintos vínculos que muestren elementos que deban estar unidos entre sí, se deberá pensar alguna solución para disimular las juntas que se generarán mediante regiones rellenadas, de máscara o similares.

Cuadro de texto: Ilustración 4 Ejemplo de solución de uniones entre vínculos, fuente propia
Ilustración 4. Ejemplo de solución de uniones entre vínculos. Fuente propia.

Conclusión

Para resolver la pregunta que nos hacíamos al principio, no podemos decir que una opción sea mejor que otra. Realmente, como todo en este mundo del BIM y el Revit, depende de la estrategia que sigamos o de los criterios establecidos en el contrato. Lo importante en situaciones como estas es pensar bien cuales van a ser nuestras necesidades y qué es lo que necesitamos obtener del modelo o del proyecto.

En MSI particularmente preferimos homogeneizar los elementos necesarios para obtener documentación como cotas, carátulas, textos y demás, y obtener la información gráfica directamente de los modelos correspondientes siempre que sea posible. A pesar de esto, creemos que siempre es necesario analizar las condiciones del proyecto y buscar la solución más optima.

Si optamos por homogeneizar los archivos y en el caso de necesitar planos en común como el índice, hacemos uso de la herramienta Insertar vista desde archivo (Insertar>Insertar desde archivo>Insertar vista desde archivo) para así insertar los planos de los demás vínculos. Esto permite tener el plano y los elementos contenidos en él, como vistas, tablas, leyendas, etc.

Artículos relacionados

Abrir chat
Hola 👋
¿En qué podemos ayudarte?