Hola.

Aquí estoy de nuevo con una duda de HTML/Javascript.

Resulta que quiero que cuando un usuario le de al botón de imprimir que tengo en un informe generado en HTML, éste se oculte para que no salga en la impresión y que automáticamente vuelva a aparecer tras la misma.

Se supone que con ésto funciona:

Código [Seleccionar] Expand

onPrintButtonClicked()
{
   var printButton = document.getElementById('printButton');
   printButton.style.display = 'none';
   print();
   printButton.style.display = '';
}

Pero a mí no me funciona. Efectivamente desaparece y cuando confirmo el cuadro de diálogo de configuración de impresión me aparece de nuevo, pero aún así sale en la copia impresa.

Así que, ¿se os ocurre algo para solucionar ésto?.

Se me había ocurrido hacer un "sleep" durante un par de segundos o así pero me parece algo cutre. :P

Gracias.

Hola.

Estoy intentando hacer que una serie de tablas se vayan apilando en filas dentro de una capa (de ancho fijo).

Código [Seleccionar] Expand

<div style="width: 500px; height: 120px; border: 1px solid Silver; margin-left: 5px; overflow: scroll;">

   <table cellpadding="0" cellspacing="0" style="margin: 4px;">
       <tr>
           <td rowspan="3"><img src="whatever.jpg" alt="sad" width="64px" height="64px" /></td>
           <td>Prop1</td>
       </tr>
       <tr><td>Prop2</td></tr>
       <tr><td>Prop3</td></tr>
   </table>

   <table cellpadding="0" cellspacing="0" style="margin: 4px;">
       <tr>
           <td rowspan="3"><img src="whatever.jpg" alt="sad" width="64px" height="64px" /></td>
           <td>Prop1</td>
       </tr>
       <tr><td>Prop2</td></tr>
       <tr><td>Prop3</td></tr>
   </table>
   
</div>

Ahora mismo el comportamiento que tienen las tablas es que se apilan verticalmente, pero yo quiero que se vayan rellenado las columnas y que automáticamente vayan pasando a la siguiente fila cuando se alcance el ancho de la capa contenedora.

Si apilo imágenes sí funciona, pero con tablas o capas no. ¿Se os ocurre una forma de hacerlo automáticamente sin tener que echar mano de Javascript?.

Gracias.

[Session]

Hola.

Ante todo decir que no estoy muy puesto en el desarrollo de aplicaciones web. :)

Estoy desarrollando una aplicación web haciendo uso de ASP.NET 2.0 y estoy teniendo problemas con el estado de la sesión. Resulta que las variables que almacenaba en el objeto Session se me pierden. Al final he descubierto (o creo haber descubierto) que la causa es la escritura en un archivo.

Parece ser que cada vez que se modifica el arbol de directorios (o un archivo) del AppDomain, el worker process se recicla y la sesión se resetea, con la consiguiente pérdida de los datos almacenados.

Para manejar el estado de la sesión estoy utilizando el modo por defecto (InProc) ya que parece ser que es el más rápido, aunque tiene estos efectos colaterales (parece que con los otros dos modos no ocurre).

La cuestión es si existe alguna forma de evitar ésto sin cambiar el modo de sesión. He pensado en prescindir del objeto Session pero necesito mantener ciertas variables para cada usuario (por ejemplo para saber qué artículos tiene en la cesta de la compra y algunos datos más). ¿Se podría tal vez mantener una tabla hash que emule la sesión estándar de ASP.NET?. ¿Qué sistema utilizáis vosotros?.

Gracias.

[here]

 Hi.

If you've seen tutorial #11 that comes with the engine, you'll probably notice that light shafts, when seen perpendicularly, cause some artifacts. So today we've solved this problem and furthermore, we've added shadow projection for objects inside the light volume and also apply a gaussian blur to the light shaft so we reduce aliasing artifacts. Moreover, new parameters have been introduced so the effect now offers more possibilities.

I've captured a little video demostration. You can download it here.

The light shaft in the video is made up of 100 sampling planes. Those planes (quads) are clipped against light frustum via CPU. One improvement would be create the vertex data in the vertex shader and clip the polygons in the GPU using the user clipping planes.

Hope you like it!. :)

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



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

Hola.

