Sobre 3dsmax

[BeRSeRKeR]

 Bueno, tal y como exporto yo en estos momentos, la malla queda totalmente limpia de vértices redundantes. Lo que pasa es que es un proceso lento. Por suerte, y como ya he dicho, la mayoría de las veces esta regeneración de la geometría no es necesaria por lo que en la mayoría de los casos la exportación se realiza de forma rápida.

Te he enviado la función que utilizo para regenerar la malla para que le eches un vistazo y a ver si se te ocurre alguna optimización que acelere el proceso.

Saludos

[Ithaqua]

 Hola Berserker!

Sorry por responder tan tarde pero últimamente estoy algo desconectado de los foros de stratos (desde el nuevo redesign, no se si tendrá algo que ver :) )
Yo he tenido bastantes peleas con lo de la consolidación de malla, y hasta hace un par de meses mi código tardaba mucho en construir la malla consolidada (lo de equiparar número de vértices a número de coordenadas de mapeado etc). Y era muy engorroso porque yo exporto bastantes canales de mapeado (3 en el peor caso). Eso unido a las normales, a los vertex colors y a los vértices en sí puede llegar a un caos tremendo.

La solución la tuve cuando implementé los smoothing groups de MAX para calcular correctamente los vertex normals (ya sabéis, un vértice puede tener varias normales según la cara desde la que se accede) y la escena queda totalmente distinta a hacerlo con o sin los smoothing groups. Mil veces mejor.
El caso es que una vez que implementé tener en cuenta el smoothing group de cada cara el hecho de luego procesar el mapeado etc para equiparar vértices salió 'gratis'. Y la consolidación de malla ahora es prácticamente instantánea aparte de optimizar mucho más la malla en cuanto a nº de vértices que antes.

Es un poco tarde para poner la explicación del algoritmo, pero no tengo problema en enviarte el código por mail si te interesa y que le eches un vistazo.

      Saludos!

Ithaqua.


P.D  Yo anduve durante bastante tiempo buscando solución a ésto y pensé en usar el IGameInterface o Flexporter pensando que realizaban esa tarea, pero el primero ya ví que no lo hace y el segundo creo que solamente tiene en cuenta el canal básico de mapeado, y no los demás que pueda haber. No se si tampoco calcula las normales teniendo en cuenta los smoothing groups...

[Ithaqua]

 Por cierto, ya se discutió un tema parecido hace bastante tiempo en este post.

[MChiz]

 Hola Ithaqua:

Yo consegui hacer que me exportase verdaderamente rapido, pero ahora estoy intentando exportar dos juegos de coordenadas de texturas y es un coñazo. Y lo mismo con lo de las normales... no entiendo para que te sirven los smoothing groups. Lo entiendo para las normales, pero para el mapeado?? Yo si que te pediria, porfavor, algun codigo de ejemplo.

Muchas gracias!

[DraKKaR]

 Los smoothing groups valen para suavizar las normales de una zona de un objeto selectivamente, sin necesidad de ke todo este suavizado o no.

[MChiz]

 

no entiendo para que te sirven los smoothing groups. Lo entiendo para las normales, pero para el mapeado??

No era esa mi duda ; )

[BeRSeRKeR]

 Hey Ithaqua. Te he dejado por mensaje privado mi dirección.

Gracias.

[Ithaqua]

 Mchiz: no tienen nada que ver pero resulta que el algoritmo que usé para reconstruir la malla según los smoothing groups (para que al calcular las normales hiciera las medias como debiera) permitía que introdujera sin problemas una parte de mesh consolidation.

El algoritmo funciona básicamente así:

---------------------------
Smoothing groups: Van por cara. A la hora de calcular las normales si un vértice pertenece a varias caras antes lo que hacíamos era que su vertex normal era el promediado de esas caras. Con smoothing groups se calcula la media _solamente_ para caras que tienen el mismo smoothing group.
---------------------------
Algoritmo

Código [Seleccionar] Expand


-Declarar los diferentes std::vector que contendrán la malla final procesada (vertices, normales, maps...).
-Declarar vector con la información de los smoothing groups.
Es una lista en la que cada elemento tiene a su vez otra lista con las distintas apariciones de ese vértice pero con diferente smoothing group. (vector<vector<struct{indicevertice, smoothingroup}>>)
Estos vértices deben ser los replicados para calcular correctamente las normales, ya que no intervienen en la media a la hora de promediar las face normals para el vértice.

for(caras)
{
 smoothing group = cara.smoothinggroup.
 int v[3]; // contendrá los índices de nuestra nueva cara

 for(vertices en cara)
 {
    Para este vertice, buscar si ya está en la lista con este smoothing group.

    if(no encontrado)
    {
        1-Añadir el vértice (indice) y su smoothing group a la lista de vectores.
        2-Generar nuevo vértice en los vectores de la malla final procesada,
        con su información de mapeado etc y meter el índice que ha ocupado en v[]
    }
    else
    {
        // Este vertice con su smoothing group ya ha sido procesado pero tenemos que comprobar
        // si el resto de información (mapeado, vcolors, etc) es la misma.

        bool mismo = true;

        if(mapeado1 no es el mismo) mismo = false
        if(mapeado2 no es el mismo) mismo = false
        ....
        if(caracteristica n  no es igual) mismo = false

        if(mismo == true)
       {
           // Ya tenemos este vértice en nuestra lista, ahora se accede a él desde diferente cara
           // Lo que hacemos es simplemente indexar el mismo en v[]
       }
       else
       {
           // El vértice es geométricamente el mismo, pero sus mapeados etc son distintos
           // Generamos un nuevo vértice como en el paso 2 de if(no encontrado) y lo indexamos en v[].
       }
   }

   Añadir cara(v) a la lista de caras.
}


-------------------

P.D Berserker: Te envío el código con la explicación por mail :)

[BeRSeRKeR]

 Muchas gracias Ithaqua

[Ithaqua]

 Por cierto,

Mchiz: El esqueleto de ese código sirve para procesar los smoothing groups, pero como puedes ver en el if(encontrado) { } else { AQUI }  se procesa el tema de que un vértice puede tener distintos mapeados según la cara. En caso de tenerlo hay que replicarlo, porque sino saldría mal.

En definitiva, MAX podría hacer ese curro por nosotros pero... :)

[BeRSeRKeR]

 Y digo yo.

Si MAX tiene que trabajar internamente con uns lista de vértices, colores, normales, etc "compatible" con OpenGL o Direct3D (porque si no no podría renderizar los objetos correctamente, claro). ¿Por qué demonios no nos dan ya la lista "correcta"?. ¡O por lo menos que den las dos posibilidades!

Es que este tema es un coñazo, de verdad :D

Saludos

[MChiz]

 Muchas gracias Ithaqua! Tendre que mirar como 'estan hechos' los smoothing groups porque nunca los he tocado ;bbb
Gracias!!

[toni]

 Berseker, sobre los 36 vertices q salen en un cubo, la cosa es sencilla
6 caras* (2 triangulos/cara)* (3 vertices/triangulo) = 36 vertices, y esto te pasara siempre a menos q los vertices compartan uv's

Saludos,
Toni aka Tag

[BeRSeRKeR]

 En realidad, lo normal es que un cubo esté formado por 24 vértices (6 caras * 4 vértices por cara) y 36 índices...

Esos 36 vértices sería si no utilizas índices, lo cual es poco recomendable (un cubo vale, pero un modelo con miles de vértices...)

Saludos