croquis a render fotorrealista

¿Qué hace croquis a render fotorrealista?

Convierte un dibujo arquitectónico –croquis a mano alzada, alzado, exportación de SketchUp o Revit, plano de sitio coloreado, lámina PDF– en una imagen que parezca tomada con una DSLR de fotograma completo, manteniendo el diseño exactamente como está dibujado. Gemini genera los píxeles (gemini-3-pro-image, generateContent legacy). Tu trabajo es todo lo que rodea a esa llamada: leer el dibujo, redactar el brief, controlar el gasto y verificar cada resultado contra su fuente antes de entregar nada.

scripts/render.py hace la mecánica, una llamada al modelo por pasada: extiende los bordes de la fuente hasta la más cercana de las diez relaciones de aspecto que ofrece el modelo (para que nunca se le pida al modelo que recomponer la escena), renderiza en esa relación, recorta el rectángulo original de la fuente, marca cualquier reencuadre y escribe una hoja de comparación antes/después. Las rutas a continuación son relativas a la carpeta de esta habilidad; llama al script por su ruta absoluta, con el Python que render.py check apruebe.

Dónde se ejecuta esto

El renderizado en vivo necesita Claude Code en la máquina del usuario, con GOOGLE_API_KEY configurada allí. Si no tienes shell local ni sistema de archivos –chat de claude.ai, contenedor de habilidades de la API de Claude– dilo claramente: puedes leer el dibujo, redactar el brief y, si Python y Pillow están presentes, mostrar un mensaje --prompt-only, pero no puedes renderizar. Nunca ofrezcas recibir la clave.

La política vigente – cítala, nunca la parafrasees

La política de renderizado del usuario, dada el 28 de agosto de 2026:

Tarea: Renderizar la imagen de entrada primero en calidad 1K para reducir el coste.

• Mantener una precisión del 100% en geometría, escala y proporción.
• Sin alucinaciones, sin añadir/eliminar elementos a menos que se indique explícitamente.
• Reemplazar los materiales con acabados reales (p. ej., tejados de teja, árboles realistas, piscinas, paisajes).
• El resultado debe parecer fotografía arquitectónica DSLR de alta gama.
• Todas las ediciones y revisiones deben permanecer en calidad 1K hasta que se confirmen.

Una vez aprobado, escalar la misma imagen a calidad 4K:

• Entregar una precisión nítida y detallada sin desenfoque ni manchas.
• Cada elemento debe verse real y fotorrealista al hacer zoom.
• Preservar la geometría exacta y la fidelidad de los detalles de la imagen de referencia.

Regla final: Renderizar siempre las ediciones primero en 1K, luego mejorar a 4K solo después de la confirmación explícita.

El requisito de hoja de comparación del usuario, dado el 31 de agosto de 2026:

en todos los renderizados futuros, después de cada renderizado quiero una hoja de comparación para verificación cruzada. actualizar en todas partes.

Si reformulas alguna de las dos, cítala. Cifras de coste y antecedentes: references/policy.md.

Puertas duras