Si habéis visto el tutorial #11 que viene con el motor, es posible que os diérais cuenta de que los light shafts, al mirarlos perpendicularmente, se veían mal. Pues bien, ya hemos solucionado ese problema y además, ahora también se proyecta la sombra de los objetos que hayan dentro del volumen y también se aplica un gaussian blur al light shaft para evitar en la medida de lo posible problemas de aliasing. Adicionalmente se han agregado algunos parámetros que hacen que el efecto ofrezca más posibilidades.

He capturado un pequeño video demostrativo. Podéis descargarlo de aquí.

El light shaft del video está compuesto por 100 "sampling planes". Estos planos (quads) son recortados a través del frustum de la luz via CPU. Una buena mejora sería posicionar los vértices en el vertex shader y realizar el recortado de los polígonos a través de la GPU utilizando los "user clipping planes".

¡Espero que os guste!. :)

[little video demo]

 Well, we've a good portion of the space partitioning system finished. It's based on portals/sectors. The most challenging part has been the sector extraction based on an arbitrary list of polygons and portals placed by the level artist. Also, we've built a BSP tree (non-splitting BSP tree) that will allow us to know in which sector we are in. Also, the BSP tree will allow us to clip shadow volumes (that would be precalculated) for static objects/lights, decals clipping, etc.

Now we have to add special cases like mirror portals, portals that point to non-geometrically-contiguos sectors or portals that point to outdoor areas. Effectively, we want to allow automatic indoor and outdoor areas.

You can see a little video demo where you can see a level made by 7 sectors. All the time you can see a little description of the sector the camera is in (if we are not into the void). This description will be specified by the level artist into MAX. The only thing to do is place a custom MAX helper (sector locators, similar to Doom3) into the desired sector and specify its "description" property. The engine, at load time, will detect these entities and will assign the description to each sector that contains one of these entities.

Greets.

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

Bueno, ya tenemos buena parte del sistema de particionamiento del espacio terminado. Está basado en un sistema de portales/sectores. Lo más complicado ha sido extraer los sectores a partir de un sopa de polígonos y una lista de portales posicionados por el diseñador de niveles. También se ha creado un arbol BSP del nivel (no se lleva a cabo particionamiento de polígonos) para saber en todo momento en qué sector estamos. El arbol BSP también nos servirá para recortar los shadow volumes (que serían precalculados) de los objetos/luces estáticos, recortar los decals, etc.

Ahora habrá que añadir casos especiales como portales "espejo", portales que dan a otros sectores que no son geométricamente contiguos o portales que dan al exterior. Con exterior me refiero a por ejemplo un terreno, es decir, queremos tener tanto interiores como exteriores controlados de forma automática por el motor.

Podéis ver un pequeño video demostrativo donde se puede ver un nivel con 7 sectores. En todo momento se muestra en pantalla la descripción del sector en el que nos encontramos (si es que no estamos en el vacío). Esta descripción la especificaría el grafista desde MAX. Tan sólo tendría que crear una entidad especial (sector locators, algo similar a Doom3) dentro del sector y asignarle una propiedad "description" o algo similar. El motor, en tiempo de carga, detectaría esas entidades y le asignaría al sector que la contenga, la descripción correspondiente.

Saludos.

 Ok, I'll show you how to register and set the forum language to english. Here are the steps.

Step 1.


Step 2.


Step 3.


Step 4.


Step 5.


Step 6.


Hope it helps!.

 Hola.

Estoy haciendo algunas cosillas con el sistema de particionamiento BSP. Seguramente os preguntaréis para qué demonios hacer uso de un BSP a estas alturas. Se supone que el BSP había muerto ya, ¿no?. :D

Bueno, la verdad es que creo que el BSP puede ser útil hoy día para ciertas cosas. Por ejemplo, imaginad el típico manchurrón de sangre que se queda marcado en la pared (decals). Es muy posible que el polígono con la textura de sangre sobresalga por alguna esquina. En una escena sin ningún tipo de coherencia geométrica, recortar dicho polígono creo que es bastante costoso en términos de tiempo (tendríamos que recorrer todos los triángulos de la escena y ver si están dentro del radio del decal y si es así, ver si cada uno de ellos intersecta con él). Con un arbol BSP no tendríamos más que ir recorriendo los nodos anteriores de la hoja donde se encuentra el decal e ir viendo si cada nodo intersecta con el decal. Si eso ocurre, se hace un split del decal y se elimina la parte que queda en la parte frontal del nodo.

