1 puntos por GN⁺ 6 시간 전 | 1 comentarios | Compartir por WhatsApp
  • El benchmark OpenSCAD Pantheon evalúa si herramientas de codificación con IA pueden implementar una obra arquitectónica en código CAD paramétrico usando solo 2 imágenes de referencia y un prompt corto
  • Google Antigravity 2.0 / Gemini 3.5 Flash High obtuvo la puntuación más alta con una calidad de 4.5/5, e incluso implementó las dimensiones reales del Panteón, su inscripción y el patrón interior del techo artesonado
  • Codex 5.5 High mostró una alta densidad de detalle, pero perdió puntos por la inconsistencia entre la vista previa PNG y el STL final; Sonnet produjo el modelo más limpio entre las ejecuciones autónomas previas
  • Cursor fue el más rápido, pero también el de menor calidad; ModelRift/Gemini Flash 3.0 alcanzó 3.8/5 con un enfoque human-in-the-loop que añadía retroalimentación visual
  • Todos los sistemas ejecutaron el renderizado con OpenSCAD CLI, pero el cuello de botella no fue el acceso a herramientas, sino el juicio geométrico y la validación de la malla final

Objetivo del benchmark y tarea

  • Como ModelRift genera código OpenSCAD para todos los modelos 3D, la capacidad de un LLM para procesar geometría espacial se conecta directamente con la calidad real del modelo
  • Esta prueba fue un pequeño benchmark práctico en el que se dio la misma tarea a varias herramientas de codificación con IA: implementar el Pantheon en OpenSCAD a partir de imágenes de referencia y un prompt corto
  • El objetivo era comprobar la capacidad de convertir referencias arquitectónicas en código CAD paramétrico, renderizar vistas previas PNG con OpenSCAD CLI e iterar para mejorarlas
  • El prompt exigía incluir la rotonda, la cúpula, el pórtico, las columnas, el frontón, el basamento escalonado y los detalles frontales del Pantheon
    see two ref images and build .scad file with openscad implementation of pantheon. use openscad CLI (available) to preview your work (by rendering openscad model to .png)  and iterate until you are happy with the result.
    

Por qué eligieron el Pantheon y OpenSCAD

  • El Pantheon es una tarea que va más allá de una simple prueba de sintaxis de difference(), cube() y cylinder(), pero tampoco cae en geometrías orgánicas, escultóricas o de personajes que OpenSCAD maneja mal
  • Su estructura principal está compuesta por una rotonda circular y una cúpula, un óculo central, un pórtico lineal, columnas, un basamento escalonado y un frontón triangular, lo que facilita comparar diferencias entre resultados
  • Incluso un resultado débil puede parecer un edificio con cúpula, pero uno bueno debe ajustar con más precisión la relación entre el tambor redondo, el pórtico rectangular, el anillo de la cúpula y la fachada frontal
  • OpenSCAD es adecuado para geometría generada por LLM porque el modelo está en código de texto plano y su vocabulario es reducido
  • Instrucciones como “repetir 28 columnas alrededor del radio” o “restar el óculo de la cúpula” pueden expresarse directamente en el código fuente
  • Los resultados son inspeccionables, reproducibles y fáciles de corregir; incluso un error en el espaciado de columnas puede arreglarse modificando parámetros o bucles en vez de depender de un estado oculto de la escena
  • El contexto de por qué ModelRift se construyó sobre OpenSCAD está resumido en Why we built ModelRift on OpenSCAD
  • La desventaja es que OpenSCAD no es una herramienta de esculpido, sino que encaja mejor con objetos constructivos, paramétricos y hard-surface

