Cómo Cerebrium convirtió la infraestructura de IA en una experiencia 3D

Cerebrium presentó una experiencia web que busca hacer comprensible la infraestructura sin servidor para inteligencia artificial mediante escenas 3D, animaciones interactivas y efectos gráficos en tiempo real. El proyecto combinó diseño, dirección artística y desarrollo con Three.js, WebGPU, WebGL y técnicas de programación de shaders para que los visitantes no solo leyeran sobre la plataforma, sino que pudieran percibir visualmente cómo funciona un sistema modular, rápido y preparado para escalar.

Explicar la infraestructura sin servidor para inteligencia artificial es un desafío especialmente complejo. El concepto reúne cómputo bajo demanda, procesamiento distribuido, escalabilidad, seguridad, redes y automatización, elementos que suelen presentarse mediante diagramas técnicos, capturas de paneles o extensos bloques de texto. En el caso de Cerebrium, el equipo eligió una estrategia diferente: convertir esas ideas abstractas en una experiencia digital que pudiera explorarse con el mouse y el desplazamiento por la página.

Según Fuente original, la información se basa en Building Cerebrium: Making Serverless Infrastructure Tangible.

El resultado no funciona como una simple decoración visual para una página corporativa. La interacción forma parte del mensaje principal. Las escenas, las transiciones, las partículas y los caminos luminosos fueron diseñados para transmitir atributos asociados con la plataforma: velocidad, precisión, modularidad y capacidad de crecimiento. La identidad del producto se expresa a través del comportamiento de la interfaz, no únicamente mediante textos comerciales o imágenes estáticas.

El desarrollo fue documentado en un artículo publicado por Codrops, fuente original del proyecto. Allí se detallan las decisiones técnicas, los problemas de rendimiento y los recursos utilizados para llevar una propuesta visual ambiciosa a un entorno de producción.

infraestructura de IA en 3D: Una infraestructura de inteligencia artificial que se entiende con interacción

La idea central consistió en evitar una explicación puramente racional de la infraestructura. En lugar de comenzar con una arquitectura formada por cajas y flechas, la experiencia permite recorrer entornos virtuales que representan relaciones, flujos y capas de protección. La intención es que el usuario comprenda el funcionamiento general a través del movimiento, la profundidad, la iluminación y la respuesta de los objetos.

Este enfoque tiene valor para empresas tecnológicas que venden productos difíciles de explicar. Una plataforma de inteligencia artificial puede ser potente, pero si su propuesta resulta demasiado abstracta para un visitante nuevo, la comunicación pierde eficacia. Una visualización interactiva puede ayudar a mostrar cómo se conectan los componentes y qué sensación debería transmitir el servicio, siempre que la estética no reemplace a la información funcional.

En Cerebrium, cada entorno 3D fue integrado dentro de un mismo lienzo. El desafío consistió en mantener materiales, partículas, luces y efectos de posprocesamiento diferentes sin obligar al visitante a esperar una pantalla de carga cada vez que cambiaba de sección. La navegación debía sentirse continua, como si todas las partes formaran un único sistema.

El cambio de WebGPU a WebGL durante la etapa de producción

El proyecto comenzó utilizando WebGPURenderer, la implementación de Three.js orientada a WebGPU, junto con TSL, el lenguaje de shaders basado en nodos de Three.js. La combinación ofrecía una arquitectura moderna y modular. En vez de mantener por separado múltiples archivos GLSL, materiales, cálculos para la unidad de procesamiento gráfico y efectos de posprocesamiento, el equipo podía describir los recursos mediante grafos de nodos escritos en JavaScript.

El motor se encargaba luego de generar los shaders apropiados según el sistema de renderizado utilizado. Esta forma de trabajo permitía organizar los efectos como piezas reutilizables y facilitaba la experimentación con materiales y operaciones visuales. También representaba una oportunidad para probar WebGPU en un proyecto real destinado a usuarios finales, algo relevante porque la tecnología promete un acceso más directo y eficiente a las capacidades de las tarjetas gráficas modernas.

Sin embargo, el problema principal no apareció cuando las escenas ya estaban funcionando, sino durante el inicio. La aplicación debía recorrer los grafos de nodos de TSL, producir los shaders correspondientes y compilar las canalizaciones gráficas antes de mostrar el primer cuadro. En el equipo de referencia, ese proceso podía acercarse a los veinte segundos. Para una página web, incluso una experiencia visualmente sofisticada, ese tiempo de espera resultaba difícil de justificar.

Versiones posteriores de Three.js mejoraron de manera considerable la compilación mediante un mejor almacenamiento en caché de los tipos de nodos. Los análisis publicados por el propio proyecto muestran una aceleración aproximada de tres veces en esa etapa, asociada en buena medida al trabajo de Renaud Rohlinger. Pero esas mejoras todavía no estaban disponibles cuando Cerebrium debía publicarse.