Otra cosa de la que se podría beneficiar de un arbol BSP es la IA. Para un nivel como los que podemos ver en los quakes, doom3, y unreals, tenemos que las hojas del arbol forman un convex hull, es decir, podemos movernos de un punto a otro en linea recta sin preocuparnos de colisionar con nada (a no ser que sea un objeto dinámico que haya por ahí enmedio). Además, estos convex hulls forman areas que se podrían utilizar para calcular las rutas para los personajes controlados por la IA. Otra ventaja es que llevar a cabo el LoS (line of sight) es bastante rápido.

Pero ahora vienen mis dudas. ¿Pensáis que es buena idea calcular el BSP a partir de triángulos en lugar de polígonos?. Imaginad esta situación:



En la figura 1A tenemos el caso de utilizar triángulos. Tenemos dos triángulos que van a ser divididos por la línea roja. En la figura 1B podéis ver el resultado de la partición.  En negro tenéis las nuevas aristas que se han creado en la triangulación de los polígonos resultantes. Tras la partición, se han creado un total de 6 triángulos.

Ahora veamos el caso de utilizar un polígono (en este caso un "quad"). En la figura 2A tenemos el polígono y la línea que lo dividirá en dos polígonos. En la figura 2B vemos el resultado tras la partición. Como veis, tras la triangulación de los dos polígonos obtenemos un total de 4 triángulos, es decir, 2 menos de los que obtuvimos en el caso de utilizar triángulos. Ahora pensad esto mismo pero en el caso de existir unos cuantos cientos de miles de triángulos. ¿Cuántos triángulos podrían llegar a generarse tras la partición del espacio?.

Así que una cuestión queda en el aire. En el caso de utilizar triángulos, ¿es buena idea particionar o simplemente metemos el polígono que debería ser particionado en el nodo frontal y en el trasero del splitting node?. De esta forma el número de triángulos permanecerá igual y sólo tendremos que asegurarnos de sólo renderizar dichos triángulos una sóla vez. Evidentemente, una desventaja de ésto es que podrían haber polígonos muy grandes que procesarían pixel shaders (que podrían ser bastante costosos) sin ninguna necesidad.

Por lo tanto otra cuestión salta a la palestra. ¿Creeis que MAX/Maya/Blender/XSI/XXX son buenas herramientas para crear mapas que cumplan con los requisitos a la hora de generar un arbol BSP?. Aunque bien es cierto que al menos en MAX podríamos exportar el escenario a base de polígonos en lugar de triángulos pero aún quedaría el tema de los leaks o la geometría ilegal. Por ejemplo nodos cuyo nodo trasero apuntase a una zona vacía (transitable).

Bueno, a ver qué pensáis.

Gracias.

[cascade.avi]

 Hola.

A falta de darle los últimos retoques, se puede decir que el editor de partículas es totalmente funcional. Se ha incrustado en el propio visor de escenas. De esta forma también se podrán editar las partículas en la propia escena, para tener una mejor referencia.

He creado dos videos donde muestro cómo utilizar el editor. En el video cascade.avi hago uso de las partículas con orientación de tipo "aimed". Sin duda son las partículas más peculiares. En el otro video; paranoia.avi, creo un efecto con dos sistemas. Uno es un humo que utiliza partículas con orientación estándar y otro que es uno de tipo "aimed" que simula una cosa rara... :D



Descargar (~36MB)

Al hacer click en el enlace, os aparecerá una web con un banner y debajo os pondrá un contador donde os indica los segundos que tenéis que esperar. Una vez que el contador llegue a 0, os aparecerá un nuevo enlace. Hacéis click y os enviará a otra página donde aparecerá otro contador. Pasado un tiempo, os aparecerán los enlaces a las descargas. Si no queréis instalar ningún ActiveX, os recomiendo el enlace que pone FileFactory Direct.

Pues eso es todo. Esperamos que os guste. :)

PD: Se admiten sugerencias. :)

[Imp]

 Hola.

Hoy os quiero presentar al que; con gran probabilidad, será el sustituto de Imp. Este personaje es bien conocido por todos los "maxeros". Señoras y señores, les presento a Biped (xvid, ~600KB). (ole)