Resultados generales

  • Las puntuaciones son evaluaciones relativas dentro de este benchmark y no representan un ranking general de modelos
  • La puntuación de tiempo refleja el tiempo de implementación observado, no la hora de publicación del proyecto
  • La puntuación de calidad se asignó de forma conservadora, y ni siquiera el mejor resultado se acerca a un modelo perfecto del Pantheon
  • Resultados por herramienta y modelo:
    • Cursor 3.5 / Composer 2.5: tiempo 5/5, calidad 1.4/5. Fue el más rápido pero también el más débil; más allá de la forma general de la cúpula y el pórtico, le faltaron proporciones, control de color y detalle arquitectónico
    • Codex 5.5 High: tiempo 4/5, calidad 3.0/5. Tuvo una alta densidad de detalle, suficiente incluso para incluir la inscripción del entablamento, pero perdió puntos porque el STL final no coincidía con la vista previa PNG
    • Claude Code 2.1 / Opus 4.7: tiempo 2/5, calidad 3.0/5. Mostró una estructura, un pórtico y un basamento escalonado más claros que Cursor, pero el color era demasiado uniforme y resultaba menos convincente que los mejores resultados
    • Claude Code 2.1 / Sonnet 4.6: tiempo 1/5, calidad 3.4/5. Ofreció la impresión general más creíble y proporciones equilibradas entre las ejecuciones autónomas previas, pero tardó más que cualquiera
    • Google Antigravity 2.0 / Gemini 3.5 Flash High: tiempo 1/5, calidad 4.5/5. Usó dimensiones e inscripciones reales del Pantheon y fue el único agente autónomo que implementó el patrón interior de techo artesonado
    • ModelRift / Gemini Flash 3.0: tiempo 1/5, calidad 3.8/5. Fue el mejor resultado no autónomo usando el flujo de trabajo iterativo con anotaciones de ModelRift y tardó aproximadamente el doble que Claude Code

Observaciones sobre el flujo de trabajo

  • El flujo de trabajo del cliente fue tan importante como el propio modelo
  • Codex Desktop mostraba directamente en la conversación las imágenes que el LLM había cargado en contexto, lo que facilitaba verificar si estaba usando las referencias en una tarea CAD visual
  • Cursor Agent y Claude Code CLI también podían usar imágenes, pero el contexto visual era menos explícito durante el proceso
  • Todos los sistemas probados pudieron manejar la cadena de herramientas local de OpenSCAD y llamaron a OpenSCAD desde el PATH de macOS para renderizar vistas previas PNG
  • El cuello de botella no fue el acceso a herramientas, sino el juicio geométrico, la configuración de cámara y la capacidad de exportar un modelo limpio a una malla final
  • Codex exponía en el mismo hilo las imágenes de referencia, la edición del archivo OpenSCAD y las vistas previas generadas, lo que hacía más fácil seguir el proceso iterativo
  • Después del benchmark público, Codex intentó corregir problemas de exportación del techo y el entablamento, pero la comparación final se basó en el modelo enviado originalmente
  • Cursor ofreció el bucle de interacción más rápido y una interfaz paralela útil para planes y código OpenSCAD, pero la calidad de salida quedó por detrás de las ejecuciones más lentas
  • Claude Code trabajó desde terminal leyendo imágenes y repitiendo comandos de OpenSCAD, pero el proceso de construcción del modelo fue menos visual

