Remplazo del Model

[AVinitzca]

Introducción

Hacer que las personas que cursan la materia carguen y dibujen sus modelos fue un tema sensible porque estos pueden venir muy variados (texturas, matrices, geometrías).
Esta discusión busca exponer los problemas del diseño planteado por MonoGame (XNA) y explorar alguna solución que tenga un buen balance entre abstracción, simplicidad y flexibilidad.

Qué es el Model

El Model de XNA y sus clases asociadas es una abstracción para los modelos 3D que tiene distintos componentes internos.
Por alguna razón las colecciones son inmutables y de tipos manejados por MonoGame.

Las clases más importantes son:

• Model: Un Model es la instancia asociada a un modelo (que puede venir desde un archivo procesado por el Content) y contiene una jerarquía de Bones (huesos).
  También tiene una colección de MeshParts.
• Bones: Un Bone es una matriz relativa que además contiene el contexto en la jerarquía.
  Tiene información como un índice, nombre, Bone base que contiene a la instancia, lista de ModelMesh a cuales aplica,
  matriz relativa y matriz absoluta una vez que es construida. El model puede decidir "aplanar" la jerarquía (calcular las matrices absolutas), aunque no está expuesto públicamente - sólo se usa internamente cuando se va a dibujar un modelo.
• ModelMesh: Un ModelMesh es un conjunto de ModelMeshParts y además apunta a un Bone en la jerarquía.
  Es un conjunto de geometrías afectadas por la misma matriz relativa.
• ModelMeshPart: Es una referencia a Vertex Buffer, Index Buffer y un Effect.
  Un ModelMeshPart es el elemento más básico de una geometría, aunque no tiene ownership del VB/IB.
• Effect: Asociado a un archivo de Shader, tiene una colección de técnicas, una técnica actual y parámetros.
  Tiene que asociarse la técnica actual antes de dibujar cualquier geometría y son referencias al recurso de la API gráfica.
• Technique: Una colección de pasadas, asociadas a la technique en un archivo Shader.

Problemas del Model

• Ya viene asignado a uno o varios BasicEffects. Quien lo usa tiene que aprender a pisarlo por ModelMeshPart,
  pero antes extraer sus texturas si las hay y encontrar una manera de mappearlas a las ModelMeshParts (generalmente un diccionario lo resuelve). Nota: Por ahora no pude importar un modelo y que reconozca más de una textura por ModelMeshPart. No está bien asumir que una mesh va a tener una única textura, aunque si es una limitación del importer tendríamos que cambiarlo.

• Es poco opaco a la hora de entender las diferencias entre Model, ModelMesh y ModelMeshPart: ¿Por qué hay tres objetos y por qué tienen esos nombres?
  Hay poca documentación al respecto que ayude a entender distintos casos. La persona que lo usa tiene que habituarse a los tipos listados arriba. Si bien contemplan casos flexibles, hacer geometría a mano (véase las primitivas) termina teniendo una interfaz distinta e incompatible.

• Esconde las matrices de mundo atrás de una interfaz poco amigable como los huesos.
  ¿Qué pasa si quiero dibujar un modelo en dos lugares distintos con valores distintos para sus huesos?
  Hay que copiar toda la jerarquía e iterarla.
  En el primer cuatrimestre del 2023 surgió este problema cuando un grupo quería dibujar varios autos iguales con distintos valores para los huesos en las ruedas.

• ¿Cómo dibujo un modelo? Hay mil formas, dependiendo de si hay una ModelMesh o varias, y dependiendo de si tiene múltiples matrices o no.
  Si bien esto es deseable, en el caso de que venga una geometría sola tenemos que revisar los huesos para saber si tiene transformaciones.
  Pero si queremos usar distintas matrices o parámetros por mesh es un poco más complejo.

• Si quiero extraer parte de una mesh para dibujarla aparte es difícil porque las colecciones de ModelMesh y ModelMeshParts son inmutables. Tendría que conocer los efectos de cada ModelMeshPart y preparar sus valores.
  Si quiero no dibujar una mesh no puedo sacarla de las colecciones, tampoco agregarlas. Sólo puedo crear Model nuevos.

Soluciones

Este problema tiene múltiples soluciones:

A

