CONCEPTOConcepto: no es un encargo de cliente
RACKLIGHT: un sistema operativo de almacén en 3D que se puede recorrer, hecho como concepto
RACKLIGHT es un sistema de gestión de almacenes para Norvane DC-02, un almacén de logística a terceros que no existe. VITON13 lo creó como concepto para mostrar cómo es un producto de operaciones cuando la interfaz es el propio almacén: 1656 ubicaciones como palés 3D en vivo, una búsqueda que vuela a cualquier ubicación, un optimizador de rutas de picking, recepción por escáner con regla de ubicación e IA de demostración para el stock, que son reglas y estadística en el navegador y así se indica.
Abrir el proyecto
- Ubicaciones dibujadas como palés 3D en vivo, coloreadas según el stock o la frecuencia de picking
- 1656
- SKU ficticios, cada uno con 90 días de demanda y una previsión a 28 días
- 400
- Ruta de picking mediana frente a la hoja de pedido, 1140 pedidos generados (unos −9 % frente a una hoja ordenada por ubicación)
- −32 %
- Primer script con gzip; la escena de three.js (154 KB) se carga después de la interfaz
- 10 KB
Tarea
VITON13 crea productos conceptuales para mostrar su alcance donde aún no tiene un proyecto de cliente que enseñar. RACKLIGHT es el de operaciones: un WMS para Norvane DC-02, un almacén inventado de logística a terceros con 400 productos, 38 pedidos de salida al día, cinco muelles de entrada, cinco de salida y una cámara frigorífica. La empresa, sus clientes, transportistas, proveedores y todas las cifras son ficticios, y la demo lo dice en una etiqueta fija en pantalla.
El encargo nos lo pusimos nosotros. El software de almacén suele mostrar el stock como tablas de códigos, así que la interfaz debía ser el propio almacén, con cada palé a la vista y cada acción reflejada en la nave, sin convertirlo en un escaparate en 3D. Tenía que incluir flujos que un jefe de turno reconocería, enseñar los números de cada sugerencia y funcionar en inglés y en ruso, en portátil y en móvil.
Qué hicimos
El almacén es una nave de 108 × 80 m dibujada con three.js y una cámara ortográfica isométrica: 12 pasillos principales con zona de picking y reserva, 4 pasillos en una cámara frigorífica acristalada, recepción, puestos de embalaje con cinta transportadora, carriles de expedición y 10 muelles con camiones. Las 1656 ubicaciones son palés instanciados coloreados según el stock, o según la frecuencia de picking en el modo de mapa de calor. Nueve preparadores y cinco carretillas recorren el grafo de pasillos, los camiones atracan en los muelles según el horario y, al pasar el cursor por una ubicación, se ven su SKU, la cantidad y el llenado.
Sobre él trabajan cuatro herramientas. La búsqueda (⌘K) abarca los 400 SKU, pedidos y códigos de ubicación; lleva la cámara hasta la ubicación, la ilumina con un haz y traza una ruta desde el preparador más cercano. El optimizador compara el orden de la hoja de pedido con una ruta construida por vecino más cercano y 2-opt sobre las distancias mínimas entre pasillos, y manda a un preparador a recorrerla. La regla de ubicación del escaneo en recepción elige el hueco según la rotación —los artículos rápidos, junto a embalaje; los lentos, en los niveles altos de reserva; los refrigerados, en la cámara— mientras una carretilla lleva allí el palé. La cuarta es la inteligencia de inventario.
Alrededor de la escena hay paneles de indicadores (ocupación por zona, entradas y salidas del día, precisión de picking, pedidos pendientes antes del próximo corte del transportista, un flujo de eventos en vivo y una línea de tiempo de muelles), una tabla de inventario con filtros y una gráfica de 90 días por SKU, una cola de pedidos por estado y corte, y un diagrama de Gantt para los 10 muelles. Cada cambio se guarda en el navegador de quien visita, y un botón restablece el entorno de prueba.
Cómo funciona
La inteligencia de inventario es IA de demostración, y la interfaz lo dice: reglas y estadística en el navegador, no un modelo de lenguaje. Cada SKU tiene 90 días de demanda generada con estacionalidad semanal; la previsión usa índices estacionales de las últimas ocho semanas y una tendencia lineal amortiguada, un stock de seguridad con z = 1,65 fija el punto de pedido y cuatro listas señalan stock bajo (se lanza un pedido de compra y un camión atraca), sobrestock, stock muerto y cambios de ubicación con los metros que ahorrarían. Cada acción cambia la escena 3D: los palés llegan, se mueven, se tiñen de violeta para liquidación o salen.
Todo es procedural: sin modelos 3D, sin texturas de imagen y sin peticiones externas. La interfaz es JavaScript sin framework empaquetado con esbuild y se pinta primero; la escena de three.js es un bloque aparte que se carga después. Los palés son mallas instanciadas con un único material modificado para las juntas de las cajas, el atenuado, el brillo del mapa de calor y el encendido de luces de la intro; las sombras solo se recalculan cuando cambia el stock, la resolución baja si los fotogramas se ralentizan y el renderizado se pausa en una pestaña oculta. En el móvil hay una escena más ligera con menos agentes, una franja de indicadores, paneles inferiores y una barra de pestañas.
Qué existe hoy
Hoy existe un concepto que funciona en tarasovvitalii.com/demos/racklight/: cuatro vistas, cuatro herramientas y unas 230 cadenas de interfaz en cada idioma, inglés y ruso. El 28 de septiembre de 2026 medimos la build de producción: el primer script pesa 10 KB con gzip (tras rehacer el arranque), la escena de three.js 154 KB con gzip y la build completa 1,0 MB, sin archivos de imagen, modelos ni texturas. En Chrome headless en un MacBook Air con Apple M5, a 1600 × 1000 con escala Retina, la escena mantuvo 55–60 fps con el reloj de fotogramas por defecto de 60 Hz en seis estados y, sin límite, llegó a 160–200 fps, unos 5–6 ms por fotograma.
También ejecutamos el propio código de rutas de la demo sobre los 1140 pedidos que genera en 30 días. La ruta optimizada fue, en mediana, un 32 % más corta que recorrer la hoja de pedido línea a línea, y el pedido de las capturas baja de 409 m a 211 m. Frente a una hoja simplemente ordenada por código de ubicación, la ganancia mediana ronda el 9 %, la comparación más justa para un almacén que ya ordena sus listas de picking.
Qué no demuestra
RACKLIGHT es un concepto que VITON13 creó para mostrar su alcance, no un producto encargado. Norvane DC-02, sus clientes, transportistas, proveedores, productos y todas las cifras son ficticios y se generan en el navegador: detrás no hay usuarios, ni clientes, ni almacén, ni ingresos, y no demuestra nada sobre la adopción ni el ahorro en una operación real. La IA de demostración son reglas y estadística en el dispositivo de quien la visita, no un modelo entrenado, y nunca ha visto demanda real.
Nada se conecta a un WMS, ERP, escáner de códigos de barras o sistema de muelles reales; el plano está fijado en el código en lugar de importarse de planos, y las rutas ignoran atascos, carros y preparación por lotes. Los fotogramas proceden de una sola máquina con Chrome headless en un solo día, y la revisión de Lighthouse de abajo se midió en la dirección real el 28 de septiembre de 2026, con un móvil simulado y no en dispositivos reales. La demo está fuera de los buscadores a propósito.




