Guía para generar imágenes arquitectónicas y editar renders con Nano Banana 2.1

¿Qué aprenderás en esta guía?

Esta guía explica cómo evaluar Nano Banana 2.1 para generar imágenes arquitectónicas y revisar mediante texto un render existente. El objetivo no es escribir un prompt genérico y esperar el resultado, sino establecer un flujo de trabajo controlado describiendo la escena, el lenguaje visual y los límites de los cambios. Los prompts de ejemplo son originales: puedes copiarlos directamente y adaptarlos a la descripción de tu proyecto.

Según la documentación de la API de Gemini, el modelo puede generar imágenes a partir de texto y también editarlas aceptando entradas de texto e imágenes. Esto permite elegir entre crear una nueva imagen conceptual o solicitar una intervención específica sobre un render existente. Es importante no tratar los resultados de imagen generativa como sustitutos de planos técnicos, modelos a escala o proyectos ejecutivos, sino evaluarlos como parte de la investigación de diseño y del proceso de presentación.

Requisitos: acceso a la API y selección del modelo

Para este flujo de trabajo se necesita acceso a la API de Gemini y una clave de API. La documentación de Google incluye ejemplos para Python, JavaScript, Java, Go y REST. Para quienes prefieran trabajar sin código, la fuente describe la generación y edición conversacional de imágenes con Gemini, pero aquí no se presupone una interfaz de aplicación ni una ruta de menús concretas.

Si vas a configurar un nuevo proyecto de API, la documentación indica el identificador de modelo gemini-nano-banana-2.1. Google recomienda usar Nano Banana 2.1 en proyectos nuevos. En la misma documentación, se describe como un modelo de alta eficiencia para la generación de imágenes y la edición en varias rondas. La fuente no especifica precios, requisitos de hardware concretos ni un límite de trabajo independiente para la resolución de imagen que usaremos en esta guía, por lo que no deben hacerse suposiciones al respecto.

Si vas a editar una imagen de referencia, asegúrate de tener derecho a utilizarla. Uno de los ejemplos de la documentación muestra cómo cargar una imagen PNG en la API. Consulta la documentación sobre comprensión de imágenes de la API para obtener detalles sobre los tipos de archivo compatibles y la carga de imágenes de mayor tamaño.

Flujo de trabajo arquitectónico paso a paso

1. Decide si quieres generar o editar. Si todavía no tienes una imagen de referencia, empieza generándola a partir de texto. Si quieres conservar un render existente y cambiar una característica concreta, utiliza texto e imagen como entradas. En este segundo método, especifica claramente en el prompt qué elementos deben permanecer sin cambios.

2. Describe la escena de forma concreta. Indica en conjunto el uso del edificio o espacio, los materiales principales, las condiciones de iluminación, el encuadre y la atmósfera deseada. En lugar de una descripción abierta a interpretaciones, como «un interior bonito», utiliza características que hagan visibles las decisiones de diseño. En el primer intento, evita acumular demasiados requisitos de estilo o materiales que puedan entrar en conflicto.

Create an architectural visualization of a compact urban library with a double-height reading hall, exposed timber beams, pale stone flooring, and tall windows facing a planted courtyard. Show the main reading area from eye level with soft overcast daylight. Keep the composition calm and realistic, with no people and no signage.

Este prompt define por separado el programa del espacio, los elementos principales de la construcción, el nivel de visión y las condiciones de iluminación. Si quieres cambiar un elemento concreto en el resultado, prueba una instrucción de seguimiento centrada únicamente en esa decisión, en lugar de volver a escribir toda la descripción de la escena.

1. Al editar un render, define los límites del cambio. Envía la imagen de referencia junto con el texto y divide la solicitud en dos partes: «qué debe cambiar» y «qué debe conservarse». Así, el prompt no solo propone un diseño nuevo, sino que también explica qué características de la imagen existente deben mantenerse. Esto no significa que el modelo vaya a conservar todos los detalles exactamente; hay que revisar el resultado y, si es necesario, solicitar otra ronda.

Edit the provided interior rendering. Keep the room layout, camera viewpoint, openings, and furniture positions unchanged. Change the wall finish to warm light plaster and make the daylight softer. Do not add new objects or alter the floor plan.

En este ejemplo, la edición se limita a los acabados y la luz natural. Compara el resultado generado con la imagen de origen; si cambia la geometría o la disposición del mobiliario, vuelve a intentarlo con un prompt más acotado.