Hacer alguna utilidad que extraiga las geometrías con sus texturas y matrices, y que lxs estudiantes dibujen esto directamente y lo manejen como quieran.
Requiere que quien lo usa escriba más código pero se tiene más control y nos ahorramos de leer cualquier abstracción que hagamos.
Podemos hacer que el TP cero tenga modelos muy básicos, y que en el TP cuatrimestral tengan que escribir sus propios métodos para dibujar, algo que ya está pasando.
El código se va a parecer más a algo bajo nivel:

private Model _model;

private ModelInfo _modelInfo;

private Effect _effectOne;
private Effect _effectTwo;

private Matrix _worldOne, _worldTwo;

void LoadContent()
{    
    _model = Content.Load<Model>("tgcito");
    
    // Get associated ModelInfo for this Model, storing textures, matrices, geometries.
    _modelInfo = ModelExtensions.GetInfo(model);
}

void Draw()
{
    var viewProjection = Camera.View * Camera.Projection;
    
    // The user knows the model and knows what to expect from it
    // Matrices, textures, all should be passed for each geometry
    
    ref var geometryOne = _modelInfo[0];
    _effectOne.Parameters["WorldViewProjection"].SetValue(geometryOne.Matrix * _worldOne * viewProjection);
    _effectOne.Parameters["Texture"].SetValue(_modelInfo.Textures[0]);
    _modelInfo.Geometries[0].Draw(_effectOne);
    
    ref var geometryTwo = ref _modelInfo[1];
    _effectTwo.Parameters["WorldViewProjection"].SetValue(geometryTwo.Matrix * _worldTwo * viewProjection);
    _effectTwo.Parameters["Texture"].SetValue(_modelInfo.Textures[0]);
    _effectTwo.Parameters["NormalMap"].SetValue(_modelInfo.Textures[1]);
    _modelInfo.Geometries[1].Draw(_effectTwo);
}

struct ModelInfo
{
    public List<GeometryData> Geometries;
}

struct GeometryData
{
    public Geometry Geometry;

    public Matrix Matrix;
    
    // Can be null for a geometry if it has no textures
    private Texture[]? Textures;
}

Pros:

• Todo está expuesto para ser usado.
• Verbose AF.
• La gente no tiene que leer un apunte extra ni clases.
  Una utilidad te extrae todo lo que necesitas (o podemos hacer un processor custom).
• Es totalmente flexible a hacer cualquier cosa y lxs estudiantes pueden conocer el modelo directamente (cuántas geometrías tiene, etc).
• Hacer una utilidad para combinar todas las partes de un modelo en una geometría sola es muy fácil. Hiper amigable para usuarios que están aprendiendo.

Contras:

• Abre camino para que, de nuevo, haya mil maneras de dibujar un modelo, y dibujar un modelo implica conocer el efecto y qué hay que pasarle.
• Sacando el TP0, quien hace el TP tiene que conocer la estructura de los modelos que usa (que está expuesta, pero igual requiere verlo).

B

Hacer alguna utilidad que procese el Model y devuelva una abstracción, no asociada a un Effect, pero flexible
para permitir dibujar geometrías de una manera más controlada.
Esta solución no requiere que quien la usa conozca el modelo a dibujar en su totalidad, pero requiere un poco de conocimiento
sobre la abstracción en sí.
El código se vería así:

private ModelDrawer _modelDrawer;

private ModelDrawer _extraModelDrawer;

void LoadContent()
{    
    var model = Content.Load<Model>("tgcito");
    
    // Get a drawer ModelDrawer for this Model, in charge of drawing it.
    _modelDrawer = ModelDrawer.For(model);    
    
    // Can be transferable to other ModelDrawers if needed
    _extraModelDrawer = _modelDrawer.Extract(0 /* Pass an instance index, or multiple indices */);
    
    // The model can now be disposed.
    model.Dispose();
}