Google Antigravity 2.0 / Gemini 3.5 Flash High

  • Explore 3D result
  • Esta ejecución se añadió el 22 de mayo de 2026, poco después de que Google lanzara Antigravity 2.0 en I/O 2026 y de que Gemini 3.5 Flash se presentara el 19 de mayo de 2026
  • El resultado fue el mejor modelo completamente autónomo de este benchmark y también dio señales iniciales positivas sobre Flash 3.5
  • Antigravity 2.0 se parecía más a una app de escritorio agent-first con planificación, ejecución de tareas y vistas previas, y recibió muchas críticas en su semana de lanzamiento porque los usuarios que querían la experiencia previa tipo IDE no tenían una vía de regreso fluida más allá de hacer downgrade o fijar la app anterior
  • Flash 3.5 High no solo estimó a ojo las imágenes de referencia, sino que buscó parámetros reales del Pantheon
  • El plan y el código usaron dimensiones explícitas para la rotonda, la cúpula, el pórtico y el óculo, y las transformaron en valores paramétricos de OpenSCAD
    Implement a detailed, visually stunning, and dimensionally accurate 3D model of the Pantheon in Rome using OpenSCAD.
    
  • Para reflejar también la estructura interior del Pantheon, propuso un modo cutaway
    To showcase both the exterior (stepped rings, portico) and the interior (coffers, niches, perfect spherical proportion), I will include a toggle in the code `show_cutaway = false;`.
    
  • El detalle más fuerte estuvo en el techo
    The Pantheon dome interior has 5 rings of 28 coffers. Subtracting these mathematically in OpenSCAD is highly detailed and looks amazing.
    
  • Antigravity fue el único agente autónomo que implementó el patrón repetitivo de artesonados cuadrados visible a través del óculo
  • El resultado exterior también incluyó elementos que suelen omitirse en salidas rápidas de OpenSCAD
    • material de columnas en gris y rojo
    • inscripción legible
    • anillos escalonados del techo
    • relaciones amplias entre la rotonda, el bloque intermedio, el pórtico y la cúpula
  • La puntuación de calidad fue 4.5/5 y la de velocidad 1/5
  • No fue rápido, pero elevó el techo máximo de generación autónoma en este benchmark y sugiere que Flash 3.5 se ve prometedor para generar código espacial cuando se combina con herramientas de planificación, render, inspección y corrección

ModelRift / Gemini Flash 3.0

  • Explore 3D result
  • Este resultado se produjo mediante un proceso human-in-the-loop con ModelRift y Gemini Flash 3.0, y no fue un benchmark autónomo de una sola pasada como las primeras cuatro ejecuciones
  • El flujo de trabajo tomó unos 10 minutos, aproximadamente el doble del tiempo de Claude Code, por lo que recibió la misma puntuación de velocidad de 1/5
  • Este benchmark se ejecutó el 21 de mayo de 2026, justo después del lanzamiento de Gemini 3.5 Flash
  • El resultado de Antigravity mostró que 3.5 Flash es fuerte, pero en la selección de modelo por defecto de ModelRift también deben considerarse calidad, costo y latencia
  • Los precios de la API de Gemini de Google muestran un precio estándar para Gemini 3.5 Flash de 1.50 dólares por millón de tokens de entrada y 9.00 dólares por millón de tokens de salida, frente a 0.50 dólares de entrada y 3.00 dólares de salida para Gemini 3 Flash
  • Gemini 3.5 Flash implica un aumento de costo de 3x frente a la generación Flash anterior, y es mucho más caro que las referencias de costo de la era Gemini 1.5 Flash
  • La calidad fue de 3.8/5, mejor que el lote de ejecuciones autónomas previas
  • El modelo no era perfecto, pero el pórtico, la disposición de columnas, el techo, las nervaduras de la cúpula y la masa general fueron más consistentes
  • La diferencia clave fue que permitía adjuntar retroalimentación visual directamente sobre el render actual
  • El flujo de trabajo de ModelRift está diseñado para repetir la generación del modelo, la inspección en navegador, la escritura de notas visuales sobre el render y la solicitud a la IA de ajustes en OpenSCAD
  • En trabajo CAD espacial, este bucle es mucho más preciso que dar instrucciones solo con texto

