Páginas en este Blog:

jueves, 30 de octubre de 2008

Asunto MBA-070: ... y más ayuda en español.

ProyectOReviT es un blog en lengua castellana que ha estado posteando desde Agosto de 2008.

Este sitio es mantenido por Johann Hudtwalcker, de Lima, Perú. Arquitecto de la Universidad Ricardo Palma, y Especialista Certificado Autodesk. Profesor de Taller de Diseño en la carrera de Arquitectura de Interiores - Instituto TOULOUSE-LAUTREC Consultor Autorizado Autodesk para AEC.


domingo, 26 de octubre de 2008

Asunto MBA-069: Modelo y obra construida: el déjà vu de Revit

Esa sensación de haber estado ahí antes... es más que una sensación. Esto no debiera sorprender a nadie que crea en lo que predica, pero el hecho es que un proyecto desarrollado en Revit Architecture tiene esa propiedad: la cosa es conocida y la obra es sólo la confirmación de una realidad virtual ya largamente recorrida por el proyectista. Y sin embargo...

Estas vistas del nuevo Estadio Olímpico Francisco Sánchez Rumoroso en la ciudad de Coquimbo, Chile, son expresión de ese déjà vu de los modelos tridimensionales. Cabe reconocer que, sobre todo, lo son para nosotros que llevamos varios meses entre esos muros, columnas y graderías, en forma virtual, claro, pero, llegado el momento, las vistas del modelo y las fotografías de la obra real se confunden.













sábado, 25 de octubre de 2008

Asunto MBA-068: Estándares de BIM (y Revit)

Recientemente hemos descubierto la existencia de Revitopia un blog dedicado al establecimiento de estándares para el uso de Revit con pretensiones internacionales. La necesidad de establecer estándares para la documentación de planos, la generación de modelos BIM y la organización de la información en ellos es absolutamente vital. Nos parece que cualquier usario serio del programa, es decir, aquel que debe y deberá producir sus planos y documentos de construcción y, más aún, prestar su servicio profesional recurriendo a un modelo BIM, más temprano que tarde se enfrenta a la necesidad de establecer estándares.

Los estándares son la única forma de capitalizar el esfuerzo. La única forma de convertir una herramienta de diseño como Revit en una experiencia tecnológica. Y pensamos aquí el término tecnología como, precisamente, la repetición. La reedición de una experiencia técnica anterior y su inevitable y consecuente mejoramiento. Sin estándares es imposible repetir.

El problema de los estándares, sin embargo, y quizás aquí está lo utópico de Revitopia, es que tienen un momento histórico y un aquí-ahora donde se validan, justifican y perfecccionan. No es posible la extensión internacional. Y eso, nos parece, bien lo sabe Autodesk con sus productos. La traducción de Revit al español es un ejemplo de esa imposibilidad. En Chile decimos "cielo falso" y no "falso techo"; decimos "terreno" y no "solar"; a los "forjados" les decimos "losas" y a los "solados" los llamamos "Radieres" (vaya un término misterioso). En eso de "traductore traditore" se disuelve lentamente el significado de las cosas y se desintegra el esfuerzo de estandarización. Por eso, lo primero que una educación tecnológica debe hacer es nombrar. Es decir, definir el significado preciso de los conceptos y, en consecuencia, inculcar una terminología, un vocabulario técnico.

Pero el problema no se reduce a eso aunque de ahí surge. La torre de Babel está instalada en el medio de nuestra nación. Nuestra propia industria es todavía incompetente en este aspecto. No sólo la voluntad de ponerse de acuerdo entre fabricantes de un mismo mercado ha sido infructuosa y con tantos diferentes intentos fallidos. Esta voluntad irregularmente existe en cada industrial. Escasamente hay un criterio unificado para la denominación de los diversos productos de un mismo fabricante. Es el encargado del marketing el que denomina los productos y la codificación cambia de producto en producto. Cuando existe, casi núnca se refleja en los catálogos que llegan hasta las manos del arquitecto especificador. Hay honrosas excepciones y frecuentemente coinciden con las mejores especificaciones. A nivel nacional, un ejemplo de este fracaso de clasificación y estandarización se puede ver en la historia del Catálogo de la Construcción y sus distintas ediciones históricas. En las primeras ediciones, el catálogo se distribuía completo como una colección de volúmenes. Por lo tanto, caducaba muy pronto. En ediciones posteriores, se adoptó el método repartir a los consumidores AIC (arquitectos, ingenieros, constructores) un archivador vacío para ir llenandolo con las fichas técnicas por producto. Cada industrial, importador o representante de un producto debía preparar una ficha técnica de aquellos elementos que quería ingresar al catálogo y se las hacía llegar por correo al arquitecto para que este las archivara en el volúmen y actualizara su información. Para ello se creó una nomenclatura y se subdividió en menos de veinte capítulos toda la diversa producción industrial y de servicios relacionada con la construcción. La subdivisión se abandonó en la última edición del catálogo. Hoy apenas existe como capítulos más generales basados en una clasificación de colores, método más "simple" para los ocupados destinatarios.