1. Añade el lenguaje visual y los límites. Precisar los materiales y la descripción de la iluminación facilita la comparación entre distintas pruebas. También puedes indicar expresamente preferencias de presentación, como el encuadre, el número de objetos o el uso de texto. Establecer restricciones claras sobre el tipo de resultado que buscas reduce el margen de interpretación, aunque siempre hay que revisar cada resultado.

Create a photorealistic exterior architectural visualization of a small community arts center. Use a restrained palette of light brick, dark metal frames, and clear glazing. Show the entrance and public forecourt in a three-quarter view during late-afternoon light. Keep the building massing simple and do not include text, logos, or banners.

Este prompt describe el tipo de edificio, la paleta de materiales, el ángulo de visión y los elementos que deben evitarse. Si quieres comparar opciones de materiales o iluminación para la misma escena, cambiar una variable principal en cada prueba hará que la evaluación sea más clara.

1. Revisa el resultado y trabaja de forma iterativa. La guía de diseño de prompts de Google se basa en instrucciones claras y concretas, y plantea la redacción de prompts como un proceso de prueba y mejora. En vez de despachar los problemas del resultado con una instrucción genérica como «hazlo mejor», describe la diferencia observada: por ejemplo, indica que ha cambiado la disposición de las ventanas que debía conservarse o que la luz es demasiado intensa. Si trabajas con la API, en los ejemplos la imagen resultante se obtiene mediante interaction.output_image.

Errores frecuentes

Dejar las solicitudes poco definidas: Expresiones como «hazlo más moderno» no indican qué decisión de diseño debe cambiar. Especifica si quieres modificar los materiales, la iluminación o la composición de la escena.

No diferenciar entre lo que debe cambiar y lo que debe conservarse: Si en una solicitud de edición no indicas que se mantengan el ángulo de cámara, la planta o los objetos, puede ser más difícil evaluar las diferencias no deseadas. Comprueba de todos modos las instrucciones de conservación en el resultado; las instrucciones de texto no garantizan que todo se mantenga exactamente.

Cambiar demasiadas variables a la vez: Si modificas al mismo tiempo los materiales, el encuadre, la iluminación y la distribución del espacio, será difícil saber qué instrucción influyó en el resultado. Primero define la escena principal y después prueba las revisiones paso a paso.

Ignorar los derechos de las imágenes: Google recuerda que es necesario contar con los derechos pertinentes para las imágenes cargadas y evitar generar contenido que infrinja los derechos de otras personas. Comprueba las condiciones de uso de las imágenes del proyecto. Además, según la documentación de la API, las imágenes generadas incluyen una marca de agua SynthID; tenlo en cuenta al entregar y utilizar los resultados.

Impacto en los flujos de trabajo de arquitectura y visualización

Para arquitectos, interioristas y equipos de visualización, este método puede ser útil en etapas como la creación de opciones conceptuales, la exploración de atmósferas de materiales o el análisis de alternativas sobre una imagen existente. En particular, dividir el prompt en pequeñas revisiones puede ayudar a que la intención de diseño sea más comprensible para el equipo. Sin embargo, el resultado del modelo no significa que se haya actualizado el archivo de origen ni el modelo técnico. La precisión de las decisiones del proyecto —por ejemplo, las medidas, las uniones, los huecos y el comportamiento de los materiales— debe evaluarse por separado en la imagen generada.

Para utilizar la API se necesitan acceso y una clave de API. Como las fuentes no incluyen información sobre precios, no conviene decidir un uso regular sin calcular los costes. Esta guía no establece requisitos para una tarjeta gráfica específica ni para hardware local. Es más prudente que los estudios empiecen con una prueba pequeña para evaluar la calidad, los requisitos de privacidad y licencias, y la compatibilidad del resultado con su flujo de presentación actual. Estas fuentes tampoco indican que exista integración directa con programas de dibujo y modelado.

Próximos pasos

Prueba varios prompts de edición sobre la misma imagen de referencia, cada uno centrado en un solo cambio, y compara los resultados lado a lado. Guardar los prompts junto con las notas del proyecto ayuda a identificar qué descripción produjo cada preferencia visual. Si trabajas mediante la API, consulta conjuntamente la documentación de Google sobre generación y comprensión de imágenes; ten también en cuenta la nota de que, en resultados de texto e imagen con varias partes, los campos de conveniencia que proporcionan únicamente el último bloque de imagen pueden no incluir todo el contenido.

Fuentes y licencia

Esta guía se adaptó al turco a partir de los documentos de Google Gemini API «Nano Banana image generation» y «Prompt design strategies». Ambas fuentes se publican bajo la licencia CC BY 4.0. El código y los prompts de ejemplo no se han tomado literalmente de las fuentes: los ejemplos para arquitectura e interiores se han creado expresamente.