void Draw()
{
    var viewProjection = Camera.View * Camera.Projection;
    
    
    // Pass some random value into the effect
    _effectOne.Parameters["SomeFloatValue"].SetValue(_modelDrawer.Get<float>());
    
    // Users could even store matrices on the model drawer and modify them,
    // but that would mean that models are associated to one draw instance
    // and that is not always desired.
    // Although they could store a collection of matrices :)
    
    // The user can iterate the model
    foreach(var instance in _modelDrawer)
    {
        _effectOne.Parameters["WorldViewProjection"].SetValue(instance.Get<Matrix>() * world 
            * viewProjection);
            
        _effectOne.Parameters["Texture"].SetValue(instance.Get<Texture>());
        
        instance.Geometry.Draw(_effectOne);
    }
    
    world = _extraModelDrawer.Get<Matrix>();
    
    // The user can iterate the model
    foreach(var instance in _extraModelDrawer)
    {
        _effectTwo.Parameters["WorldViewProjection"].SetValue(instance.Get<Matrix>() * world 
            * viewProjection);
            
        _effectTwo.Parameters["Texture"].SetValue(instance.Get<Texture>(0));
        
        if(instance.TryGet<Texture>(1, out var texture)
            _effectOne.Parameters["NormalMap"].SetValue(texture);
        
        instance.Geometry.Draw(_effectTwo);
    }
    
    // ...
}


interface ModelDrawer : IDrawableData, IEnumerable<GeometryInstance>
{
    void Draw(Effect effect);
}

struct GeometryInstance : IDrawableData
{
    public Geometry Geometry { get; set; }
}

interface IDrawableData
{
    // Tells if this instance has this data type
    public bool Has<T>();
    
    // Gets the amount of data that this instance contains
    public bool GetCount<T>();
    
    // Gets a data element with an index
    public T Get<T>(int index = 0);
    
    // Tries to get the first data with the matching type
    public bool TryGetFirst<T>(out T data);
    
    // Tries to get the Nth data for the type
    public bool TryGet<T>(int index, out T data);
}

Pros:

• Bastante flexible.
• La persona que lo usa no tiene que tener total conocimiento sobre los modelos.
• Puede integrar huesos si queremos, podemos extender IDrawableData para devolver
  elementos en una jerarquía de huesos o exponer data especial.
• Se pueden separar geometrías según grupos.
• Puede contener cualquier cosa y el alumno puede conocer el modelo directamente (cuántas geometrías tiene, etc).

Contras:

• Abre camino para que, de nuevo, hayan mil maneras de dibujar un modelo, y dibujar un modelo implica conocer el efecto y qué hay que pasarle.
• Sacando el TP0, quien hace el TP tiene que conocer la estructura de los modelos que usa (que está expuesta, pero igual requiere verlo).

[LeandroJavierLaino]

Si bien ambas soluciones resuelven como renderizar de manera mas simple y legible un modelo. Para el objetivo de la materia y lo que buscamos que el alumno aprenda a bajo nivel, es mejor la solución A. Muestra todo lo que tiene que hacer para poder renderizar el model sin esconderlo atrás de interfeces.

[rejurime]

Comparto que Models no es la clase que necesitamos para realizar muchas cosas y es una clase que sirve para la gente que recién arranca y quiere hacer algo rápido. Este justamente no es nuestro objetivo como materia.
De las 2 opciones me inclino x la primera ya que creo que yendo por la segunda nos embarcamos en rumbo de algo similar a como debe haber empezado TGCViewer a crecer en el tiempo brindando mas y mas utilidades para que los chicos puedan hacer juegos y esto terminaba generando que muchas cosas quedan encapsuladas y no las terminaran aprendiendo.
Algo que charlamos en su momento y creo que fue el mayor punto de conflicto (que recuerde), es que si bien me gusta este enfoque, no quisiera en Samples no tener uno o dos ejemplos (podemos jugar con el nombre/seccion y que quede explicit) de como se harían las cosas a la MonoGame x si alguien le copa seguir su TP en la plataforma o alguien quiere jugar rápidamente, no creo que le haga mal a nadie dejar algo mostrando como seria hacerlo como el framework deja por default.

[rejurime]

No se si ModelExtensions es el nombre que mas me gusta 😜

[AVinitzca]

Con eso último no adhiero totalmente. Si elegimos exponer todo, o cualquiera de estas dos opciones, creo que habría que ir por ese camino. Si queremos dejar un Sample con algo de MG está bien, pero que sea un Sample sólo. Si tenemos que pensar por Sample si usar la forma de MG o no, abre camino para que la gente se inspire y vuelva a usar el BasicEffect.