La tecnología asociada al concepto del diseño empleando BIM sólo puede alcanzar su auténtico esplendor y conseguir sus mejores prestaciones para el desarrollo económico y social de un país si se convierte en un criterio de calidad. Un criterio significa que el trabajo entero relacionado con la construcción es ordenable jerarquizadamente, ahora y en el tiempo futuro. Es decir, conforma una estructura de planificación.

Un pequeño intento de estandarización, absolutamente concreto y reproducible, pero completamente individual y aislado ha sido el que publicamos en el asunto MBA-011. En ese post proporcionamos nuestro archivo de notas clave (sólo los títulos) que incorporaba una serie numérica que subdivide en partidas todo lo identificable en la industria de la construcción chilena (sabemos que no exhaustivamente). Nosotros empleamos intensamente esa nomenclatura y hemos llenado una importante proción de sus capítulos asignándole un código a miles de item y materiales de construcción que se comercializan en Chile (por ejemplo, todos los perfiles de acero, escuadrías de madera, técnicas de fijación (siempre faltan), mallas de alambre, paneles de todo tipo, etc., etc.). La lista no deja ni dejará de crecer. Hoy por hoy es una garantía de especificaciones correctas en nuestros planos. Sabemos de otros usuarios de Revit que adoptaron nuestra lista y han hecho lo propio, perfeccionándola y nutriéndola según sus necesidades. Desde que introdujimos la práctica de las notas clave y el estándar de numeración de partidas y componentes, cada nuevo proyecto Revit (.RVT) ha contribuido a que nuestra biblioteca de familias, cubicaciones, listas de componentes, etc. formen un todo coherente, aprovechable y en continuo perfeccionamiento. Son un estándar propiamente tal y BIM, una auténtica experiencia tecnológica.

El problema actual está en la faceta utópica detrás de BIM. Entre los usuarios de un programa como Revit Architecture, Structure o MEP, el asunto es de fácil comprensión. Más temprano que tarde, cada uno discurre un mecanismo de capitalización del esfuerzo. El paso que falta, sin embargo, es el más difícil pues debe comprometer a los otros tres actores que intervienen en la industria AIC:

a) a los industriales que deben encontrar una motivación para la generosidad, cualidad incompatible con el rigor de la libre competencia. Los industriales por lo menos deben recordar que para vender hay que ser "especificado" en un proyecto, y que los que especificamos somos fundamentalmente los proyectistas,

b) a los constructores, que deben recuperar la confianza en que una obra bien especificada y bien estudiada es beneficiosa para todas las partes porque reduce la incertidumbre y recompensa con justicia el esfuerzo y las destrezas para la calidad y la eficiencia, y

c) a los propios mandantes y gestores de las obras para los cuales la incertidumbre sobre los costos de una obra y el éxito de la gestión está en directa relación con la calidad técnica de la documentación del proyecto y la profundidad de la planificación.


Asunto MBA-067: Más ayuda en español: nuevo blog Revit Argentina

Una buena noticia para la comunidad de usuarios de habla castellana: ha surgido un blog argentino de dicado a Revit Architecture: se trata de REVIT ARGENTINA o Revit ARG que está dirigido por Leonardo Aita, docente de Revit Architecture de la Facultad de Arquitectura, Diseño y Urbanismo de la Universidad de Buenos Aires, Argentina.

¡ Bienvenido !


domingo, 19 de octubre de 2008

Asunto MBA-066: Revit y DWGs