Principales resultados de ejecuciones autónomas

  • Codex 5.5 High

    • Explore 3D result
    • Codex 5.5 High generó el modelo más denso
    • Incluyó la rotonda, nervaduras de la cúpula, el óculo, bandas de piedra apiladas, el pórtico frontal, columnas, detalles del basamento circundante y texto en el entablamento
    • El entablamento contenía M AGRIPPA L F COS TERTIVM FECIT
    • En OpenSCAD, el texto es un elemento difícil desde la perspectiva del modelado porque requiere colocación, extrusión, orientación y un grosor fino estable
    • Durante la iteración, las vistas previas renderizadas se veían mejor que el STL final exportado
    • En el resultado final aparecieron superficies tipo techo con problemas en el entablamento y la zona del techo del pórtico, alterando la impresión del ensamblaje frontal
    • Codex mostró un fuerte razonamiento espacial y una ambición alta de detalle, pero también dejó ver el riesgo de exportación: la precisión de la vista previa no equivale a la precisión de la malla final
    • Si se hubiera evaluado por la mejor vista previa PNG y no por el STL publicado, habría quedado justo por debajo de Antigravity 2.0 en estructura y detalle
    • La nota de 3.0/5 estuvo muy influida por la penalización por la discrepancia entre exportación final y render, más que por la intención de diseño del modelo
  • Claude Sonnet

    • Explore 3D result
    • Claude Sonnet generó el modelo más limpio entre el lote de ejecuciones autónomas previas
    • No intentó tanto detalle fino como Codex, pero la silueta fue más limpia y las principales piezas arquitectónicas encajaron de forma más natural
    • La cúpula, el tambor, el pórtico y la disposición de columnas se leen como un solo edificio y no como un conjunto de primitivas adyacentes
    • Las proporciones también fueron más contenidas y, antes de la ejecución de Antigravity, era el mejor resultado completamente autónomo
    • Claude Code fue entre 2 y 3 veces más lento que Codex en este benchmark, y Sonnet recibió la peor puntuación de tiempo pese a su buena calidad
    • La puntuación de calidad fue 3.4/5, y siguió quedándose en un modelo aproximado, no en una reconstrucción arquitectónica de calidad de producción
  • Cursor Composer

    • Explore 3D result
    • La combinación de Cursor y Composer 2.5 fue la ejecución más rápida, pero también la más débil
    • Sí acertó con los grandes gestos: rotonda, cúpula, pórtico y columnas
    • Pero no captó la contención de materiales ni el matiz arquitectónico que hacen reconocible al Pantheon
    • La salida se parecía más a un placeholder simplificado que a un modelo terminado, y habría necesitado mucho retrabajo antes de publicarse
  • Claude Opus

    • Explore 3D result
    • Claude Opus quedó entre Cursor y Sonnet
    • Produjo un edificio más resuelto que Cursor y mostró con más claridad el pórtico y el basamento escalonado
    • Pero la salida fue demasiado uniforme y menos convincente que Sonnet
    • Había estructura, pero faltaba juicio sobre la jerarquía visual
    • Casi todos los elementos tenían el mismo color y peso, por lo que los detalles competían entre sí en vez de guiar la vista
    • La puntuación actualizada fue 3.0/5; merecía una evaluación mejor que la primera versión de la tabla, pero aun así quedó detrás de Sonnet y Antigravity

