Llevo años esperando esto. No es una manía nueva ni un capricho de última hora, es algo que arrastro desde que dejé de trabajar con Softimage. Cuando estaba en activo con ese software, una de las cosas que más disfrutaba era la tranquilidad de saber que todo mi proyecto vivía en un mismo sitio. Texturas, escenas, renders, todo dentro de una misma estructura. Podía copiar esa carpeta a otro disco, a otro ordenador, y abrir el proyecto sin que nada se rompiera por el camino.
En las primeras versiones de Softimage esto se llamaba crear una base de datos. Sonaba un poco raro para lo que en realidad era: una carpeta con una estructura fija donde el propio programa colocaba cada cosa en su sitio. Más adelante, ya con el nombre XSI, lo rebautizaron como Project, y le cambiaron la cara, pero la idea de fondo no cambió nunca. Seguía siendo la misma promesa: organiza esto una vez y no vuelvas a pensar en ello.
De hecho tengo un vídeo mío de hace años explicando el Project Manager de Softimage, así que esto no es nostalgia sin fundamento ni un recuerdo idealizado. Es algo que usé de forma constante, durante mucho tiempo, y que eché de menos cada vez que he tenido que lidiar con rutas rotas en Blender.
Tabla de contenidos
Lo que ya resolvían Softimage, Maya y 3ds Max
Maya y 3ds Max hacen básicamente lo mismo, cada uno a su manera. Maya tiene su Set Project, que crea una estructura fija de carpetas para escenas, texturas y renders en el momento en que la defines. 3ds Max hace algo parecido con su propio sistema de proyectos. En ambos casos la lógica es la misma que en Softimage: mueves la carpeta raíz de un ordenador a otro y todo sigue funcionando, porque las rutas están pensadas para ser relativas a esa raíz.
Blender nunca ha tenido nada de esto a nivel nativo. Cada .blend enlaza a sus texturas y recursos externos con rutas que se rompen en cuanto cambias de máquina o de carpeta. Y durante años la única solución real ha sido apretar los dientes, ir a mano detrás de cada ruta rota, o aprender a base de golpes a usar rutas relativas desde el principio y rezar para que nadie mueva nada de sitio.
Qué es Projects en Blender 5.3
Eso está a punto de cambiar. Blender 5.3, que ahora mismo está en fase Alpha, introduce por fin un sistema de proyectos nativo. No es un añadido de un addon de la comunidad ni un script que alguien ha ido manteniendo por su cuenta, está integrado en el propio núcleo del programa.
Según la documentación oficial, este sistema hace que Blender sea consciente de un contexto más amplio que el archivo que tienes abierto en ese momento. Cada proyecto tiene una carpeta raíz, identificada por una subcarpeta oculta llamada .blender_project, que contiene un archivo de configuración gestionado por el propio Blender. Los archivos que están dentro de esa carpeta tienen acceso automático a las funciones y variables del proyecto, como la nueva project_root, que se puede usar en las plantillas de rutas de archivo.
Es un sistema opcional, no obligatorio. Puedes seguir trabajando exactamente igual que hasta ahora si no te interesa. Y la propia documentación deja claro que esto es solo el arranque: en el futuro se ampliará con más funciones. Lo que hay ahora es la base, no la versión terminada.
Cómo lo han diseñado los desarrolladores
He podido rastrear parte de la discusión de diseño real entre los desarrolladores de Blender, y hay un par de decisiones que merece la pena contar porque explican por qué el sistema se comporta como se comporta y no de otra manera. No es solo «así lo han hecho», es que detrás hay un debate concreto sobre cómo debía funcionar.
La primera decisión importante es la regla que define cuándo un archivo pertenece a un proyecto. No basta con abrirlo dentro de la carpeta del proyecto, tiene que estar guardado ahí. Mientras un archivo no se ha guardado, es un archivo sin proyecto, huérfano, sin acceso a nada de lo que ofrece esa estructura. En el momento en que lo guardas dentro de la carpeta raíz, y solo en ese momento, pasa a formar parte de él. Es la misma lógica que usan Git o VS Code, y de hecho la citaron como referencia directa durante la discusión: primero decides dónde vive el archivo, después empiezas a trabajar con las ventajas de pertenecer a ese contexto.
La segunda es más pequeña pero también importante para el día a día: el proyecto activo se muestra en la barra de título, junto al nombre del archivo. Así siempre sabes en qué contexto estás trabajando sin tener que ir a comprobarlo. Puede sonar un detalle menor, pero es justo el tipo de cosa que evita errores tontos cuando llevas varias horas seguidas saltando entre archivos.
Así se ve ahora mismo en la Alpha
Ahora mismo, en la Alpha, hay muy poco que ver todavía. La he instalado y ya aparece Projects en el menú, así que la función existe de verdad y no es solo una promesa en una nota de desarrollo. Pero en cuanto entras, las opciones disponibles son mínimas. No hay mucho que tocar ni que configurar por ahora.
Tiene sentido que sea así. El desarrollo acaba de empezar, y según la propia documentación oficial, esto se irá ampliando con el tiempo. Estamos viendo los primeros cimientos, no la casa terminada. Si esperabas encontrarte algo parecido a lo que tenías en Softimage, Maya o 3ds Max, todavía no está ahí, y no lo va a estar en esta Alpha. Lo interesante es que el hueco ya existe en el menú, y que detrás hay una discusión de diseño seria que apunta a algo bastante más completo de lo que se ve hoy.
Lo que Blender ya organizaba por dentro
Mientras tanto, hay algo dentro del propio Blender que ya se parece, en espíritu, a lo que resuelve un sistema de proyectos, aunque a una escala mucho más pequeña. Es el Outliner, y probablemente lo has usado cientos de veces sin pararte a pensar en esto que te voy a contar.
Si abres un .blend cualquiera y cambias el modo del Outliner a Blender File, ves algo así:
Aquí no hay carpetas del sistema operativo, es el propio archivo abierto en canal. Cámaras, colecciones, imágenes, luces, materiales, mallas, objetos, escenas, mundos, cada tipo de dato agrupado y accesible desde ese único panel. Es la prueba visual de que un .blend no es un archivo de escena plano como podría parecer a primera vista, es un contenedor que empaqueta dentro todos esos data-blocks, cada uno en su categoría.
La diferencia con Softimage, Maya o 3ds Max es justo esa. En esos programas la organización siempre vivió fuera, en el sistema de archivos, en carpetas que tú podías ver y mover desde el explorador de tu sistema operativo. En Blender, esa organización siempre ha vivido dentro del propio archivo. Lo que trae Projects en 5.3 es, por primera vez, una capa de organización nativa por fuera del .blend, la pieza que le faltaba a Blender para completar el círculo que Softimage, Maya y 3ds Max llevan décadas resolviendo cada uno a su manera.
Voy a ir siguiendo el desarrollo de esta función y actualizando este artículo según avance. Si has usado Softimage, Maya o 3ds Max y echas de menos esto en Blender, cuéntamelo en los comentarios.