La coexistencia de contenido DWG en un archivo RVT es, sin duda, una característica básica que permite aprovechar el trabajo de terceros que no utilizan Revit, o el propio trabajo antiguo. Sin embargo la importción a Revit de DWGs requiere de ciertas precauciones para evitar hacer muy "pesado" el archivo RVT anfitrión. El documento publicado por Autodesk para los suscriptores Revit Platform 2009, Model Performance Technical Note hace algunas recomendaciones interesantes aunque no del todo insospechadas.

  1. La primera es evitar en lo posible su utilización. Aunque no lo dice así tan tajantemente, el mensaje es: mientras menos DWG importados o vinculados, mejor.
  2. La segunda recomendación es reducir al máximo el tamaño de los archivos DWG antes de vincularlos o importarlos. Eliminar achurados, reducir al mínimo el número de capas. En general incorporar al modelo RVT los archivos más limpios y reducidos posibles.
  3. Sólo importar o vincular un DWG en la vista pertinente. Esto convierte las líneas del DWG en líneas simbólicas, invisibles en otras vista perpendiculares (si el DWG se insertó en una vista de planta, no aparecerá en elevaciones y cortes).
  4. Como corolario de lo anterior, dibujos DWG importados en todo el proyecto (no "Sólo en vista") aparecerán en vista perpendiculares como un conjunto de líneas de modelo coplanares, dando el efecto de sola línea pero de lenta regeneración. En esos casos se debe hacer invisibles en esas vistas los objetos importados.
Tal vez la mejor recomendación es insertar un DWG vinculándolo y no importándolo, y deshacerse de él cuanto antes, sea borrándolo del proyecto o desenlazándolo.




sábado, 18 de octubre de 2008

Asunto MBA-065: Cubicaciones con Revit Architecture

El cómputo de cantidades (Schedules, Material Takeoffs) a partir del modelo BIM es una de las principales prestaciones de Revit Architecture. Sin embargo, hay en esto un cierto arte que debe ser dominado para que los resultados expresados en las Tablas de planificación sean confiables. La precisión de las cubicaciones, nos parece, depende de dos factores principales:

1. La precisión del modelo
2. Los enlaces o uniones de los componentes

Con respecto al punto 1, y que es bastante obvio, la calidad del modelo BIM está diréctamente ligada a la precisión del cómputo de materiales. Por ejemplo, si un muro, que tiene como acabado superficial palmetas de cerámica, se prolonga más arriba del nivel de cielo falso, estas prolongaciones serán también contabilizadas (y habrá cerámica sobre el cielo falso). Si hay elementos duplicados, se contarán dos veces, etc. Sin embargo, no es trivial determinar estos eventuales vicios. No siempre son aparentes ni detectables. Es importante enfatizar la importancia de un modelado preciso y consciente en todo el equipo de trabajo, de tal forma que todos los colaboradores contribuyan a conseguir un modelo prolijo. Y en la precisión del modelo también debe incluirse una correcta clasificación de las partes: como es, por ejemplo, dibujar en la fase correcta, en el nivel que le corresponde lógicamente al elemento y en consistencia con cualquier parámetro relevante que pueda ser necesario como filtro o recurso para la clasificación en las tablas de planificación. Debe, en general, evitarse dejar "para después" los aspectos sistemáticos y de clasificación de las partes.

Con respecto al punto 2. hay prácticas que, aunque bien intencionadas y consistentes con el punto 1., causan imprecisiones tan importantes o incluso peores que las primeras. Un ejemplo de esto es la geometría no unida. No hay restas de elementos que se instersectan si la geometría no está unida. Por ejemplo, si un muro intersecta una losa, la superficie del muro se descontará de la losa sólo si se ha efectuado una unión de los elementos. Pero además, no sólo es cuestión de unir. El problema está en qué se resta de quién. Veamos el ejemplo siguiente:

Se trata de dos suelos y se requiere computar las áreas de cada uno.


El suelo "A", que representa una superficie de terreno con césped, se extiende como objeto en forma continua por debajo de los suelos "B" y "C" que representan dos veredas. En la sección podemos ver que hemos hecho los suelos "B" y "C" más gruesos que el suelo "A" de tal forma que efectivamente corten en todo su espesor al suelo "A", y por lo tanto, la superficie de las veredas se descuente (se reste) de la superficie de césped. No hay problemas con las superficies "B" y "C", las tablas de planificación contabilizarán sus áreas correctamente. Pero con la superficie "A", que pasa por debajo de las otras, la cosa no es tan obvia.La unión de los tres suelos implicará restas de unos con respecto a los otros, y para eso emplearemos el comando Unir geometría.

Sin embargo el resultado depende del orden cómo se seleccionen las partes a unir.
En el caso del suelo "B" se seleccionó primero el suelo "A" y luego el "B". El resultado es que la vereda "B" no se resta del área de césped, y éste pasa continuo a través del sustrato o capas basales de la vereda "B". En caso del suelo "C", se ha seleccionado primero a la vereda y luego al césped. La consecuencia es que la vereda "C" corta al césped y se descuenta de la superficie del suelo"A" el área del suelo "C".

Cuando se une geometría, el orden de selección de los elementos es muy relevante para determinar qué se une con qué o qué se resta de qué.