SCAN TO BIM - De la tecnología al modelado BIM - NdP en Revit
Cuando ya hemos adquirido la nube de puntos y vamos a tratarla en Revit, es importante conocer cuáles son los puntos clave a conocer para poder trabajar correctamente con la nube dentro del software de modelado. Que formatos admite, que peso es óptimo para que se maneje de forma ágil, si se trabaja colaborativamente que es necesario tener en cuenta, etc. Como finalmente también formará parte de la estrategia de obtención de nube de puntos, vamos a analizar qué requisitos son necesarios para modelarlas en Revit.
A partir del primer post introductorio de SCAN TO BIM – De la tecnología al modelado BIM - Introducción, continuamos ahora con el cuarto post para plantear como debemos trabajar el archivo de nube de puntos en Revit para un ágil levantamiento a partir de este. Comentamos a continuación, cuales son estos aspectos importantes.
¿Qué tipos de archivos de nube de puntos admite Revit?
Revit permite vincular dos tipos de formatos de nubes de punto dentro de un proyecto Estos son RCP o RCS. Ambos formatos pueden tratarse tanto en ReCap como en Revit. Desde ReCap, como software de Autodesk de tratamiento de nube de puntos, se pueden guardar cualquiera de los dos formatos, pero es importante reconocer las diferencias.
- RCP es un archivo que como un único archivo mantiene vinculado todos los archivos de escaneos que contiene. Un archivo RCP puede tener vinculados 10 archivos linkados de la toma de escaneo.
- RCS es un archivo único que contiene incluidos dentro del propio archivo los puntos de escaneo.
El peso de los dos archivos varia bastante al sistema de unión que existe entre ellos:
Se puede ver en la Ilustración 1 que el peso del archivo RCP es mucho menor que el del archivo RCS. Eso es debido a que la integración de los distintos puntos dentro del archivo estén vinculados y mantenga el vínculo o estén desvinculados.
Podemos ver en la Ilustración 2 que, una vez vinculado en Revit el formato es RCP, se pueden apagar los distintos puntos que contiene el archivo y por tanto, visualizar solo una parte de la nube. En cambio, el archivo RCS pierde la capacidad de vinculo y ha compactado el resultado.
Para que se entienda un poco mejor se podría realizar el símil de que, un archivo RCP sería como un archivo NWF de Navisworks donde tienen vinculados los NWC. Y en cambio un RCS sería un archivo NWD donde pierde la conexión con los NWC y los integra.
¿La ruta y el peso influyen en el modelado?
Cuando debemos levantar un modelo a partir de nube de puntos en Revit, suele ser un proyecto de un tamaño considerable y que, por tanto, también nos encontremos con tener que trabajar varias personas en el modelo al mismo tiempo de forma colaborativa.
Lo primero que tenemos que tener en cuenta es que, si debemos trabajar colaborativamente desde un archivo central con varios locales, debemos hacer que todos los archivos lean la misma ruta relativa a la nube de puntos.
Según Autodesk: “es aconsejable que cada usuario copie localmente los archivos de nube de puntos. Mientras la ruta relativa de las copias locales de los archivos de nube de puntos sea la misma para cada usuario, el vínculo seguirá siendo válido cuando se sincronice con el archivo central.”
Por tanto, cuando el archivo se vincule directamente sobre el proyecto, deberemos generar la misma ruta para cada archivo local.
En cambio, cuando el archivo tenga un peso que impida el trabajo fluido directamente desde Revit, la opción más recomendable es generar un archivo puente, donde en un archivo blanco con coordenadas adquiridas, se vinculen las nubes de puntos. Este archivo solo contendrá la nube de puntos. Posteriormente, en el archivo donde queramos modelar, es donde vincularemos este mismo archivo puente. Esta acción hará reducir el peso del propio archivo y permitirá poder trabajar con ella cuando necesitemos, pudiendo incluso apagar el vínculo cuando no nos interese.
¿Y como modelamos a partir de la nube de puntos?
- Crear elementos de referencia: las nubes pueden sufrir cierta desviación aceptable que pueda hacer variar un nivel, siempre se debe consultar al experto antes para confirmar que es correcto, una vez aceptado ese mínimo error, es recomendable siempre marcar tanto niveles como rejillas de referencia marcando la aceptación del punto escogido de la nube de puntos.
- Crear plantillas de vista para modelar: Se recomienda crear plantillas de vista por plantas donde se controlarán los elementos básicos de modelo y de anotación.
- Un concepto muy importante a la hora de crear plantillas de vista es el Rango de Vista. Se recomienda NO incluir el Rango de vista en las plantillas ya que es recomendable trabajar con rangos muy pequeños para poder visualizar mejor la nube de puntos.
- Secciones de corto alcance. En el caso de las secciones sucede algo parecido, debemos tener en cuenta trabajar con desfases cortos de este modo se puede visualizar solo el fragmento de nube de puntos con el que se quiera trabajar
- Familias vs Componentes in situ: Siempre es recomendable contar con una biblioteca de familias que cubra la mayor cantidad de objetos constructivos que nos podemos encontrar. Estos serán siempre paramétricos y a considerar su categoría y plantilla según la disciplina y función. Pero para según qué proyectos de escaneado, por ejemplo de edificios patrimoniales, SOLO cuando se traten de elementos puntuales/singulares que presentan una complejidad mayor, se realizarán mediante componentes in situ.
El modelo in situ nos permite referenciarlo tanto en el modelo como la nube de puntos, pero habrá que vigilar la cantidad de elementos se hagan de esta forma ya que pueden cargar el modelo con más peso del necesario.
Conclusión
En muchos casos puede resultar arduo tener que empezar de cero modelando en Revit con una nube de puntos, pero a partir de esta serie de posts y los puntos clave de trabajarlos en Revit, puede facilitar muchos pasos que agilizan y ayudan a entender el proceso completo. Este último paso es el que crea el modelo del edificio, por tanto, es en el que hay que poner más hincapié para tener esta base lo más próxima a la realidad teniendo la certeza de haber modelado sobre una nube de puntos.
Property Sets de IFC, ¿Tablas de planificación o .txt? Parte I
Sabemos que para exportar datos desde Revit a IFC con Property Sets personalizados contamos con dos metodologías distintas, la primera a través de tablas de planificación de Revit, y otra que pueda parecer más compleja, configurando un archivo .txt con la estructura necesaria para relacionar los parámetros que queramos en cada agrupación de datos. ¿Cuál es más recomendable usar?
Como vimos en el post anterior Criterios a tener en cuenta para exportar un IFC, descubrimos que existen unos criterios previos que debemos plantearnos antes de exportar un IFC. Y ya no solo se trata de cómo generar la estructura de modelo, sino qué información debe contener para que posteriormente también la contenga el archivo IFC.
Vamos a analizar qué tipo de información puede contener el IFC respecto a los parámetros de Revit.
¿Qué tipos de parámetros nos encontramos en Revit?
Como ya sabemos, en Revit existen dos tipos de parámetros en referencia a los objetos de Revit.
Por un lado, tenemos los parámetros de Tipo, que nos dan información general respecto a todos los ejemplares del proyecto que pertenezcan al mismo Tipo. Por ejemplo, la información del Fabricante, será la misma para todos los ejemplares del mismo tipo de silla que coloquemos en proyecto.
Y, por otro lado, tenemos los parámetros de Ejemplar que nos dan información específica de cada objeto del proyecto y que puede variar de uno a otro. Como, por ejemplo, el área de un muro, que variará según su morfología.
¿Qué tipos de agrupaciones de información podemos generar para un IFC?
Antes de continuar, vamos a hacer un pequeño recordatorio de que es un Property Set. Se trata de un contenedor de parámetros de información, con un nombre específico, y que nos aportarán la información que se obtiene directamente de los objetos contenidos en el proyecto.
Bien, pues a partir de aquí, según los criterios que exija el proyecto, podemos encontrarnos con 4 casuísticas distintas de tipos de agrupaciones de Property Set que queramos exportar a IFC:
- Parámetros de Tipo que vayan referidos a todos los elementos de mi proyecto.
- Parámetros de Tipo que solo vayan referenciados a unas categorías concretas de mi proyecto.
- Parámetros de Ejemplar que vayan referidos a todos los elementos de mi proyecto.
- Parámetros de Ejemplar que solo vayan referenciados a unas categorías concretas de mi proyecto.
Vamos a poner dos ejemplos de cada uno para poder desarrollar:
| CASO 1 – Pset_General | |||
| Nombre en Revit | Nombre en IFC | Información Contenida | Categorías |
| Código de montaje | ClasificacionProyecto | Código GuBIMClass | Todas |
| Descripción de montaje | Descripcion | Descripción GuBIMClass | Todas |
| CASO 2 – Pset_Compra | |||
| Nombre en Revit | Nombre en IFC | Información Contenida | Categorías |
| Fabricante | Fabricante | Nombre del fabricante | Sillas/Mesas |
| Modelo | Modelo_Codigo | Número del código | Sillas/Mesas |
| CASO 3 – Pset_Temp | |||
| Nombre en Revit | Nombre en IFC | Información Contenida | Categorías |
| Fase de creación | TCreacion | Fase en la que se crea | Todas |
| Fase de derribo | TDerribo | Fase en la que se derriba | Todas |
| CASO 4 – Pset_Med | |||
| Nombre en Revit | Nombre en IFC | Información Contenida | Categorías |
| Área | Area | Área del elemento | Muro, Suelo |
| Volumen | Volumen | Volumen del elemento | Pilar, Muro, Suelo |
¿Cuál sería el mejor método de exportación para cada uno de ellos?
Para ello, vamos a coger un pequeño modelo de muestra:
Exportación a partir de tablas de planificación
Si queremos realizar la exportación a partir de tablas de planificación, debemos tener estos aspectos en cuenta:
- En Revit, ninguna tabla de planificación se puede llamar igual.
- En Revit, las tablas multicategoría solo muestran categorías cargables, si no debemos hacerlas por categoría.
- Las columnas de valores calculados de las tablas de planificación, no se exportan desde la tabla a los PropertySets
Vamos a comprobar que deberíamos hacer en Revit:
Vemos que, si queremos hacerlo todo por tablas de planificación, parece que necesitaríamos crear unas 13 tablas de planificación distintas. Y Esto siendo un modelo pequeño. Si fuera un proyecto mayor con muchas más categorías modelada, el número de tablas finales incrementaría bastante.
Recordamos que, para poder exportar las tablas de planificación como Property Sets, en el exportador de IFC debemos marcar Export schedules as property sets:
Ahora vamos a ver el resultado en IFC desde el visor BIMcollab ZOOM:
Si comprobamos qué PropertySets se han exportado para una familia de sistema Muro, comprobamos que:
- Se ha exportado tres veces el Pset_General, el que pertenecía a la tabla de planificación multicategoría (que Revit solo deja ver familias cargables) y todas aquellas que han sido creadas por categoría de sistema concreta.
- Se ha exportado una tabla de Temp y otra de Med específica solo de su propia categoría.
Si comprobamos que PropertySets se han exportado Para una familia cargable Silla - Mobiliario, comprobamos que:
- Se ha exportado tres veces el Pset_General, el que pertenecía a él, desde multicategoría, y aquellas que han sido creadas por categoría de sistema concreta.
- Se ha exportado una tabla de Temp y otra de Compra específica solo de su propia categoría.
Si comprobamos que PropertySets se han exportado Para una familia cargable Puerta, comprobamos que:
- Se ha exportado tres veces el Pset_General, el que pertenecía a él, desde multicategoría, y aquellas que han sido creadas por categoría de sistema concreta.
- Se ha exportado una tabla de Temp específica solo de su propia categoría.
- Se ha exportado también Pset_Compra, que no debía exportarse para él, pero como contiene la información cumplimentada en Revit, se ha exportado igualmente.
Conclusión
Por tanto, la conclusión que podemos sacar de las exportaciones de Property Sets desde tablas de planificación es que:
- Los parámetros que son de Tipo y que se llamen igual para todos los elementos, se repiten tantas veces como en tablas aparezca el mismo nombre de parámetro.
- Los parámetros de Ejemplar aparecen solo en la tabla de planificación que le corresponde.
- La tabla multicategoría, aunque en Revit solo nos muestre familias cargables, en IFC sirve tanto para mostrar familias cargables como de sistema siempre y cuando los parámetros sean de Tipo y se nombren igual.
En el siguiente post, veremos cómo hacer el mismo procedimiento con un archivo .txt, y Así podremos determinar que método funciona mejor.