Revisión SEO
Medido en la dirección real el 28 de septiembre de 2026, después de rehacer el arranque. Lighthouse (cinco ejecuciones por dispositivo, medianas, en un MacBook con una carga media de 3 a 9) dio un rendimiento de 86 en móvil (LCP 3,3 s, 0 ms de bloqueo, 0,45 MB) y de 99 en escritorio (LCP 0,5 s), accesibilidad 91 y 92 y buenas prácticas 100 en ambos; en nuestro recorrido de prueba la demo cargó con 0 infracciones de CSP y 0 errores de consola. La primera medición, local y con la máquina muy cargada antes del cambio, dio 37 y 69. El SEO es 63 porque la demo lleva noindex, nofollow: la página pensada para los buscadores es la ficha del caso en el portafolio.
Revisado el 28 de septiembre de 2026: 5 páginas renderizadas en Chrome tal como las ve un rastreador, y Lighthouse 13 en la portada.
Lighthouse, portada
- Rendimiento
- Móvil86Escritorio99
- Accesibilidad
- Móvil91Escritorio92
- Buenas prácticas
- Móvil100Escritorio100
- SEO
- Móvil63Escritorio63
Comprobaciones de página y SEO técnico
- Títulos de página únicosfalta2/5
- Título de 30–65 caracteresfalta1/5
- Metadescripción de 70–170 caracteresfalta0/5
- Un solo H1 por páginaparcial4/5
- Idioma de la página declaradocorrectoen
- Diseño móvil sin desplazamiento lateralcorrecto390 px
- Imágenes con texto alternativocorrecto0 img
- Enlaces internos rotoscorrecto0
- URL canónicafalta0/5
- Open Graph: título e imagenfalta0/5
- Datos estructurados (JSON-LD)falta0/5
- sitemap.xml y robots.txtparcial1/2
Se revisaron 5 documentos, las 4 vistas de la única dirección y su página 404, en Chrome headless a 390 px. En orden: el idioma declarado (en, y ru tras el cambio), sin desplazamiento lateral a 390 px y 0 enlaces rotos entre 7 destinos; no hay ninguna etiqueta <img> que describir, porque el almacén es WebGL y los iconos son SVG. En parte: las vistas de inventario, pedidos y muelles y la página 404 tienen un H1; la vista del almacén 3D, ninguno. Falta: las 4 vistas comparten un título de 77 caracteres y una descripción de 218, y no hay canonical, ni imagen Open Graph, ni JSON-LD. robots.txt está en la raíz del dominio; la demo queda fuera del sitemap.xml a propósito.
El punto débil de la primera medición era el rendimiento, y la causa se conocía: casi todo el tiempo de bloqueo se iba en construir la escena 3D de una vez. Rehicimos el arranque para que cada paso ceda el turno al navegador, los shaders se compilen de forma asíncrona y el primer fotograma se construya por partes; en nuestra propia prueba, con la CPU cuatro veces más lenta, el tiempo de bloqueo bajó de unos 1,3 s a unos 20 ms, y la dirección real obtiene ahora 86 en móvil sin tiempo de bloqueo. Lo siguiente: dar más contraste al pequeño contador de un botón de herramienta y agrandar el enlace de la insignia «producto ficticio», que restan 8–9 puntos de accesibilidad, y dar a cada vista su título y su descripción.
Servicios que muestra este caso
Describe la tarea en la página del servicio; el alcance, el plazo y el precio por escrito llegan en un día laborable.
Hablar de un proyecto similarMás casos
Todos los casos
CONCEPTOConcepto: no es un encargo de cliente
HOURLINE
Producto conceptual · Aplicación web · inglés, ruso · 2026
HOURLINE es una plataforma de reservas online que VITON13 creó como concepto, presentada a través de una red ficticia de tres estudios premium en Moscú, Dubái y Londres. Una sola demo reúne las dos caras: la página donde el cliente reserva una cita desde el móvil en segundos y el back office donde el estudio lleva su calendario, ve el riesgo de inasistencias, llena los huecos y consulta sus cifras. Todo funciona en el navegador con datos generados.
Leer el caso →
CONCEPTOConcepto: no es un encargo de cliente
SOLVENT
Producto conceptual · App web · inglés, ruso · 2026
SOLVENT es un producto de flujo de caja que VITON13 creó como concepto, mostrado con la contabilidad de Kite & Co., un estudio ficticio de diseño e imprenta de 14 personas. Le dice al dueño cuánto dinero hay, para cuántos meses alcanza y cómo pintan los próximos 18 meses, y le deja probar una decisión antes de tomarla: ocho palancas recalculan la previsión al instante y una cascada muestra qué cambia cada una. Todo funciona en el navegador con datos generados, y no es asesoría financiera.
Leer el caso →
CONCEPTOConcepto: no es un encargo de cliente
Möbius School & Institute
Web conceptual · three.js · inglés, ruso · 2026
Möbius es un colegio e instituto ficticio para alumnos de 5 a 25 años, y esta es la web que VITON13 creó para él como concepto para colegios, institutos y universidades. En la portada, 40 tarjetas de historias recorren una banda de Möbius real en three.js; detrás están la película «Quiénes somos», los programas, las herramientas de admisión, un mapa del campus y My Möbius, una demo funcional del área personal para alumnos, familias y profesores.
Leer el caso →