Lecciones clave

  • OpenSCAD resistió bien como lenguaje objetivo
    • Su sintaxis es pequeña, la salida es determinista y el CLI renderiza vistas previas inspeccionables dentro del bucle iterativo
    • Los LLM no necesitaron una adaptación especial para usar OpenSCAD
  • El uso de herramientas no fue el cuello de botella
    • Todos los agentes llamaron a OpenSCAD desde el PATH de macOS y renderizaron vistas previas PNG
    • La parte difícil no fue la infraestructura, sino el juicio geométrico
  • La velocidad no predijo la calidad
    • Cursor fue el más rápido, pero produjo el peor resultado
    • Sonnet tardó más entre las ejecuciones autónomas previas, pero produjo el modelo más limpio
    • Antigravity también fue lento, pero Gemini 3.5 Flash High dio el mejor resultado autónomo tras tener tiempo para planear e iterar
    • ModelRift/Gemini Flash 3.0 tardó más, pero gracias a la retroalimentación visual alcanzó una calidad superior a la del lote autónomo previo
  • La vista previa y la exportación no son lo mismo
    • Codex se vio fuerte en el bucle de render, pero en el STL final aparecieron problemas geométricos alrededor del techo del pórtico
    • Los modelos destinados a impresión deben inspeccionar por separado no solo la vista previa, sino también la malla exportada
  • Ningún resultado alcanzó el nivel de un modelo arquitectónico fiel
    • La inscripción de Codex fue un buen detalle
    • Las proporciones de Sonnet fueron consistentes
    • El techo artesonado de Antigravity fue el detalle más sorprendente
    • El resultado de ModelRift/Gemini Flash 3.0 mostró cuánto mejora la calidad cuando una persona hace ajustes visuales
  • Con solo dos imágenes de referencia y un prompt corto, todos los sistemas llegaron a un OpenSCAD válido y renderizable sin escribir manualmente el código CAD directo
  • Las diferencias de calidad entre herramientas fueron grandes, pero el punto de partida en sí fue más alto de lo esperado
  • La generación completamente autónoma todavía no es el flujo de trabajo correcto para este tipo de tarea
    • En ModelRift todavía se usa Annotation Mode para el trabajo iterativo
    • Consiste en dibujar flechas y notas directamente sobre capturas de pantalla del modelo 3D y devolvérselas a la IA
    • En geometría espacial, la etapa human-in-the-loop sigue siendo importante incluso usando modelos de primer nivel
    • El modelo puede acertar las masas generales pero equivocarse en la posición de columnas o en las proporciones de la cúpula
    • Señalar directamente los problemas sobre el render es más rápido y preciso que describirlos con texto