Por ese motivo, el equipo tomó una decisión pragmática: regresar a WebGLRenderer. La migración no implicó descartar WebGPU como tecnología. Fue una elección vinculada con la madurez del ecosistema en ese momento y con la necesidad de ofrecer tiempos de arranque previsibles. Para una experiencia comercial, la estabilidad percibida por el visitante puede ser más importante que utilizar la herramienta más nueva.

Más control manual sobre materiales y efectos

La lógica general del renderizado se mantuvo relativamente parecida, pero varios componentes debieron hacerse explícitos. Los materiales basados en nodos fueron reemplazados por materiales tradicionales de Three.js, ampliados mediante onBeforeCompile() para incorporar código GLSL personalizado. Los shaders de cálculo utilizados para simular partículas se transformaron en un sistema GPGPU de tipo ping-pong, apoyado en texturas de punto flotante.

El posprocesamiento también cambió. El grafo de efectos se reconstruyó con EffectComposer y varias pasadas GLSL diseñadas específicamente para el proyecto. Esta adaptación permitió recuperar la velocidad de inicio, aunque obligó a recalibrar el resultado visual. Dos shaders pueden perseguir la misma idea y producir imágenes diferentes, sobre todo cuando intervienen bloom, niebla, gradientes, iluminación y color.

La migración exigió ajustar la intensidad del brillo, la densidad de la atmósfera y varios tonos de los materiales para conservar la dirección artística original. El caso demuestra que una sustitución tecnológica no siempre es transparente: cuando una escena depende de efectos acumulativos, pequeñas variaciones en cada capa pueden modificar notablemente la apariencia final.

Cómo se construyeron las redes luminosas que parecen estar en movimiento

Uno de los recursos visuales más destacados es una red de caminos brillantes que parece transportar energía o información. La ilusión no surge porque las geometrías se desplacen. Los recorridos son mallas estáticas y el movimiento se simula completamente desde el shader.

Cada camino fue desplegado en coordenadas UV de manera que el eje vertical recorriera la línea de un extremo al otro. Luego, el shader mueve una máscara estrecha de opacidad a través de ese eje. El desplazamiento genera la apariencia de un pulso que atraviesa la red. El ancho y la caída de la máscara determinan si el resultado se percibe como una señal definida o como una estela de energía más difusa.

Para evitar una animación mecánica, cada trayecto recibe parámetros ligeramente distintos. Esa variación introduce pequeñas diferencias de velocidad, intensidad y desvanecimiento, suficientes para que el conjunto parezca orgánico. La visibilidad de las líneas también se limita según su distancia respecto de la cámara, de modo que la red se revela progresivamente mientras el recorrido avanza.

El equilibrio visual fue delicado. Las líneas debían tener suficiente luminosidad para parecer emisoras de luz, pero el bloom no podía cubrir sus detalles ni convertir toda la escena en una mancha violeta. Durante el desarrollo, un inspector permitió modificar casi todos los parámetros y encontrar una combinación que mantuviera la legibilidad de la geometría.

Iluminación, optimización geométrica y continuidad entre escenas

La atmósfera púrpura del proyecto se reforzó con un HDRI personalizado de Poly Haven utilizado como mapa de entorno. Además de generar reflejos sutiles, esta fuente ayudó a unificar escenas que, por su estructura, eran diferentes. La coherencia de la iluminación resulta fundamental en una experiencia con varios ambientes: si cada sección utiliza una lógica cromática aislada, el sitio puede sentirse como una colección de demos sin relación.

La iluminación no podía hornearse porque muchas escenas incluían objetos animados. Cada luz tuvo que reconstruirse directamente en Three.js. Para facilitar el posicionamiento, se exportaron cubos auxiliares desde Cinema 4D. Esos objetos conservaron la ubicación y la orientación de las luces, permitiendo reproducir dentro del motor la configuración creada en la herramienta 3D.

El proyecto también enfrentó una dificultad habitual en la entrega de modelos para la web. Las curvas de la red requerían una geometría muy subdividida, especialmente en los segmentos redondeados. Optimizar la escena completa con Draco reducía el peso del archivo, pero también disminuía la cantidad de polígonos y producía facetas visibles en las curvas.

La solución fue dividir el modelo en dos partes y optimizar cada malla por separado. Una contenía los objetos auxiliares, los caminos de luz y una sección de la red; la otra reunía el resto de la geometría. La separación se ubicó en una zona imperceptible para el usuario. Así fue posible administrar y transmitir los recursos de manera más eficiente sin sacrificar la suavidad visual de los recorridos.