1. Preguntar antes de gastar. Antes de cualquier llamada facturable, informa al usuario del número de imágenes, el nivel y el coste, y espera un "sí" explícito. Solo entonces añade --spend-ok. El script lo exige: sin --spend-ok imprime la estimación y sale con código 3 sin leer la clave. Un "sí" cubre exactamente lo que has cotizado; cada revisión, parche o reejecución posterior de una pasada fallida es un nuevo gasto, así que cotízalo (una imagen, 1K, hasta USD 0.268) y obtén otro "sí". Puedes poner el plan y el precio en un solo mensaje ("A continuación: revisar la vista 02 para arreglar el color del tejado – 1 imagen a 1K, hasta USD 0.268. ¿Procedemos?"). Las cotizaciones son a la tarifa por imagen; Google también factura la imagen de entrada de cada intento (aproximadamente USD 0.0011), el texto del mensaje y los tokens de razonamiento del modelo, así que di que el cargo real supera ligeramente la cotización.
2. 4K es por imagen, después de la aprobación. Ejecuta upscale --confirmed solo para una imagen que el usuario haya visto en su hoja de comparación y aprobado por nombre. "Se ve bien" sobre un conjunto no es aprobación para pasar el conjunto a 4K, y "hazlo más nítido" no es aprobación para rerenderizar a 4K – pregunta qué imagen en concreto. Cotízalo como cualquier gasto: el nombre del archivo, 1 imagen, 4K, hasta 2 intentos, máximo USD 0.48 (USD 0.24 por intento).
3. Nunca iterar en 4K. Arregla todo primero en 1K; la pasada a 4K reproduce los fallos fielmente. Un archivo 4K es definitivo y nunca se revisa.
4. Cada pasada entrega su hoja, y tú la revisas primero. Después de cada pasada, abre la imagen de la hoja con la herramienta de lectura y revísala con references/review-checklist.md. Decide un veredicto (coincide / menor / mayor) con los problemas que veas, luego entrega el render, la hoja y lo que muestra la hoja. Un render sin su hoja no está terminado.
5. Nunca sobrescribir, y nunca escribir dentro de la carpeta de esta habilidad. El script nunca reutiliza un nombre de archivo y rechaza una carpeta de salida dentro de la habilidad; no muevas, renombres ni reemplaces archivos entregados o fuentes por tu cuenta.
6. Nunca manejar la clave API en el chat. No la pidas, la aceptes, la imprimas ni la escribas en un archivo. Si un usuario pega una, dile que ahora está expuesta en el chat, que debe eliminarla y recrearla en AI Studio, y cómo configurar la nueva como variable de entorno. Prefiere la variable de entorno del usuario a un archivo .env, y nunca pongas un .env en una carpeta de habilidad que se copie, comprima o suba.
7. Decir una vez por proyecto, antes de la primera llamada en vivo, que el dibujo se envía a la API de Gemini de Google (generativelanguage.googleapis.com) para ser renderizado. Los dibujos de los clientes son confidenciales; obtener la aprobación del usuario.
8. Cada reintento se factura, incluidos los intentos que no devuelven imagen. Arregla el mensaje; nunca aumentes --attempts para rescatar uno malo (el script lo limita a 3).

Lo que esta habilidad no puede hacer

El pipeline mantiene la propia cámara del dibujo. No puede mostrar otro lado del edificio, un nuevo ángulo, un zoom, un recorte o una relación de aspecto diferente, y no puede convertir un plano de planta en una perspectiva o vista a nivel de ojo: en el árbol, un plano enviado como imagen volvió como una casa diferente, y los movimientos de cámara solo con mensaje de texto dieron una villa diferente cada vez (references/art-direction.md sección 13). Cuando el usuario pida algo de eso, no gastes: explícalo y pide una nueva exportación de esa vista desde el modelo 3D, luego renderiza esa exportación como un trabajo nuevo. Nunca pongas cambios de cámara o encuadre en notas de revise o patch; el script imprime !! CAMERA / FRAMING WORDS si lo haces.

Tampoco borra etiquetas, registra paneles, coloca mosaicos de aerofotografía muy inclinados ni compone fondos de placa, cosas que el árbol hacía alrededor de sus renderizados (references/failure-modes.md). Cuando eso era lo que funcionaba, advierte al usuario antes de gastar que solo las palabras pueden no ser suficientes.

Verificación de configuración (una vez por máquina)

Ejecuta python scripts/render.py check. Imprime las versiones de Python, Pillow y PyMuPDF, la fuente de la hoja, el id del modelo y dónde se encontró la clave (solo la fuente, nunca el valor); sin clave imprime los pasos para configurar una. Si falla en una importación, ejecuta python -m pip install -r scripts/requirements.txt con ese Python. Con una clave configurada, check --online realiza la llamada gratuita de metadatos models.get para demostrar que la clave y el modelo funcionan; nunca se factura.

Flujo de trabajo para una vista

1. Toma de entrada

Obtén del usuario: el archivo como ruta en disco (una imagen pegada no tiene ruta – pregunta dónde está el archivo), un nombre de vista y notas en cuatro campos – materiales, iluminación, entorno, otros (cada uno opcional). Pregunta sobre cualquier cosa que el dibujo deje abierta y que cambiaría la imagen (¿esta zona plana es césped o pavimento? ¿de dónde viene el sol?) en lugar de adivinar. Clasifica la entrada:

• Una lámina con varios paneles (plantas, alzados), o un PDF cuya vista no está en la página 1: haz exportar un panel o página, o recórtalo tú mismo en un nuevo archivo dentro de una carpeta ... Input, una vista por trabajo. Informa al usuario de que la hoja de comparación emparejará ese panel con su render. Las distribuciones densas de mobiliario fallaron generativamente en el árbol; dilo antes de gastar.
• Una solicitud que el pipeline no puede cumplir (ver arriba): detente y explica antes de cualquier gasto.
• Una lámina con cajetín, cuadro de superficies, etiquetas o líneas de límite reglamentarias: deben permanecer exactamente como están dibujadas, y el modelo no puede mantener texto (el brief lo prohíbe). Haz que se recorten antes del renderizado y se vuelvan a colocar sin cambios en la lámina final fuera del render; nombra cualquier línea reglamentaria en una advertencia para que no se convierta en un muro o se borre.
• Una solicitud que contradiga el dibujo (un tejado plano donde se dibuja uno a cuatro aguas): señála y pregunta. La política mantiene la geometría tal como está dibujada a menos que el usuario diga explícitamente lo contrario.

2. Leer el dibujo y redactar el brief

Ejecuta primero una pasada gratuita --prompt-only, siempre con --out (fuera de la carpeta de esta habilidad; para assets/test_sketch.png, una carpeta temporal): rasteriza la página 1 de un PDF y escribe la entrada rellenada en <out>/_work/prompt-only/<view>_<tier>_padded.jpg (máximo 2400 px), el archivo más fácil de ver. Ábrelo con la herramienta de lectura y estúdialo. Luego escribe el JSON del brief siguiendo references/art-direction.md:

{"elements": ["bloque de dos plantas, tejado a cuatro aguas, mitad izquierda del encuadre", "..."],
 "finishes": ["paredes de estuco de cal color blanco cálido roto", "..."],
 "cautions": ["ENCUADRE: la villa ocupa el 20-78% del ancho, alero al 37% de altura; si crece, se recentra o se añade cielo, el resultado ha fallado", "..."]}

• elements: cada elemento del edificio, hueco, forma de tejado, planta, barandilla, piscina, zona pavimentada, masa de plantación y mueble, con su posición y su número (máximo 30 elementos, 160 caracteres).
• finishes: los materiales reales (máximo 15, 120 caracteres).
• cautions: el anclaje de encuadre medible PRIMERO, con su prueba de "el resultado ha fallado si ..."; luego número de plantas, artefactos de dibujo que no son objetos, y negativos específicos de este encuadre (máximo 10, 160 caracteres).

Mantén el brief corto – los briefs largos perdían el encuadre en el árbol. Guárdalo junto al trabajo, p.ej., <out>/_briefs/<view>.json. El texto más largo sobre materiales o entorno va en --materials / --environment (las notas pueden totalizar 4000 caracteres).

3. Elegir las banderas

• ¿Los tejados no son de teja (losas planas, membrana, pizarra, metal, cubierta vegetal)? Añade --no-terracotta-example, pon una advertencia de tejado en el brief ("todos los tejados son planos – sin tejas, sin pendiente, sin terracota", o "el tejado del ala es una losa plana – sin tejas, sin pendiente") y nombra el acabado real del tejado. El brief de fidelidad compartido usa terracota como ejemplo de acabado y ha añadido tejados de teja roja a villas con tejado plano; la bandera elimina ese ejemplo positivo. Una advertencia aún puede nombrar la terracota como negativo.
• El nivel por defecto es 1K. Sugiere --size 2K (mismo precio de catálogo) solo cuando los elementos clave medirían menos de unos 20 px a 1K, como en una aerofotografía amplia de una finca, y úsalo solo después de que el usuario acepte; 4K nunca es un nivel de borrador.
• ¿La entrada es una copia preparada (líneas de eje limpiadas, etiquetas borradas, un vacío blanco pre-rellenado)? Pasa la exportación sin modificar como --original FILE para que la hoja empareje el verdadero original.
• --out por defecto a una carpeta hermana 03 Output cuando la entrada está en una carpeta ... Input, si no <carpeta de entrada>/03 Output; nunca puede estar dentro de la carpeta de esta habilidad.

4. Auditar el mensaje (gratuito)

Vuelve a ejecutar con el brief y las notas y --prompt-only, lee el mensaje impreso y verifica que nada en él pida un elemento que el dibujo no tenga.

