¿Qué es un modelo único de documentación?
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).
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.
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.
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.
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.
