Del levantamiento al modelo 3D de una faja y su stockpile

El correo era corto: adjuntamos el modelo 3D de la prioridad 4, faja y stockpile, con su enlace de visualización y la leyenda de colores usada. Tres líneas y un archivo. Pero detrás de ese envío hay una serie de decisiones que se tomaron semanas antes, cuando se acordó qué se iba a modelar, con qué nivel de detalle y en qué orden llegaría. Cuando esas decisiones se conversan al inicio, el correo puede ser de tres líneas. Cuando no, el correo es de tres páginas y termina en una reunión.

Este artículo es sobre eso: qué recibe realmente un cliente cuando pide un modelo 3D de infraestructura existente, qué preguntas conviene hacer antes de firmar el alcance y en qué puntos este tipo de entregable no da lo que uno esperaba. Lo escribimos porque la consulta se repite, y porque casi siempre la confusión está en el mismo lugar.

Un modelo 3D no es una nube de puntos, y conviene decirlo temprano

El levantamiento de campo produce una nube de puntos: millones de coordenadas medidas sobre la faja, la estructura, el chute, el material acopiado. Esa nube es el registro más honesto de lo que había ese día, porque nadie la interpretó. El modelo 3D es el paso siguiente, y ese sí es interpretación: alguien decide que ese conjunto de puntos es un rodillo, que aquello es una viga y que esta franja de material es el stockpile. Son dos entregables distintos y sirven para cosas distintas.

Lo natural es pedir los dos y usarlos en momentos distintos. La nube resuelve la pregunta de qué había; el modelo resuelve la pregunta de qué hago con eso. Si en la revisión aparece una duda sobre un elemento modelado, se vuelve a la nube y se compara. Por eso conservamos ambas y no entregamos el modelo como si fuera la única verdad del proyecto.

Por qué entregamos por prioridades y no todo junto

En una planta grande, modelar todo antes de entregar algo es la peor manera de trabajar. El cliente espera meses sin ver nada, y cuando por fin recibe el paquete completo descubre que el criterio de modelado no era el que tenía en mente, con todo ya hecho. Por eso el alcance se divide en prioridades y cada una se entrega apenas está lista y revisada.

La prioridad 4 de este proyecto era faja y stockpile. Al llegar ahí, el criterio ya estaba calibrado con las anteriores: cómo se nombran los elementos, qué se modela como sólido y qué se deja como referencia, hasta dónde llega el detalle en estructuras secundarias. Ese acuerdo no se logra en una reunión inicial, se logra entregando algo y escuchando la corrección. Priorizar también permite que el cliente empiece a usar las zonas críticas mientras el resto sigue en proceso.

La leyenda de colores es parte del entregable, no un adorno

Con el modelo enviamos la leyenda de colores utilizada. Suena menor y no lo es. En un modelo de coordinación, el color es la primera capa de lectura: distingue disciplinas, estados o categorías de elementos, y permite que alguien que abre el archivo por primera vez entienda qué está mirando antes de hacer clic en nada. Si la leyenda no viaja con el archivo, cada persona interpreta el color a su manera y las observaciones empiezan a cruzarse.

Lo mismo pasa con la convención de nombres del archivo y de los elementos. Cuando el nombre codifica el proyecto, la disciplina y la prioridad, no hay que abrir tres versiones para saber cuál es la vigente. Es trabajo administrativo, no ingeniería, pero es el que evita que un modelo revisado se pierda en una carpeta compartida.

El enlace de visualización evita la discusión sobre el software

Junto al archivo enviamos un enlace a un visor en línea. La razón es práctica: no todos los que necesitan mirar el modelo tienen instalada la herramienta de coordinación, ni un equipo que la mueva con soltura. El gerente que quiere confirmar la posición del stockpile no va a pedir una licencia para eso. Con el enlace abre el modelo en el navegador, gira, mide, comenta y devuelve la observación el mismo día. El archivo pesado queda para quien de verdad trabaja adentro.

Dónde falla esto

Primero, lo oculto. El sensor solo modela lo que vio, y en una faja en operación hay elementos tapados por guardas, por estructura o por el propio material. Esas zonas se resuelven con criterio de ingeniería o quedan marcadas como no levantadas, y eso debe estar declarado, no asumido. Segundo, el nivel de detalle. Un modelo pensado para coordinar interferencias no es un modelo de fabricación, y pedirle precisión de taller a un entregable de coordinación termina en frustración de ambos lados.

Qué conviene dejar por escrito antes de empezar

• Qué elementos se modelan y cuáles quedan solo como nube de puntos.
• El nivel de detalle esperado por tipo de elemento, con un ejemplo acordado.
• El sistema de coordenadas y la cota de referencia del proyecto.
• Los formatos de entrega, incluido el archivo de coordinación y el enlace de visualización.
• La leyenda de colores y la convención de nombres de archivos y elementos.
• Cómo se tratan las zonas ocultas o inaccesibles durante el levantamiento.
• El orden de prioridades y quién valida cada una antes de pasar a la siguiente.

Ninguno de esos puntos es difícil de definir. Lo difícil es acordarlos después, cuando el modelo ya está hecho y cambiar el criterio significa rehacer trabajo. En los proyectos donde esta lista se conversó al inicio, la revisión de cada prioridad se resuelve con comentarios puntuales sobre el modelo y no con una discusión sobre qué se entendió por alcance.