#environment mapping

A Study in Image Based Lighting via Cell Phone Photos

Summary: You don't need perfect images or HDRI spheres to create amazing lighting in your 3D renders. Go ahead and use your cell phone camera to capture an environment at the spur of the moment if you love the light that you're seeing.

See the animations at 960x960 at the Imgur gallery. Explore the terribly broken but perfectly adequate photospheres at Google Photos. Also on Ello and Dribble for consistency.

The other day, I came across an article at BlenderNation pointing to this killer tutorial by Gleb Alexandrov titled "Are You Overlooking This Way to Make Amazingly Complex Lighting?". I read the article and was instantly inspired. He describes a scene setup where he uses one light plane and a large number of objects with interesting geometries and various transparent materials to compose a "light symphony" which you only need to explore with your camera to create some amazing renders. While I loved the output he was getting from this technique, I had a problem with this approach. Gleb likes to compose individual still images and let them render over night, and I like to compose simpler animations made of 48 or more frames and give them that same amount of time(or less) to render - but his described technique would be incredibly computationally expensive. I know from experience that increasing the number of bounces and transmissive paths any photon has to take before it reaches its destination can dramatically impact the amount of time that a render will take... But that inspiration...

Gleb's phrase "Lose control and let the light do its magic" stuck with me. Eventually, I kinda... took the idea in his article and turned it inside out. One of the themes he approaches repeatedly through his tutorials is to make sure that your light sources are non-uniform and complex. Suddenly, it came to me. "Holy crap. I can take out my phone and take some totally imperfect photos of places with lots of color, and use those as my world light! The PHYSICAL WORLD has already done all of the magic in producing a 'lighting symphony' for me, so I can just take that light and use it at my desired angle!" So I downloaded the Google Camera photosphere app for my phone and produced some super quick and dirty photospheres of interesting lighting scenarios to play with. You will notice that the stitching on the photospheres is TERRIBLE, but that is just fine for these purposes. I also selected some images which I had previously taken with my phone's camera just because they were colorful. The emphasis here is that we DO NOT need perfection in the images, only their color, non-uniformity and complexity!

In his tutorial, Gleb talked about flying your camera around within the scene to find your desired lighting angle - but what if I already had my camera and geometry composed in the way that I want for my render? That's when I had the idea to shift and distort the generated coordinates of the world sphere until the world light gave me the colors I wanted for the existing composition. Yes! Then I only needed to adjust the depth of field in my camera so the subject matter was in focus, but the background was out of focus! That way, the viewer is not concerned with any of the imperfections background light source. So I created several different renders using different world lighting configurations, with single camera and subject matter configuration. I was incredibly pleased with how AMAZING the results were! Now keep in mind, these environment images were NOT directly mapped to the world light with a standard Equirectangular projection. I took the base world coordinates and moved, rotated, scaled them until I saw the colors in the positions that I wanted to see them. In some cases I tweaked their contrast and hue a bit, then boosted the intensity of the world light into what I wanted to see.

Here's the important lesson that I learned from this experiment: You don't need to create the perfect HDRI sphere or tile an image perfectly to get a perfect lighting scenario for your shot. Just find a real world scenario with colors that you like, and snap a super quick picture or build an image sphere with your cell phone camera, and that is more than good enough.

Credit for the beautiful abstract painting titled "Conflicting Locations 5" goes to my friend Jenny Hambleton of Captain Captain Studios. I cannot express how much inspiration this painting gives to me when I need ideas for a nice color selection; Thank you so much for this painting, Jenny! :D

Código fuente y ejecutable de la solución

Frustrado porque el libro que pensaba seguir se basa en DirectX 10 (que XNA no soporta), probablemente me pase a SlimDX. De todas formas, dejo mis experiencias y comparación entre los tipos de environment mapping en Directx9.

Sphere Mapping

La interpolación lineal hace desastres sobre la textura. Utilizando un modelo y meshes más grandes (como sponza.x), la solución de no renderizar las primitivas que pasan por la singularidad no sirvió. El ejemplo de D3DBook usa una interpolación de mayor orden (por lo que pude ver, interpolación baricéntrica de Lagrange). Para eso, se aprovecha de la posibilidad de trabajar al nivel de per primitive en el Geometry Shader y así tener acceso a las 3 normales del triángulo a la vez.

float3 HighOrderInterpolate( float3 normals[6], float x, float y )

{

    float p0 = 2*x*x + 2*y*y + 4*x*y - 3*x - 3*y + 1;

    float p1 = -4*x*x - 4*x*y + 4*x;

    float p2 = 2*x*x - x;

    float p3 = -4*y*y - 4*x*y + 4*y;

    float p4 = 2*y*y - y;

    float p5 = 4*x*y;

    return p0*normals[0] + p1*normals[1] + p2*normals[2] +

    p3*normals[3] + p4*normals[4] + p5*normals[5];

}