Para obtener tal engendro he tenido que crear unos cuantos maxscripts para poder convertir el biped en un objeto poligonal y crear el biped "real" que hace de esqueleto del biped "geométrico".

Esperemos que sea de utilidad en el futuro (y que autodesk no nos ponga trabas legales :lol:).

Saludos.

[Niebla]

 Bueno pues aquí estamos otra vez para informar de los avances del motor y del visor.

Lo más importante es que se han implementado tres tipos de niebla y los decals.

Niebla

• Linear
  
• Exponential
  
• Exponential Square
  
• Layered
  

En esta imagen podéis ver un ejemplo de niebla de tipo "exponential square" (click para ver tamaño original).



Y en esta otra un ejemplo de niebla de tipo "layered" (click para ver tamaño original).



Decals

Los decals son planos que se superponen a las superficies para dar detalle extra como pueda ser sangre, barro, musgo, carteles, etc. En otras palabras, y tal como se traduce la palabra decal, son como calcomanías :P. Por ejemplo, en la siguiente imagen podéis ver los decals que se han utilizado para añadir manchas de sangre al suelo (click para ver tamaño original).



Ahora la versión wireframe para que podáis ver los quads que forman los decals (click para ver tamaño original).



Los decals no tienen por qué ser un quad. Pueden ser un patch de Bèzier moldeado para distorsionar la textura aplicada al decal.

Lo siguiente

Lo siguiente que se hará será algo similar a los decals pero no exactamente lo mismo. Implementaremos los detail maps que como su nombre indica se utilizan para añadir detalle a las texturas y de paso disimular la repetición de las mismas. El funcionamiento será como en el caso del mapa de tipo Blend en MAX. Una textura base, el detail map y una máscara que indica qué partes de la textura de detalle se verán.

Otra cosa que habría que implementar es otro tipo de niebla, la volumétrica. La niebla de tipo layered queda muy bien y a simple vista pudiera parecer que se trata de un volumen de niebla, pero lo cierto es que afecta a toda la escena. Así que habrá que implementar volúmenes de niebla. En principio se me ocurrió una técnica con la que se podría utilizar cualquier volumen convexo pero al final no funcionó como se esperaba, así que habrá que buscar otros métodos.

¡Eso es todo por ahora!.

[Shenmue]

 Ahora mismo estamos trabajando en un visor de modelos para que los grafistas puedan ver de forma rápida cómo quedaría la cosa en el motor. El visor soporta el formato nativo del motor (haddd) y también el MD5 de Doom3.



En la imagen tenéis un modelo creado por Shenmue, un usuario del foro de 3DPoder.

También he capturado un pequeño video (~3.5MB, xvid) donde podéis ver algunas de las posibilidades que ofrece. Como he dicho aún no está acabado y la intención es que se puedan hacer más cosas como por ejemplo añadir/eliminar luces, moverlas, mezclar animaciones en los diferentes canales de animación, etc.

Saludos.

 Pues eso, ya ha sido liberado el código fuente de Quake III: Arena. Lo podéis descargar de aqui.

Ale, a olisquear un poco. :D

Saludos.

[aquí]

 Pues eso, aquí podéis descargaros un video que muestra a una pandilla de frikis del quake3 "matándose" a petardazos (literalmente). ¡Es para partirse!. :lol:

En el montaje han utilizado los sonidos de quake3.

¡Recomendado!.

Por si os hacéis un lío con la descarga, aquí van unas instrucciones.

• Hacéis click en el botón "Begin Download".
  
• En la ventana que os aparecerá, hacéis click en "Keep Waiting".
  
• Entonces veréis el tiempo que queda para que comience la descarga (si es que hay que esperar algo). Una vez que pase ese tiempo, el botón que pone "Waiting" pasa a ser "Download Ready".
  
• Hacéis click en el botón "Download Ready" y la descarga dará comienzo.
  

Lo dicho, buen video para echarse una risas (sobre todo si has jugado al quake3). :D

Saludos.

 Hola.

Estos días atrás hemos estado desarrollando el sistema de materiales para el motor. El sistema es similar al que se puede encontrar en quake3 o doom3. Al igual que en estos dos juegos, nuestro sistema también se basa en un sistema de capas.