5. Estimar, preguntar, renderizar

Ejecuta el comando sin ninguna bandera de puerta para obtener la estimación (código de salida 3), cotízala al usuario y espera un "sí". Luego ejecútalo de nuevo con --spend-ok. Una llamada en vivo suele tardar 20-60 s, pero un intento puede esperar hasta 15 minutos, más que una llamada Bash en primer plano: ejecuta las pasadas en vivo en segundo plano (run_in_background) y espera a que terminen. Si un comando en vivo se interrumpe, ejecuta render.py status, informa de la pasada interrumpida como posiblemente facturada y pregunta antes de cualquier reejecución. Varias vistas: cotiza el total del lote (vistas x 1K x hasta 2 intentos) y obtén un "sí" para el lote, luego ejecuta las vistas una tras otra.

6. Revisar la hoja

Abre <out>/_Before After - <view>_1K.jpg con la herramienta de lectura. Sigue references/review-checklist.md: encuadre y proporciones, recuentos, huecos, forma del tejado, plantas, objetos añadidos o faltantes, texto, materiales, realismo. Una nota naranja "aspecto a -> b (encuadre cambiado)", o una línea de ADVERTENCIA del script, significa que el modelo reencuadró: ese render no se puede revisar ni aprobar, así que renderiza de nuevo desde la fuente con un anclaje de encuadre más fuerte y una advertencia que nombre exactamente lo que hizo la pasada fallida ("INTENTO ANTERIOR FALLÓ: ..."). Si dos renders de 1K de una vista reencuadran, detente e informa en lugar de reintentar. Abre el render mismo cuando la hoja sea demasiado pequeña para juzgar un detalle.

7. Informar

Dale al usuario: la ruta del render, la ruta de la hoja, tu veredicto con los problemas que encontraste, el coste (render.py status lo muestra), y las opciones – aprobar esta imagen para 4K, revisar una cosa, parchear una región, o renderizar de nuevo desde la fuente.

Bucle de revisión (se mantiene en 1K)

revise "<render actual>" --notes "<un cambio>". Reglas:

• Un cambio por pasada. Varios cambios en una sola edición tienden a regenerar todo el encuadre.
• Describe el estado deseado del objeto, no la corrección ("la puerta de entrada es de madera maciza color bronce cálido con dos barras de tracción verticales", no "arregla la puerta"). Haz zoom en el render antes de escribirlo: un cambio de color no es una adición.
• El "antes" es la imagen que se está revisando; la hoja la empareja con el nuevo archivo (BEFORE · <view>_1K / AFTER · <view>_1K_rev02).
• Solo el archivo actual (la pasada más reciente que no sea 4K del trabajo) se puede revisar; el script lo nombra si eliges otro. Una revisión de un render de 2K se hace a 1K y se nombra _1K_revNN.
• Cuando la composición en sí está mal (la cámara se movió, el sujeto creció, advertencia de reencuadre), no revises: ejecuta render de nuevo desde la fuente con un mejor brief.

Parche (una corrección local, se mantiene en 1K)

patch "<render actual>" --box x0,y0,x1,y1 --notes "<el cambio>" con la caja como fracciones del encuadre (0,0 arriba a la izquierda). La caja se recorta, edita a 1K completo, se escala de nuevo y se pega con una pluma de 36 píxeles en los bordes dentro del encuadre; cada píxel fuera de la caja permanece idéntico byte a byte. Úsalo para un objeto o una zona (un muro inventado, una planta equivocada, una puerta). Di qué debe cambiar y que debe ser claramente visible; no le digas que mantenga precisamente lo que quieres cambiar. Cada lado de la caja debe tener al menos 72 píxeles.

4K (una imagen aprobada)

Cuando el usuario haya aprobado una imagen por nombre, ejecuta upscale "<ruta del render>" --confirmed (sin la hoja ni notas de revisión). El script toma el render de 1K de la cesta de salida, ejecuta hasta 2 intentos a 4K, elige el mejor (la imagen que el modelo considere de mayor calidad) y lo entrega en la misma carpeta con el sufijo _4K. La hoja de comparación empareja ese archivo 4K final contra el render de 1K del que partió. No ejecutes revise ni patch sobre un archivo 4K; nunca se revisan.