Dual Paraboloid Mapping

Otra vez el problema de interpolación. En este caso resulta en una división entre ambos paraboloides y stretching de algunos triángulos. El ejemplo, en cambio, sólo tiene una pequeña línea negra.

Cube Mapping

En este caso, no hay pérdida de calidad visual por usar Dx9, sino de performance. Al no poder usar un array de rendertargets y setear el index en el shader, se deben realizar 6 pasadas (enviando a renderizar 6 veces cada primitiva). 

Mejoras a la solución

Adapté la opción de mostrar passes y sacar screenshots para que soporte cubemaps e hice un shader que renderiza las 6 caras a una Texture2D (para que las 6 caras se consideren una pasada y se muestren como un cubo desenvuelto). En la carpeta Content de la solución, aparte del .fx que utiliza XNA, está el .rfx.

Implementé frustum culling usando BoundingSpheres (XNA no genera automáticamente BoundingBoxes) y un contador de vértices renderizados. Esto, junto con el indicador de FPSs, permite ver claramente la diferencia a nivel procesamiento de cada técnica (~300.000 de sphere vs ~1.100.000 de cube).

RenderTargetUsage

Esto me tuvo luchando por más de una hora hasta que pude detectar cuál era el problema. Acostumbrado a RenderMonkey, pensaba que el usage por defecto del backbuffer y los rendertargets era PreserveContents. En cambio, es DiscardContents, por lo que al renderizar el skybox en el backbuffer, después pasar al environment mapping y por último renderizar la escena, el sky se perdía.

Solución, setear el usage al crear el rendertarget o en el evento de preparación del GraphicsDevice:

rtScreenshot = new RenderTarget2D(GraphicsDevice, iWidth, iHeight, true, SurfaceFormat.Color, DepthFormat.Depth16, 0, RenderTargetUsage.PreserveContents);

graphics = new GraphicsDeviceManager(this);

graphics.PreparingDeviceSettings += OnPreparingDeviceSettings;

private void OnPreparingDeviceSettings(object sender, PreparingDeviceSettingsEventArgs e)

{

    e.GraphicsDeviceInformation.PresentationParameters.RenderTarget

    Usage = RenderTargetUsage.PreserveContents;

}

Código fuente y ejecutable de la solución (implemetados sphere y cube hasta ahora)

En los próximos días voy a estar subiendo una adaptación de los shaders propuestos en  http://cor.to/d3dbooksphere. Los originales están hechos en DirectX 10 con VS, GS y PS 4.0 que, lamentablemente, XNA no soporta. En el caso de la esfera no es un problema, pero en el caso de cube mapping, por ejemplo, se pierde la posibilidad de generar el cubemap en una sola pasada (aprovechando el manejo de arrays de rendertargets en el shader).

Updates del "engine"

Tenía un error el manejo de la cámara que había implementado yo, por lo que la cambié por la implementación de dhpoware ( http://cor.to/dhpowarecamara). Muy versátil y configurable.

Modularicé y comenté un poco más toda la solución.

Problemas de Sphere Mapping

Están muy bien explicados en el link del D3DBook (aunque en inglés) en la sección Improving Sphere Map Implementation. De todas formas los describo junto con la solución implementada.

Singularidad alrededor del eje de la view matrix de C

Se basa en la forma del modelo y cómo se mapea para utilizar un sólo rendertarget.

La solución es bastante simple y consiste en utilizar como vector de dirección de la view matrix de C al vector C->cámara real. De esta forma, el punto de la singularidad siempre se encuentra exactamente opuesto a la cámara y, por ende, no visible.

fxpView.SetValue(Matrix.CreateLookAt(matEsfera.Translation,

camara.Position, camara.YAxis));

Comparación:

Artifact por interpolación alrededor de la singularidad

Consideremos un objeto que se encuentra en (0,0,1) (view position relativa respecto al punto C), es decir justo atravesado por la recta cámara->C->singularidad de C. Al restarle el view vector (0,0,1), la componente en z casi se anula y cada vértice del cuerpo pasa a encontrarse a (+-dx,  +-dy, ~0) siendo dx y dy de un valor absoluto ínfimo. Al normalizar, la normal de un vértice queda, por ejemplo, en (0.707, 0.707, ~0)  mientras que la del vértice siguiente en  (-0.707, -0.707, ~0) cubriendo así casi toda la textura.

Lo solucioné con:

if (inpVS.z / lenInpVS > 0.9)

{

    Output.Position.z = 10;

    return Output;

}

else Output.Position.z = lenInpVS / fFarClipPlane;

Comparación (la bola blanca giratoria se encuentra detrás de la bola de cristal):