El material se define a través de un script en el que, además de las capas, se definen las texturas que forman cada capa, los sampler y render states y algo importante, también se definen los fragmentos de shader y los valores de las variables de dichos fragmentos. Estos fragmentos son trozos de shader que llevan acabo una determinada funcionalidad. Por ejemplo, aquí tenéis un fragmento que realiza un scroll:

Código [Seleccionar] Expand

#region VAR

float2 uvScroll_Speed;

#end VAR

#region VS
{
   data_in.texCoord0.x -= uvScroll_Speed.x * ENV_Time;
   data_in.texCoord0.y += uvScroll_Speed.y * ENV_Time;
}
#end VS

Como podéis ver, hay dos secciones. En una se declaran las variables que utilizará el fragmento y en la otra el código que implementa la funcionalidad del fragmento. En este caso hacer un scroll de la textura.

Luego en el material (tenéis el código completo al final) podemos aplicar dicho fragmento y especificar los valores de las variables de la siguiente forma:

Código [Seleccionar] Expand

geometryShader "uvScroll" {

   param "uvScroll_Speed" ( 0 1 )
}

Lo bueno de este sistema es que te permite crear tus propios materiales sin tocar una sola línea de código del motor. Simplemente es crear los fragmentos de shader que necesites (geometry o lighting shaders, muchos ya irán "de serie" con el propio motor) y crear el script del material. Luego se creará un nuevo tipo de material en MAX para poder asignar estos materiales desde el propio MAX.

Evidentemente también se ofrecerá la posibilidad de crear estos materiales de forma visual a través de un editor de materiales que está a medio desarrollar. :)

He creado un pequeño video (~1MB, xvid) donde se muestran tres materiales. El primero es muy chorra y es el que he creado para hacer pruebas. Los otros dos os resultarán muy familiares a los que hayáis visto quake3. :D

Concretamente, el último es el más complejo y consta de cuatro capas. Este es el código de dicho material.

Código [Seleccionar] Expand

// blocks15cgeomtrn.material

material "blocks15cgeomtrn" {

   renderStates {

       cull        CCW
       fillMode    Solid
   }

   layer "layer0" {


       map diffuse {

           fileName    "escenas/VolumetricLight/firegorre.tga"
           
           amount      1.0

           samplerStates {

               addressU        Wrap
               addressV        Wrap
               minFilter       Linear
               magFilter       Linear
               mipFilter       Linear
           }
       }
       
       renderStates {

           alphaBlendEnable        false
           alphaTestEnable         false
           zEnable                 true
           zBufferWriteEnable      false
       }

       geometryShader "uvScroll" {

           param "uvScroll_Speed" ( 0 1 )
       }

       geometryShader "uvTurbulence" {

           param "uvTurbulence_Amplitude"  0.25
           param "uvTurbulence_Phase"      0
           param "uvTurbulence_Frequency"  1.6
       }

       geometryShader "uvScale" {

           param "uvScale_Scale" ( 0.5 0.5 )
       }
   }

   layer "layer1" {


       map diffuse {

           fileName    "escenas/VolumetricLight/blocks18cgeomtrn2.tga"
           
           amount      1.0

           samplerStates {

               addressU        Wrap
               addressV        Wrap
               minFilter       Linear
               magFilter       Linear
               mipFilter       Linear
           }
       }
       
       renderStates {

           alphaBlendEnable        true
           sourceBlend             SourceAlpha
           destinationBlend        InvSourceAlpha
           alphaTestEnable         false
           zEnable                 true
           zBufferWriteEnable      false
       }

       geometryShader "uvRotation" {

           param "uvRotation_Speed" 30
       }

       geometryShader "uvStretch" {

           param "uvStretch_WaveType"      0
           param "uvStretch_WaveParams"    ( 0.8 0.2 0.0 0.2 )
       }
   }

   layer "layer2" {


       map diffuse {

           fileName    "escenas/VolumetricLight/blocks18cgeomtrn2.tga"
           
           amount      1.0

           samplerStates {

               addressU        Wrap
               addressV        Wrap
               minFilter       Linear
               magFilter       Linear
               mipFilter       Linear
           }
       }
       
       renderStates {

           alphaBlendEnable        true
           sourceBlend             SourceAlpha
           destinationBlend        InvSourceAlpha
           alphaTestEnable         false
           zEnable                 true
           zBufferWriteEnable      false
       }

       geometryShader "uvRotation" {

           param "uvRotation_Speed" 20
       }

       geometryShader "uvStretch" {

           param "uvStretch_WaveType"      0
           param "uvStretch_WaveParams"    ( 0.8 0.2 0.0 0.1 )
       }
   }

   layer "layer3" {


       map diffuse {

           fileName    "escenas/VolumetricLight/blocks15cgeomtrn.tga"
           
           amount      1.0

           samplerStates {

               addressU        Wrap
               addressV        Wrap
               minFilter       Linear
               magFilter       Linear
               mipFilter       Linear
           }
       }
       
       renderStates {

           alphaBlendEnable        true
           sourceBlend             SourceAlpha
           destinationBlend        InvSourceAlpha
           alphaTestEnable         false
           zEnable                 true
           zBufferWriteEnable      false
       }
   }
}

