Detección de interferencias en Navisworks Manage: del modelo al BCF
Para un equipo de proyecto BIM, la detección de interferencias representa el momento donde el modelo deja de ser una representación visual y se convierte en un sistema verificable. Navisworks Manage ocupa una posición central en esta tarea porque combina la agregación de archivos de múltiples disciplinas con herramientas de análisis geométrico, reglas personalizables y exportación de resultados en formatos interoperables. Cuando el flujo termina en un informe BCF correctamente estructurado, las observaciones dejan de vivir en capturas de pantalla dispersas por correos y pasan a integrarse en plataformas de gestión de incidencias, flujos de trabajo BIM 360, ACC, BIMcollab o similares. Esto convierte cada interferencia en un dato trazable que puede asignarse, comentarse y cerrarse a lo largo de todo el ciclo de vida del proyecto. Exploring The Venue Sao Paulo S Convention Centers And Hotels Bcad.
La lectura de este artículo está orientada a coordinadores BIM, modeladores MEP, estructurales y de arquitectura, así como a responsables de calidad de modelo y jefes de proyecto. La idea es recorrer todo el camino que va desde la preparación de los archivos hasta la entrega de un paquete BCF que pueda ser consumido por el resto del software de coordinación sin pérdidas de información ni de contexto geométrico. Se abordarán también criterios para integrar estos informes en plataformas distribuidas y recomendaciones operativas para mantener la calidad del modelo a lo largo del tiempo.
Preparación del espacio de trabajo y selección de modelos
Antes de abrir Navisworks Manage conviene revisar la coherencia del propio entorno de coordinación. Los archivos que llegan de Revit, Archicad, IFC, OpenBuildings o de modelos de fabricantes deben mantener sus unidades, su origen de coordenadas y, sobre todo, sus obras lineales y categorías correctamente modeladas. Un modelo con coordenadas desplazadas no producirá choques reales sino falsos positivos que consumen horas de revisión sin aportar valor. Por eso, la fase previa de alineación en software como Recap, Civil 3D o directamente en Navisworks resulta tan importante como la propia detección, e influye decisivamente en la calidad del informe final.
Una vez alineados, los modelos se anexan en archivos NWF o NWD para que la sesión sea portable entre equipos y para que cualquier persona pueda abrir la coordinación sin necesidad de remontar toda la estructura. Conviene evitar la tentación de abrir directamente el archivo Revit desde la lista reciente, ya que cualquier guardado desde el software de origen quedará reflejado en la sesión y podría contaminar la trazabilidad del BCF. La recomendación habitual en proyectos de cierta envergadura es crear una carpeta de coordinación con versiones fechadas, conservando los NWD publicados como contenedores inmutables y manteniendo los modelos vivos en otra ruta controlada por un gestor documental o por un sistema CDE.
Configuración de pruebas de interferencias
Navisworks Manage ofrece tres tipos principales de pruebas: intersección (hard), proximidad y duplicados. La prueba de intersección compara geometría sólida contra geometría sólida y es la más habitual para detectar tuberías que atraviesan vigas, conductos que se solapan con muros o instalaciones que pisan elementos estructurales. La prueba de proximidad, en cambio, genera un resultado cuando dos elementos se encuentran dentro de una distancia definida, algo muy útil para respetar holguras de mantenimiento, normativas de accesibilidad o radios de seguridad alrededor de equipos. La prueba de duplicados busca elementos solapados del mismo tipo, frecuente en entregables de fabricantes que contienen familias repetidas o bloques copiados sin purgar.
A la hora de configurar cada prueba, los parámetros más sensibles son la tolerancia, el tipo de comparación (superficie contra superficie, superficie contra eje, sólido contra sólido) y los nombres de los sets o selecciones utilizadas. Una buena práctica consiste en crear pruebas nombradas de forma explícita, por ejemplo MEP-Estructura-Arquitectura, y guardar la configuración como plantilla para reutilizarla en sucesivas reuniones de coordinación. De este modo se evitan los clásicos "clash test 1", "clash test nuevo" o "clash test definitivo" que aparecen en proyectos mal organizados y que solo generan confusión cuando el BCF llega al equipo de proyecto.
| Tipo de prueba | Uso recomendado | Ventaja principal | Limitación a considerar |
|---|---|---|---|
| Intersección (hard) | Detección de geometrías que se atraviesan | Resultados claros y visuales | Puede generar ruido si hay tolerancias pequeñas |
| Proximidad | Holguras, mantenimiento, normativa | Aporta contexto normativo | Requiere definir bien la distancia |
| Duplicados | Modelos con elementos solapados | Limpieza de entregables | Sensible a familias mal modeladas |
| Por capa o categoría | Análisis de disciplina específica | Reduce la carga de revisión | Pierde interferencias cruzadas |
La tabla anterior resume las opciones más utilizadas en proyectos reales y permite elegir el tipo de prueba adecuado para cada fase del proyecto, ya sea durante la fase de diseño, en la fase de obra o en la auditoría final del modelo as-built antes de la entrega al cliente.
Ejecución, revisión y clasificación de choques
Una vez definida la prueba, el siguiente paso es ejecutarla y filtrar los resultados. Navisworks Manage permite agrupar, ordenar y filtrar por estado, por nombre, por capa o por disciplina, lo que resulta esencial cuando un proyecto genera miles de incidencias en una sola sesión. La función de agrupar por selección, por grid o por archivo simplifica enormemente la entrega al equipo responsable, porque cada grupo puede exportarse como un BCF independiente con su contexto geométrico y sus propiedades asociadas, sin necesidad de generar archivos demasiado pesados.
Durante la revisión, conviene clasificar cada choque con un estado claro: nuevo, activo, revisado, aprobado, resuelto o rechazado. Esta taxonomía es la que luego se traslada al BCF y la que permitirá a los proyectistas entender qué se espera de ellos en cada ronda. Un choque etiquetado como aprobado significa que la geometría es válida y que se ha asumido una tolerancia justificada; un choque marcado como resuelto implica que se ha modificado el modelo y que debe verificarse de nuevo en la siguiente iteración para confirmar que la solución no introduce nuevos conflictos con otras disciplinas.
Del modelo al informe BCF: exportación y trazabilidad
La exportación a BCF es probablemente la parte más estratégica del flujo, porque condiciona cómo se consumirán los resultados en el resto de la cadena BIM. Navisworks Manage puede exportar a BCF 1.0, 2.0 y 2.1, cada uno con diferentes niveles de información: el nombre del viewpoint, el snapshot, los comentarios, el estado, el autor, la fecha y, en las versiones más recientes, los componentes visuales extendidos y los archivos relacionados con sus GUID. Elegir la versión adecuada depende de la plataforma destino: BIMcollab consume perfectamente BCF 2.1, mientras que algunos visores legacy aún trabajan con 2.0 o con 1.0 reducido.
Para que la trazabilidad sea completa, se recomienda generar un paquete por disciplina o por prueba y nombrarlo con un código reconocible que permita identificarlo incluso dentro de un año. Algunos equipos integran el BCF directamente en una carpeta sincronizada con su plataforma de gestión, mientras que otros lo suben mediante API o conector a ACC. En proyectos distribuidos, merece la pena revisar los protocolos BCF que están adoptando los principales estudios para no perder atributos críticos como el GUID del elemento, el IFC GUID o el identificador de Revit, que son los que finalmente conectan la observación con la geometría real en el software de origen.
Integración con plataformas y equipos de proyecto
El verdadero valor de un BCF aparece cuando este entra en un sistema de gestión de incidencias. Plataformas como BIMcollab, Solibri Model Checker, ACC, BIM 360, Dalux o Revizto consumen los archivos BCF y los transforman en hilos de conversación con asignaciones, plazos, prioridades y comentarios estructurados. La ventaja es que los proyectistas pueden responder directamente desde su software de modelado o desde un visor web, y los coordinadores reciben las respuestas con el contexto geométrico intacto, sin necesidad de adjuntar planos ni capturas adicionales.
Cuando la coordinación se extiende a varios países o a varios equipos externos, el BCF se convierte en un idioma común que reduce la fricción cultural y técnica. Un equipo en São Paulo, por ejemplo, puede recibir los choques detectados en una oficina de Madrid sin que se pierda la referencia visual ni el punto de vista, lo que reduce enormemente las reuniones de sincronización y los malentendidos por malas interpretaciones. Para contextos de gran complejidad urbana, resulta útil revisar ejemplos como el caso de los centros de convenciones de São Paulo, donde la coordinación entre disciplinas, proveedores y operadores exige un flujo BCF muy robusto, bien documentado y con roles claramente asignados.
Recomendaciones operativas para la fase BCF
El último apartado merece una mención específica, porque en muchos estudios la detección de interferencias se trata como un evento puntual en lugar de un proceso continuo. La auditoría recurrente, ejecutada semanal o quincenalmente según el tamaño del proyecto, permite mantener el modelo limpio y detectar regresiones cuando un equipo actualiza su disciplina o cuando se incorporan nuevos elementos a la obra. En proyectos largos, esta práctica evita la acumulación de cientos de choques heredados que ya no son válidos y que solo sirven para entorpecer la revisión posterior.
Para que la auditoría sea sostenible, conviene automatizar la apertura de Navisworks, la ejecución de las pruebas y la exportación del BCF mediante scripts, tareas programadas o herramientas como Dynamo, el API de .NET de Navisworks o plugins específicos desarrollados por el propio estudio. Esta automatización libera al coordinador de tareas mecánicas y le permite centrarse en la interpretación de los resultados y en la comunicación con los equipos de proyecto, donde realmente aporta valor al resultado final.
- Definir plantillas de pruebas con nombres, tolerancias y selecciones estables que se reutilicen en cada sesión.
- Versionar los archivos NWF y NWD en una carpeta controlada con nomenclatura de fecha y código de proyecto.
- Aplicar una taxonomía de estados coherente y comunicada al equipo desde el inicio de la coordinación.
- Exportar a la versión de BCF que mejor soporte la plataforma destino y dejar constancia de la elección.
- Adjuntar comentarios breves, descriptivos y un autor identificable en cada viewpoint generado.
- Cerrar el ciclo verificando que los elementos modificados no generen nuevos choques en la siguiente ronda.
- Documentar el flujo en el BEP para que nuevos equipos se incorporen sin fricción y la coordinación sea repetible.