1 comentarios

 
GN⁺ 6 시간 전
Opiniones de Hacker News
  • La semana pasada le compré una bicicleta a mi esposa en Marketplace, y aunque estaba en buen estado, le faltaba uno de los tapones de goma del guiado interno de cables
    Le pasé a Claude una foto solo del agujero con forma de cápsula, y otra junto con un calibrador digital midiendo el largo y el ancho, y con un prompt corto me generó un modelo de OpenSCAD con todas las dimensiones parametrizadas
    Lo imprimí en TPU sin modificar nada y salió casi perfecto desde el primer intento; cuando bajé de 0.3 mm a 0.1 mm la resta que Claude había puesto en las dimensiones x/y, quedó exacto. Es una forma mucho más simple que la arquitectura de la antigua Roma, pero igual impresiona que esto sea tan fácil

    • El CAD era para mí un ejemplo de una tecnología con una barrera de entrada alta que nunca usaba, pero ahora siento que al menos ya puedo resolver cosas simples, aunque sea de manera medio torpe
      Tuve una experiencia parecida creando piezas funcionales simples para impresora 3D con OpenSCAD y LLMs; también sé que los modelos no son tan buenos como generando código React, y yo estoy en el extremo opuesto de un operador experto. Aun así, está buenísimo que esto me haya hecho empezar a aprender una habilidad nueva a nivel hobby
    • Claude funciona bien si le das todas las dimensiones, pero no se le da adivinar
      La verdadera magia sería cuando le das una sola medida o una foto con una regla y la IA saca el resto, pero al menos por ahora Claude es bastante flojo para inferir
    • Hace poco intenté hacer que varios modelos generaran una galleta de la fortuna 3D; Claude lo intentó con three.js y Gemini con OpenSCAD, pero ninguno entendió bien el concepto ni se acercó. Parece ser una forma sorprendentemente compleja
    • Este tipo de impresiones funcionales pequeñas es justo donde OpenSCAD y la generación con LLM brillan
    • ¿También lo optimiza para que no necesite soportes?
  • Es realmente impresionante que “Antigravity fue el único agente autónomo que implementó el patrón característico del techo interior del Panteón, es decir, el techo artesonado cuadrado repetido visible a través del óculo”
    Incluso viendo el modelo 3D, ni se me había ocurrido mirar el interior hasta leer esa frase
    Aquí está el modelo 3D con show_cutaway activado: https://modelrift.com/models/pantheon-benchmark-antigravity-...

    • No sé si es bueno o malo que haya usado información externa que no estaba explícitamente en el prompt para crear el modelo
      Si quieres el “Panteón”, claramente tiene sentido, pero si fueras delineante o ingeniero, creo que sería difícil aceptar un resultado así
    • Vi el interior por casualidad, y ahí se notaba incluso más la inteligencia y el esfuerzo que por fuera
  • No sé en qué benchmark habrá quedado primero Antigravity, pero el Antigravity que me obligaron a usar en reemplazo de Gemini CLI me pide inicio de sesión en el navegador cada vez, y el IDE de Antigravity ni siquiera se actualiza
    Si es posible, antes de preocuparse por salir primero en algo, me gustaría que alcanzaran una calidad de despliegue básicamente aceptable
    El título real es “OpenSCAD LLM Benchmark: Building the Pantheon”

    • De acuerdo. Lo que más me preocupa de los productos de Google AI es el sufrimiento interminable de la experiencia de usuario alrededor del login, pagos, upgrades y cierres de producto
      Aun así, los modelos LLM en sí son buenos y Antigravity 2.0 no está tan mal. Pero si, como mucha gente, perdiste tu configuración y proyectos de Antigravity 1.0, la historia cambia
    • Después de ver Google I/O, de hecho me quedó menos confianza en la capacidad de ejecución de Google
      Gemini 3.5 Flash es raro. Tiene un cutoff viejo; en algunos aspectos es mejor que 3.1 Pro, pero en otros peor, y a veces es más barato y a veces más caro que 3.1 Pro
      Antigravity parecía abandonado y la gente especulaba con su cierre, y en la práctica pasó un poco eso al mover a todos al nuevo Antigravity
      Da la impresión de que Google exporta su organigrama directamente como producto, y tiene demasiados productos de IA, ninguno de los cuales parece el mejor de su clase. Por ejemplo, la integración de Gemini en Google Docs es peor que Claude
      Yo esperaba un modelo con “inteligencia nivel Opus al costo de Haiku” o “rendimiento nivel Sonnet al precio de Gemini 3.0”. Si hubiera salido cualquiera de los dos, habría sido un modelo principal y competidor de Claude/Codex, pero no nos dieron ninguno
    • Uso Claude Code con IntelliJ, así que no entiendo muy bien por qué tanta gente se queja de que Antigravity haya dejado VS Code
      Me pregunto qué aspecto no cubre la combinación Antigravity CLI + VS Code o cualquier otro IDE
    • También fue malo que me forzaran el upgrade desde Gemini CLI, que me gustaba y en algunos aspectos me parecía mejor que Claude Code
      Pero el correo del miércoles, básicamente diciendo “gracias por tu suscripción a Google One AI Pro, pero desde ahora te vamos a poner límites en la cuenta; ni modo”, sí me cayó realmente mal. Antes yo incluso había elogiado AI Pro por su buena relación precio/calidad
    • Que me rompan el flujo de trabajo es la razón principal por la que, aunque me gustaba Antigravity, no lo adopté
      Me alegra que Google esté invirtiendo, pero mientras más viejo me hago, más cuido mi flujo de trabajo
  • He corrido muchos benchmarks en OpenSCAD con toda clase de modelos y configuraciones, y lo que aprendí es esto
    Los modelos son inconsistentes, así que pueden ser excelentes en cierto tipo de modelo 3D y no en otro
    En mi experiencia, los modelos Gemini son los menos inconsistentes y los mejores para entender imágenes
    Los modelos Gemini también son los más creativos, pero si quieres piezas CAD precisas, eso incluso puede no ser deseable
    En general, este benchmark no demuestra mucho. Un solo modelo 3D y un solo intento no bastan. Normalmente pruebo al menos 12 modelos, generando 3 veces cada uno, aunque en realidad habría que hacer mucho más. Pero para un desarrollador independiente el costo es demasiado alto
    Aun así, gracias por publicarlo; pronto voy a probar qué tal rinde Flash 3.5

    • OpenSCAD no puede manejar curvas, así que me parece inútil. No entiendo por qué sigue recibiendo tanta atención
  • Evaluar a los LLM por su capacidad para generar modelos CAD 3D válidos es un benchmark interesante
    OpenSCAD se presta especialmente bien para este tipo de evaluación porque depende por completo de código

  • Cuando lo probé directamente, fue una experiencia bastante mala. En el primer intento puede salir un borrador más o menos decente, pero cuando empiezas a “depurarlo”, terminas en una sesión muy frustrante y te das cuenta de que el modelo no puede “ver” bien el resultado
    O sea, no puede hacer mejora iterativa en absoluto
    Parece que la mayoría de las herramientas de ejecución o harnesses reducen el tamaño de las imágenes antes de procesarlas, y en ese proceso se pierden detalles hasta el punto de que se vuelve difícil razonar, especialmente con imágenes wireframe
    Puede que yo lo esté usando mal, pero esta prueba no verificó realmente esa parte. Solo fue un intento aislado, y ese enfoque se rompe bastante rápido. Sobre todo si no tienes una foto de referencia de lo que quieres hacer

  • Crear un solo objeto del mundo real y declarar que eso es un benchmark no es una forma sólida de evaluar herramientas
    Debería ser más como Iron Chef: dar una temática de arquitectura griega y que un panel de jueces elija al ganador. Ahora mismo es más bien ver qué herramienta hizo el Panteón subjetivamente más convincente

    • Esto se parece más a “¡a mí me gusta esto!” que a un benchmark
      Está evaluando un solo ejemplo mal definido, sin caso de uso final y con un criterio de puntuación completamente subjetivo
  • Todavía falta bastante para ponerse a hacer short de Autodesk
    Como referencia, Autodesk lanzó en diciembre un asistente agéntico para Fusion, y seis meses después sigue siendo bastante malo

    • Es casi ridículamente malo
      En las últimas semanas tuve que diseñar algunas piezas simples para impresión 3D y lo probé; cada una era del nivel de unas 4 operaciones en la timeline, pero incluso describiéndolo en detalle paso a paso con la nomenclatura de Fusion, no lograba acercarse a lo que quería
      En este punto ni siquiera estoy seguro de que pueda crear bien un sólido básico simple
    • ¿Probaste Fusion MCP, que salió el mes pasado? https://aps.autodesk.com/blog/bringing-fusion-claude-creativ...
    • Aún falta, pero creo que eventualmente va a llegar
  • No me termina de convencer. El Panteón es uno de los edificios históricos más icónicos que existen, así que hay muchísimos libros sobre él, además de fotos y modelos públicos que seguramente se usaron para el entrenamiento
    Me parecería más interesante un benchmark de modelado de una estructura anónima solo a partir de las referencias dadas. Se siente como esa magia superficial de ver a un LLM sacar una app de tareas de una sola vez

  • Estoy creando un dispositivo tecnológico para crianza, y su carcasa fue generada completamente por IA
    No tenía idea de por dónde empezar con el modelado 3D, pero el LLM me mostró que esto, como otras cosas, también es código
    Curiosamente, Opus 4.5 me lo hizo perfecto de una vez, justo antes de toda la controversia por la degradación de rendimiento, y desde entonces incluso hacer cambios mínimos en la carcasa se volvió muy difícil
    Parece que Opus pasó de ser un modelo que podía rotar formas mentalmente de manera profesional, a uno que ni siquiera sabe con qué está trabajando