Evidentemente el sistema se puede ampliar mucho más. Por ejemplo se podría hacer que el material hiciera referencia a su vez a un shader de sonido que sería el que se reproduciría en el caso de que el jugador (por poner un ejemplo) entre en contacto con una superficie que tenga aplicado dicho material.

¡Bueno, eso es todo por ahora!

Saludos.

[Renderer: Haddd]

 Como se ha dicho en otros mensajes, estamos mejorando el apartado de shaders/iluminación. El objetivo es intentar equiparar la calidad de render del motor a la calidad de render de MAX. Evidentemente sin la utilización de radiosidad ni cualquier otro tipo de iluminación global (eso lo dejamos para más adelante :D).

De esta forma el grafista podrá hacer el render en MAX y podrá tener la seguridad que lo que vea es lo que verá en el motor. Aquí os pongo dos imágenes para comparar:


Renderer: Haddd


Renderer: MAX


La primera imagen está renderizada en Haddd y la segunda en MAX.

La principal diferencia es que en Haddd la escena tiene más brillo que en MAX. Se ve que ellos utilizan algún tipo de corrección del color o algo similar y la otra diferencia es que parece que MAX maneja de otra forma las reflexiones (el objeto central). Además, en el render de Haddd le hemos metido un glow a la vidriera. Por lo demás, los brillos especulares son prácticamente idénticos (en ambos casos se utiliza Blinn-Phong como BRDF), el proyector también, el bump casi que también y la tetera tiene aplicado un gloss-map que también maneja el motor para controlar la intensidad y el color de los reflejos especulares del objeto. Ni qué decir que la iluminación en Haddd es totalmente dinámica, nada de lightmaps.

Bueno, eso es todo por ahora. Os mantendremos informados. :)

Saludos.

[Programming Game AI By Example]

 El otro día estuve leyendo el libro que se recomendó recientemente sobre IA: Programming Game AI By Example y me llamó la atención el capítulo sobre "Steering Behaviors" así que decidí ir implementando las distintas técnicas que se mencionan en el libro. Aún me quedan unas cuantas (sobre todo las que se refieren al comportamiento de grupos de entidades) pero por ejemplo ya tengo medio implementado el que se encarga de evitar obstáculos. Aquí os dejo un video.

Descargar

Como véis tiene algunos fallos y además no tiene en cuenta la colisión entre entidades. Eso será cuando implemente los comportamientos en grupo.

Saludos.

 Esta tarde se ha implementado el Depth of Field y la verdad es que ha quedado bastante bien. Hemos tenido que reducir el número de samples (hemos utilizado una distribución del tipo Poisson) a 5 porque si no nos quedábamos sin registros. :D

Este es el resultado:



Por si os interesa me he basado en el paper de Thorsten Scheuermann (ATI), Advanced Depth of Field.

Saludos.

 Mientras Haddd anda peleándose con la librería de Newton (la física), yo he estado haciéndole un buen lavado de cara al exportador de MAX para dar soporte a los temas relacionados con el portal rendering, y ya que estaba, decidí exportar todos los canales de mapeado que un objeto soportara. Una vez hecho esto ya teníamos lo necesario para implementar los lightmaps en el motor, así que he estado haciendo unas pequeñas pruebas para ver si todo funcionaba bien y aquí está el resultado:



Como veis no me he matado con la escena de pruebas... :D



La cuestión ahora mismo es saber cada canal de mapeado para qué se va a utilizar. Es posible que demos esa posibilidad al usuario a través de editor de materiales que estamos desarrollando.