Las cámaras, por su parte, fueron animadas y horneadas directamente desde Cinema 4D. Este procedimiento permitió conservar con precisión el encuadre, la duración, la aceleración y la sincronización de los movimientos. También evitó diferencias de interpolación entre el programa de diseño y el navegador, un aspecto que puede afectar la sensación de continuidad en transiciones muy controladas.

Un escudo de seguridad que responde a cada movimiento del usuario

La sección dedicada a la seguridad evita el recurso habitual del candado. En su lugar, presenta un objeto central rodeado por una esfera protectora casi invisible. La mayor parte de su apariencia se basa en un efecto Fresnel: las superficies orientadas de frente hacia la cámara permanecen discretas, mientras que los bordes observados en ángulo reciben mayor intensidad luminosa.

Una capa de ruido procedural animado modifica suavemente la intensidad del efecto para impedir que el escudo parezca completamente estático. Sobre la esfera se proyecta además una cuadrícula hexagonal, combinada de forma aditiva con el Fresnel. El bloom completa la percepción de que la protección genera energía propia.

La interacción agrega una segunda capa narrativa. Un raycaster detecta continuamente la posición del cursor sobre la esfera y la registra en una textura temporal. El shader utiliza esa información como una máscara dinámica para iluminar los hexágonos cercanos al punto de contacto. Luego, la intensidad disminuye de forma gradual.

El escudo no reacciona como un botón convencional que se enciende y apaga de inmediato. Conserva durante un breve período la memoria de la interacción, creando la sensación de que recibe una fuerza, la distribuye por la superficie y finalmente la disipa. Esa respuesta ayuda a representar la seguridad como un sistema activo y no como un símbolo visual aislado.

Qué cambia para el SEO cuando una página depende de una experiencia 3D

La propuesta de Cerebrium también plantea una cuestión concreta para la visibilidad orgánica: una experiencia visual no puede reemplazar la información que los buscadores y los usuarios necesitan para comprender el producto. Las escenas 3D pueden mejorar la diferenciación, la recordación y la percepción de calidad, pero los conceptos principales deben estar expresados en HTML accesible, títulos claros, textos descriptivos y contenidos que respondan consultas reales sobre infraestructura de IA.

Una implementación de este tipo debe cuidar especialmente el rendimiento inicial. Si el navegador necesita descargar demasiados modelos, compilar shaders complejos o ejecutar múltiples efectos antes de mostrar contenido útil, pueden empeorar las métricas de experiencia de página y aumentar el abandono. La decisión de volver a WebGL muestra que la tecnología visual debe evaluarse junto con el tiempo de interacción, el consumo de memoria, la compatibilidad entre dispositivos y la conexión disponible.

Para una empresa de software, la arquitectura más conveniente puede combinar una presentación 3D progresiva con una capa de contenido tradicional. El texto introductorio, las características, los casos de uso, la documentación y las respuestas frecuentes deberían cargarse de forma comprensible incluso si el visitante desactiva la animación o utiliza un teléfono de menor capacidad. En ese sentido, una estrategia de inteligencia artificial y posicionamiento web puede integrar la narrativa visual con páginas indexables dedicadas a cada servicio, tecnología y necesidad del público.

También resulta importante describir las imágenes y escenas mediante textos alternativos cuando corresponda, evitar que la navegación dependa exclusivamente del cursor y ofrecer controles que respeten las preferencias de movimiento reducido. El diseño inmersivo puede convivir con una buena optimización para buscadores si se construye como una capa progresiva y no como el único canal de comunicación.

La decisión técnica detrás de una experiencia que debe vender infraestructura

El caso Cerebrium deja una enseñanza aplicable a sitios de tecnología, agencias y negocios digitales: elegir entre WebGPU y WebGL no depende solo de cuál ofrece mejores capacidades en teoría. La decisión debe contemplar el momento del proyecto, la compatibilidad disponible, los tiempos de compilación, las herramientas de depuración y la previsibilidad del resultado en producción.

WebGPU y TSL ofrecen una base atractiva para crear sistemas visuales modulares, especialmente cuando se necesita trabajar con muchos efectos y operaciones gráficas complejas. WebGL, en cambio, continúa siendo una alternativa sólida cuando el objetivo prioritario es asegurar una puesta en marcha rápida y una experiencia estable en una variedad amplia de navegadores y equipos.

El trabajo de KOKI-KIKO, con estrategia y producción de Kim Levan, dirección creativa y diseño de Louis Paquet, arte 3D de Célia Lopez y desarrollo de Deven Caron y Pier-Luc Cossette, junto con la implementación WebGL de Mathis Biabiany, muestra que una interfaz tecnológica memorable exige coordinación entre varias disciplinas. La innovación no está únicamente en el efecto final, sino en la capacidad de convertir conceptos técnicos en interacciones comprensibles, eficientes y coherentes con los objetivos comerciales de una plataforma de inteligencia artificial.