Hola

He puesto un nuevo vídeo sobre la nueva versión del iL-engine. Lo podéis ver en la siguiente dirección:

http://ilengine.wikidot.com/videos

Un saludo

• Artículo de programación con strings más completo
• Artículo de programación con vectores más completo
• Artículo de programación con listas
• Artículo de programación con xmlParser (Parser XML para C++)

Página: http://ilengine.wikidot.com

• Artículo de programación con strings
• Artículo de programación con vectores

Página: http://ilengine.wikidot.com

Hola

Hace ya unos cuantos días que no actualizo el blog, y no es que lo tenga abandonado sino que no es el tipo de pagina web que yo quería para poder publicar conocimiento.

El tema está en que un blog es algo para leer día a día perdiendo de una manera simbólica el índice de las cosas que se han hecho y perdiendo el norte de todo lo que se ha publicado.

Por eso mismo, he decidido moverme hacia una página en forma de wiki para poder publicar allí todo lo que estaba publicando aquí y más de manera más ordenada y fácil de consultar.

Por lo tanto pido a todos aquellos que leíais la información que posteaba aquí que actualicéis vuestros links porque a partir de ahora pondré todo el conocimiento en la nueva wiki.

Un saludo y gracias

Nueva pagina: http://ilengine.wikidot.com

Hola

Siguiendo con las funciones interesantes y útiles de las STL y sus objetos. Imaginaros que necesitáis substituir unos caracteres por otros en una cadena.

Pues bien, utilizando una string como contenedor de la cadena es relativamente sencillo hacerlo.

std::replace(str.begin(),str.end(), '*','-');

Lo que hacemos es utilizar una función estándar de las STD para indicar que queremos substituir los asteriscos (*) de la cadena por guiones (-). Evidentemente necesitamos indicar de donde a donde irá ese cambio, es decir, unos límites. En el ejemplo que he puesto, y normalmente el más usado en la mayoría de los casos, es todo el tamaño de la cadena, desde su inicio hasta su fin.

Un saludo

Hola

Hoy os traigo algo que aunque no sea directamente relacionado con el mundo 3D, sí que lo está con el mundo de la programación y nos puede ser de utilidad.

Estoy hablando de del sistema de encriptación de datos AES en formato C++, listo para ser agregado a nuestros proyectos, sin ningún tipo de licencia y totalmente libre.

En la siguiente web podéis encontrar los dos ficheros, el *.h y el *.cpp para poder usar este sistema en vuestro proyecto para lo que queráis.

Link: AQUI

Un saludo

Hola

Después de una semana un poco movida sin haber podido postear por falta de tiempo, hoy vengo para explicar la evolución de la ecuación de Phong en nuestros engines.

La ecuación de Phong es muy simple, básicamente es una suma de tres componentes:

Resultado = Ambiente + Diffusa + Specular

¿Dónde está el problema? El problema reside en que esa es la forma más simple de calcular la iluminación en un píxel, y a medida que vamos añadiendo ‘capacidades’ a la ecuación, esta va evolucionando para dar como resultado algo nada intuitivo.

Actualmente me encuentro haciendo la ecuación de la nueva versión del engine y os puedo comentar varias cosas:

- En esta ecuación no se representa en ningún momento alguna componente de auto iluminación, por lo tanto, ya tenemos una componente que en esa ecuación no está reflejada.
- En la ecuación de iluminación del Half-Life 2, la Ambiente y la Diffusa no se suman, sino que se operan entre sí para formar una componente Diffusa nueva a la cual se le sumara la componente Specular.
- La ecuación de Phong con una sola luz nos proporciona oscuridad casi absoluta en esas caras o píxeles que no estén mirando a la luz, cargándose por completo la sensación de iluminación global de la escena. Por lo tanto a veces se opta por poner un 30% de Ambiente y un 70% de Diffusa para que los píxeles no tiendan a negro absoluto.
- En ningún momento hemos hablado de la componente de lightmap, por lo tanto ya tenemos otra componente oculta y que deberemos tratar para obtener buenos resultados.
- Etc.

Como podéis observar, la ecuación de Phong está bien para empezar, pero poco a poco vamos añadiendo mas información necesaria y nos da como resultado una ecuación que distaba mucho de la teoría.

Este podría ser un ejemplo:

Resultado = ((Ambiente <-> Diffusa) * LightMap) + Specular + Self-Ilumination

Un saludo

Hola

Hoy aunque breve, me gustaría hablar sobre una idea que me ha sobresaltado mientras pensaba en esto del HDR. Y aparte voy a probar de paso esto del particionado de la noticia.

El caso es el siguiente:

Imaginad una ecuación de render la cual nos da dos rangos de colores, el LDR y el HDR. Ahora nosotros queremos implementar niebla en la escena (lo digo porque en la versión 1 del iL-engine, la niebla estaba implementada, y esta segunda versión no será menos) y para eso nos surge una duda.

¿Donde implementamos la interpolación de la niebla con el color de la escena? En el rango LDR o en el rango LDR+HDR (es decir, en los valores ANTES de partir la información en dos rangos).

Una posible respuesta es la de aplicar la niebla al rango LDR, pues es el color ‘base’ de la escena. Pero si lo hacemos así, es decir, implementar la niebla en el rango LDR, si un objeto está muy lejos de la cámara y todo su volumen es del color de la niebla, si este objeto tiene un brillo HDR azul, este brillo saldrá por encima de la niebla. Y seamos sinceros, por muy fuerte que sea un brillo, siempre la niebla se interpone en medio de ese brillo.

Por lo tanto, lo que dentro de unos días (sino semanas) será la niebla pero en el rango LDR+HDR, es decir, antes de hacer cualquier distinción entre LDR y HDR.

Un saludo y se aceptan ideas, opiniones, etc.

Hola

Continuando con los experimentos de HDR, os quería mostrar lo que hablaba el otro día sobre esos ‘dos rangos’ en los que se dividía la luz.

Bien, en la imagen, podéis ver pixeles con color en el rengo LDR [0.0f – 1.0f] y pixeles HDR que son de color rojo (son así porque he puesto un if en le shader para distinguirlos). La manera de interpretar esta imagen es la siguiente:

- Todos los píxeles que no son rojos, son píxeles que tienen rango LDR pero no tienen nada de HDR.
- Todos los píxeles ROJOS son píxeles que aparte de tener LDR tienen HDR.

Por lo tanto, solo el rango HDR será el que pasara a los filtros de glow y demás. Todos los otros píxeles se quedaran igual.

También comente de que si hacíamos dos salidas de píxeles, una en un render target, y otra en otro render target, es posible que perdiésemos el Anti Aliasing por hardware, y así es como es, lo perdemos, pero que no cunda el pánico, pues existen unos filtros de detección de bordes que nos permitirán aplicar un blur sobre esos píxeles y hacer nosotros mismos el Anti Aliasing.

Un saludo