La pega que le veo al tema del render to texture de MAX para generar los lightmaps (aunque lo cierto es que sólo he estado trasteando con él unas pocas horas) es que si la escena se compone de objetos separados, te genera un archivo de textura para cada objeto, lo cual es una locura. Si alguno conoce alguna forma de poder crear los lightmaps en un sólo archivo de textura sin tener que asociar los objetos en uno sólo, estaría bien que lo dijera. :)

Y nada más por ahora, después de esto toca seguir con el portal rendering sobre el cual ya tengo bastante código escrito, así que espero terminarlo pronto...

Saludos.

 Hola.

Estoy preparando una serie de métodos para implementar un sistema de render basado en portales para el motor C# y me he encontrado con un problemilla. Resulta que los portales los representaríamos en MAX como polígonos convexos, pero el problema es que MAX no te da los vértices de forma consecutiva, cosa necesaria a la hora crear el frustum o de recortar el portal a través del frustum.

Así que he estado pensando y he implementado un sistema para conseguir ordenar los vértices de un polígono. Lo que hago es:

- Calcular el centro de masas del polígono.
- Calcular dos vectores (v1 y v2) que van desde el origen a dos vértices cualesquiera del polígono (comprobando que no sean paralelos).
- Calcular un tercer vector (v3) resultante del producto vectorial de los dos vectores anteriores.
- Calcular otro vector (normal) resultante del producto vectorial entre v1 y v3.
- Normalizar el vector normal.
- Con esto ya tenemos lo necesario para calcular un plano de divide el polígono en dos secciones.
- Ahora se crean dos listas, una con los vértices que se encuentran en el half-space positivo (o sobre el plano) y otra con los vértices que se encuentran en el half-space negativo.
- Para cada lista recorremos los vértices y vamos calculando el ángulo con respecto al vector v1.
- Ordenamos ambas listas en base a los ángulos. La de vértices en el half-space positivo de menor a mayor y la otra de mayor a menor.
- Unimos ambas listas.

Con eso ya tenemos la lista de vértices de forma consecutiva. Al menos lo he estado probando con varios polígonos y parece funcionar.

El problema es que lo mismo se me crea en sentido clockwise que anti-clockwise y además me parece que es un método un tanto complejo (aunque el uso que le voy a dar va a ser en tiempo de exportación en MAX por lo que la velocidad no me importa).

El caso es que me gustaría saber si conocéis un método más sencillo para conseguir esto, y ya de paso poder especificar si se ordenan en sentido clockwise o anti-clockwise.

Gracias.

[Video]

 Por fin tenemos ya cosas visibles con los MD5 utilizando animación esquelética (por supuesto). :)

Video (188KB)

En este video se ha desactivado la iluminación para que se vea todo más claro pero hay que decir que al hacer el skinning se realiza la transformación tanto de las coordenadas del vértice como las normales y las tangentes.

El siguiente paso a dar será implementar la interpolación entre sets de animación y el soporte para varios canales de animación. Explico cada cosa porque tal vez  a alguien le pueda resultar interesante.

El tema de la interpolación entre animaciones es por ejemplo realizar la transición entre la animación de andar a correr de forma suave, sin cambios bruscos.

El otro punto es uno de los más importantes y el que le ahorrará al animador tener que crear más de un animación. Consiste en tener varios canales de animación. Cada uno de estos canales tendrá asignado una lista de bones y a cada uno de estos canales se les podrá asignar una animación de forma independiente. Así, podríamos tener el canal "cabeza" y "torso" reproduciendo la animación "disparar" mientras que el canal "piernas" reproduce la animación "correr". Como es de imaginar esto nos permite realizar un montón de combinaciones sin necesidad de explotar al animador. :lol:

La otra cuestión que hay pendiende es realizar el skinning a través de un vertex shader. El problema es que los MD5 pueden llegar a soportar más de 4 pesos. Yo he llegado a ver hasta 8 pesos por vértice. La solución podría ser reducir su número a 4 como máximo pero me temo que esto causará una deformación incorrecta en el mesh. Todo dependerá de si por ejemplo los 8 pesos estaban repartidos por igual o la contribución de algunos de ellos era insignificante...

Y nada más, ya iré informando con los avances que vaya realizando sobre estos temas.

Saludos.