Monolito

Última actualización: 24-01-2026 07:37 PM

pVISOR - Contexto (Monolito)

1) Qué es pVISOR

pVISOR es un visor 3D en WebGL construido en Unity que permite previsualizar assets de videojuegos con el mismo look final del motor (materiales, shaders, iluminación y postprocesado).

No es un “viewer de malla” genérico: la intención es que el resultado final sea la experiencia real del motor, con controles de cámara tipo editor para inspección.

2) Motivación y problema a resolver

• Las plataformas de publicación típicas (p. ej. visores web/Sketchfab) permiten ver un modelo, pero no replican fielmente el look final dentro de Unity (Shader Graph, luces, volúmenes, pipeline, ajustes de cámara, etc.).

• Como artista 3D + artista técnico + desarrollador, el valor del portafolio aumenta si el asset se presenta:

  • Con setup completo de juego (URP/pipeline, luces, post, materiales)
  • Con interacción mínima (inspección, encuadre, reset, navegación)
  • Y, cuando aplique, con mecánicas simples (dependiendo de la pieza)

Resultado buscado: un build WebGL publicable en Itch (hosting) y embebible en la web personal, donde cualquiera pueda abrir y “mirar” el asset como si estuviera en el editor, pero en Play.

3) Filosofía / Principios guía

1. Fidelidad visual primero.

   • El viewer existe para mostrar arte “final” en motor. Rendimiento importa, pero no a costa de romper el look.

2. Controles familiares (Scene View).

   • La cámara debe sentirse como el editor de Unity: orbit/pan/zoom + frame (F) + reset.
   • El comportamiento debe ser consistente y predecible.

3. Producto publicable en Web (WebGL), no demo interna.

   • Debe funcionar como experiencia web: abrir → inspeccionar → cerrar.
   • Se publica en Itch para alojamiento y se embebe en la web personal.
   • Debe ser estable y optimizado.

4) Alcance

• Visor 3D con:

  • Orbit (rotación alrededor de un pivote)
  • Pan (desplazamiento lateral/vertical)
  • Zoom (acercar/alejar; coherente)
  • Dolly (zoom por drag; feeling tipo editor)
  • Frame (F): encuadrar el/los objetos de interés
  • Reset (R): volver a una vista por defecto
  • Menu (M): menu lateral oculto, para opciones variadas

• Soporte para múltiples objetos en escena y encuadre robusto (no basado en “un punto” aislado).

• Publicación WebGL en Itch (hosting) para embebido en web personal.

5) No-objetivos

• No es un editor completo.
• No requiere sistemas complejos (inventario, combate, etc.), salvo que una pieza concreta lo justifique.
• No se busca “micro-optimización” prematura.
• No se prioriza build descargable (PC) en este proyecto. El objetivo es WebGL.

6) Usuario objetivo y criterio de éxito

Usuario objetivo: reclutadores, clientes y otros artistas/desarrolladores que necesitan evaluar la calidad del asset.

Éxito significa:

• El viewer abre rápido y es entendible.
• La cámara se siente “como editor” (sin comportamientos raros).
• El look del asset coincide con la intención artística/técnica.
• El build se puede publicar y ejecutar sin fricción.

7) Requisitos de experiencia (UX) del visor

• Presentación limpia por defecto: sin UI/overlays permanentes. El foco es el arte y su lectura visual, sin botones ni elementos que contaminen la imagen.
• Interacción basada en atajos: las funciones del visor se operan principalmente mediante shortcuts y gestos estándar; si existe ayuda o referencia de controles, debe ser invocable y ocultable (no persistente).
• Navegación estilo Unity, con restricciones WebGL: la cámara debe replicar el muscle memory del Scene View (orbit/pan/zoom/frame) dentro de lo que permite el navegador (evitando teclas reservadas por OS/browser y combinaciones frágiles).
• Comportamiento estándar y estable: mismas acciones producen siempre el mismo resultado; operaciones críticas (p. ej. Frame/F) deben ser deterministas y consistentes.
• Parámetros de cámara controlados y configurables por asset: límites de pitch, distancia mínima/máxima y clipping deben estar definidos, ser robustos en extremos y ajustables según el contenido mostrado.

8) Requisitos de fidelidad visual

• Objetivo: el visor debe reproducir el look final de Unity con fidelidad (modelos, materiales, shaders, iluminación, postprocesado, skybox y pipeline de render), sin degradaciones “accidentales” por configuración.

• Responsabilidad compartida (contenido + visor):

  • Contenido: define la intención artística del asset (malla, materiales/shaders, texturas, valores, setup base).
  • Visor: aporta el entorno de render y la presentación (pipeline, quality, lighting/post, skybox, URP/HDRP settings, y demás ajustes globales).

• Presets por tipo de asset: el proyecto mantiene configuraciones/presets de calidad y render para distintos objetivos (p. ej. “realista”, “optimizado”, “neutral”), y se selecciona la adecuada antes de compilar/publicar.

• Punto de integración claro: el contenido se conecta en un punto explícito de la escena (p. ej. ModelRoot) y debe funcionar con el entorno del visor sin dependencias implícitas.

• Registro de ajustes específicos: cualquier ajuste particular requerido por una pieza (preset usado, overrides de render/lighting/post, consideraciones especiales) se documenta en su sección correspondiente (normalmente en Modularidad).

9) Estándares técnicos generales

Nota: el detalle de implementación vive en Modularidad. Aquí solo se declaran reglas globales.

• Motor objetivo: Unity 6.3 LTS (6000.3).

• Input: Unity Input System (nuevo). No usar UnityEngine.Input.

  • Baseline: com.unity.inputsystem Último.

• Arquitectura (estándar actual): RED (Rt–Ev–Dt) + VContainer.

  • Rt: RtLifetimeScope (Composition Root + DI).
  • Ev: EventsSO (señales sin payload; acciones como FrameRequested, ResetRequested).
  • Dt: DataSO (estado de input y estado runtime en memoria).

• Convención crítica: prefijo Rt se reserva para clases LifetimeScope.

• Sin singletons estáticos y sin service locator.

10) Plataforma objetivo y distribución

• Plataforma obligatoria: WebGL.
• Distribución: publicación en Itch como hosting y embebido en la web personal.
• Restricción operativa: todo lo que se implemente (controles, arquitectura, configuración) debe ser compatible con WebGL2.

---

Este documento define el “por qué” y el contrato global. El “cómo” detallado vive en pVISOR — Modularidad (Monolito). Las tareas y prioridades viven en pVISOR — Backlog (Monolito).