En resumen
- Veo 3.1 Preview se retiró de Gemini API el 22 de octubre de 2026.
- La documentación de Google recomienda migrar a Gemini Omni Flash para crear videos y editarlos mediante indicaciones conversacionales.
- El modelo puede crear videos cortos a partir de texto e imágenes; los resultados pueden editarse en varias rondas.
- Los prompts arquitectónicos de esta guía son originales: son borradores de instrucciones, no una garantía de las funciones disponibles en las fuentes.
¿Qué aprenderás en esta guía?
Esta guía muestra cómo redactar instrucciones de generación de video más claras y controlables para visualización arquitectónica y presentaciones de interiores. El objetivo es estructurar las indicaciones de texto para Gemini Omni Flash y mejorar el primer resultado mediante rondas de edición conversacional. Los ejemplos abarcan situaciones habituales en presentaciones de diseño, como un plano de aproximación a la fachada de una vivienda, un movimiento de cámara en un interior y un cambio de material.
Según la documentación de video de Gemini API de Google, Gemini Omni Flash puede crear videos cortos a partir de texto e imágenes y permite mejorar los resultados en varias rondas. La documentación también ofrece ejemplos de edición conversacional, como cambiar elementos y modificar la perspectiva. Esto no significa que todos los detalles de una escena arquitectónica vayan a conservarse con exactitud. Por eso, conviene considerar los prompts como instrucciones iniciales, revisar el resultado y describir claramente cualquier corrección necesaria.
Requisitos y nota sobre la transición
El flujo de ejemplo se basa en el modelo Gemini Omni Flash indicado en la documentación de Gemini API. El nombre del modelo que aparece en la documentación es gemini-omni-1.1-flash. Las fuentes no explican cómo crear una cuenta, los precios, los requisitos de hardware ni las rutas de menú de una interfaz específica; por tanto, no hacemos suposiciones al respecto. Si se trabaja a través de la API, también hay que consultar las instrucciones actuales de acceso y uso en la documentación de Gemini API de Google.
La fecha clave para los equipos que vayan a migrar es el 22 de octubre de 2026. Google indica que el servicio Veo 3.1 Preview de Gemini API se cerró en esa fecha y recomienda migrar a Gemini Omni Flash o a los modelos GA disponibles a través de Gemini Enterprise Agent Platform para evitar interrupciones. Los ejemplos siguientes están preparados para Omni Flash; no incluyen parámetros ni llamadas a la API del modelo de vista previa Veo que se retiró.
El enfoque básico para diseñar prompts consiste en dividir la solicitud en partes claras y específicas. La guía de estrategias de prompting de Google recomienda indicar con claridad la tarea, la entrada, las restricciones y el formato de salida esperado. También señala que el diseño de prompts puede requerir pruebas y mejoras. Los textos siguientes se crearon para situaciones arquitectónicas a partir de esos principios.
Cinco prompts para videos arquitectónicos
1. Crear un plano de aproximación a la fachada
Primero, separa el tema de la escena del movimiento que quieres en el video. Si usas una imagen de referencia, indica también que debe servir como referencia para el diseño de la fachada existente.
Crea un video breve de presentación arquitectónica tomando como base la fachada de la vivienda contemporánea de la imagen de referencia. Acerca lentamente la cámara al edificio. No cambies la disposición de las ventanas, los materiales ni la forma general del volumen. El movimiento debe ser suave y continuo; no añadas elementos de diseño nuevos.Este prompt describe por separado el tema de la escena, el movimiento de cámara y las características que deben conservarse. Como no se garantiza que el modelo preserve todos los detalles geométricos, compara el resultado con la imagen de diseño.
2. Describir el movimiento de cámara en un interior
En una presentación de interiores, describe la dirección de la cámara y el tipo de movimiento de la forma más sencilla posible. Este ejemplo no fija una duración ni parámetros técnicos concretos, ya que las fuentes no especifican esos límites.
Convierte la sala de estar moderna de la imagen de referencia en un video arquitectónico breve. La cámara debe desplazarse suavemente desde la entrada del espacio hacia la zona de estar. Conserva la distribución de los muebles, las aberturas de las paredes y el diseño de la iluminación. No añadas muebles ni elementos decorativos que no estén en la imagen.La solicitud se centra aquí en una única transición espacial. Si el movimiento de cámara o los elementos de la escena se apartan de lo esperado en el primer resultado, señalar solo el aspecto que hay que corregir en la siguiente ronda ayuda a formular una instrucción más clara.
3. Pedir un cambio de material mediante edición conversacional
La documentación de origen ofrece ejemplos de edición conversacional y sustitución de elementos. El texto siguiente adapta ese enfoque a la presentación de materiales; no afirma que exista una herramienta específica para editar materiales.
Conserva la fachada y el movimiento de cámara del video anterior. Cambia únicamente el aspecto de la superficie de color claro alrededor de la entrada por un revestimiento de piedra más oscuro. No modifiques las proporciones de las ventanas, las aberturas de la fachada ni las demás superficies.La referencia al «video anterior» define una edición continuada; después, se especifica qué elemento debe cambiar y qué partes deben permanecer intactas. Revisa el resultado para comprobar si el cambio se aplicó únicamente a la zona solicitada.
4. Pedir un cambio de perspectiva
La documentación de video de Google menciona el cambio de perspectiva como ejemplo de edición en varias rondas. El ejemplo siguiente es un borrador de instrucción para mostrar la misma escena desde otro punto de vista.
Conserva el edificio y el aspecto de los materiales del video arquitectónico anterior. Muestra esta vez la escena desde la esquina opuesta del edificio. No añadas nuevos volúmenes y no modifiques el diseño de la fachada.Para diferenciar el cambio de perspectiva de una revisión del diseño, se indican por separado las características que deben conservarse, como el volumen y los materiales. Si aparecen cambios en la escena, corrígelos claramente en una solicitud de seguimiento aparte.
5. Indicar el resultado deseado junto con las restricciones
Un prompt no debería limitarse a decir «crea un video». La solicitud queda más definida cuando se indican conjuntamente la tarea, la entrada de la escena y los cambios que deben evitarse.
Genera un video breve de presentación a partir de la imagen del interior proporcionada. Toma como base el espacio y la distribución principal de los muebles de la imagen; procura que la cámara muestre el espacio con claridad. No añadas ventanas, muebles ni elementos decorativos nuevos al diseño. El resultado debe ser una narración visual sencilla, adecuada para presentar un proyecto arquitectónico.Este quinto ejemplo describe el propósito de la presentación y las restricciones, en lugar de exigir un movimiento de cámara específico. Si el resultado del modelo no cumple las expectativas, concreta más la solicitud; por ejemplo, especifica qué partes de la escena deben conservarse o qué dirección de vista se desea.
Errores frecuentes
Combinar demasiadas tareas en un solo prompt: Reunir distintos objetivos en una sola solicitud —como mover la cámara, cambiar materiales y añadir elementos nuevos a la escena— puede dificultar la evaluación del cambio solicitado. Primero, crea el video base y después pide la edición en una ronda aparte.
No indicar qué debe permanecer igual: Una instrucción amplia como «cambia la fachada» deja poco claro qué decisiones de diseño deben conservarse. Describe tanto el elemento que debe cambiar como las partes que deben permanecer intactas.
Esperar un resultado perfecto en un solo intento: Google describe el diseño de prompts como un proceso iterativo. Revisar el resultado y precisar las instrucciones es más adecuado que suponer que el primer prompt funcionará correctamente en todos los casos.
Suponer detalles técnicos que no figuran en las fuentes: La documentación no especifica duración, resolución, parámetros de cámara ni una sintaxis de control especial para los prompts arquitectónicos de esta guía. No añadas esos valores al prompt ni al plan de producción como si estuvieran disponibles.
Próximos pasos para flujos de trabajo de arquitectura y visualización
Los estudios y estudiantes pueden evaluar este enfoque para preparar presentaciones conceptuales breves o probar la generación de video a partir de imágenes existentes. La posibilidad de convertir una imagen de fachada o de interior en una narración en movimiento y corregir el primer resultado mediante indicaciones conversacionales puede aportar valor al flujo de trabajo. Sin embargo, el resultado del modelo no debe considerarse una representación de diseño verificada que sustituya al modelo del proyecto o a los planos técnicos.
Primero, elige una imagen de referencia adecuada para el uso previsto y describe en una frase el resultado que quieres. Después, indica qué elementos del diseño deben conservarse. Compara el video generado con la intención de diseño y, si hace falta, continúa con una sola solicitud de edición. Las fuentes no ofrecen información sobre el precio del servicio Gemini API, las condiciones de cuenta ni los términos de uso; consúltalos en la documentación vigente del servicio antes de empezar. Google indica que el contenido de su documentación está bajo la licencia CC BY 4.0 y que los ejemplos de código están bajo la licencia Apache 2.0.
Fuente y licencia
Este contenido se adaptó al turco a partir de la documentación de Google sobre generación de video en Gemini API, bajo la licencia CC BY 4.0, y de la guía de estrategias de diseño de prompts. Los ejemplos de prompts para situaciones arquitectónicas se redactaron originalmente para esta guía.
Fuentes
2 fuentesNo republicamos los textos de las fuentes; las citas breves van marcadas y el resto es resumen y comentario propios.
Para los estudios de arquitectura y los equipos de visualización de Turquía, la principal ventaja es poder transformar una imagen existente en una breve presentación animada y mejorar el resultado con indicaciones sucesivas. Puede ser útil para hacer pruebas rápidas en presentaciones conceptuales, pero la precisión del diseño y las decisiones del proyecto deben verificarse con supervisión humana.
El cierre de Veo 3.1 Preview puede afectar los flujos de trabajo. Antes de migrar a Gemini Omni Flash, es importante que las organizaciones revisen la información actualizada sobre acceso, licencias y costos; las fuentes no especifican precios ni requisitos de hardware. También conviene revisar las políticas internas sobre el uso de imágenes de clientes.
Preguntas frecuentes
¿Cuándo se cerró Veo 3.1 Preview en Gemini API?
Según la documentación de Google, Veo 3.1 Preview se cerró en Gemini API el 22 de octubre de 2026.
¿Se pueden crear videos arquitectónicos con Gemini Omni Flash?
Google indica que Gemini Omni Flash puede crear videos cortos a partir de texto e imágenes. Los ejemplos de prompts para usos arquitectónicos de esta guía se redactaron originalmente para este artículo.
¿Se pueden editar videos con Gemini Omni Flash?
Según la documentación de Google, los resultados pueden mejorarse mediante indicaciones conversacionales en varias rondas. Cambiar un elemento y modificar la perspectiva están entre los ejemplos de edición de la documentación.



