Category Archives: Deferred Rendering

redLights 2.0 has been released!

Ok, it’s been done on time. Yesterday Unity 5.0 has been released and so has been redLights 2.0. If you want high quality area lighting in your Unity 5.0 projects, you should check out our plugin in the assetstore.

To celebrate all this, we prepared a new web demo that shows off our latest feature. Support for Enlighten realtime GI. As usual you can find it in our redLab.

Have a great day everybody!

Physically Based Area Lights for Unity3D

Oh well, it’s been a while since, but this is certainly worth a quick entry.

We were quite busy working on our PBS Area Lights for Unity, that will hit the assetstore soon. As usual you can follow the discussion in the forum, or on our Facebook page.

Stay tuned!

SSAL redLights have been released!

Our redLights SSAL package has been released and is now available for purchase at the unity asset store.

Go, grab it while it’s hot! Now!

Let’s call it redLab!

Yesterday the redPlant team launched a new area on their website. It’s the redLab, where we will showcase latest experiments from our office in Germany.

The first entry is about redLights (SSAL). A new technique for illuminating scenes that have been built with Unity3d. The respective unity package will hit the asset store soon. So stay tuned!

The next article will follow shortly. It will contain an in-depth explanation of the deferred rendering pipeline, that we have developed and contributed to the three.js engine. It’s part of the stable branch since release r54.

Exciting :)

Screen Space Area Lights – SSAL – New Preview

There is a new preview version that shows our SSAL in action. Note, that all the lighting in the screenshots below comes from SSAL. No ambient, directional, spots or points.

The final package will be released soon. Cheers.

Screen Space Area Lights – SSAL

I’m happy to announce that our SSAL package will be released on the unity asset store soon.

Unity users will now have the ability to use realtime arealights in their applications by using our screen space implementation.

It supports all the goodness, such as deferred and forward rendering, correctly works together with the builtin unity materials, lights and shadows. And since it is rendered as image effect, it is decoupled from the geometric complexity of the rendered scene.

There is a preview version to play around with.

You can also follow the discussion on the unity forum.

Stay tuned!

WebGL – Deferred Arealights

To continue this series on WebGL-based deferred lighting, we just finished another deferred lighting demo at the redPlant demo section.

This new application is showing a deferred arealight implementation, again WebGL based, again done with three.js and again with public source.

Have fun and merry christmas!

WebGL – Deferred Spotlight with Deferred Shadowmapping

There is a new demo at our redPlant demo section showing an WebGL based implementation of a deferred spotlight with deferred shadow mapping. It again utlitizes the three.js library. However if you are planning on doing deferred stuff with three.js, I highly recommend waiting for alteredqualia’s WebGLDeferredRenderer, which will include a more sophisticated integration with the three.js libary. You can follow the discussion on github.

WebGL – Deferred Pointlights. New demo and source released

Hi,

the source of the previous demo as well as the new demo will be released over at the three.js forum soon.
You can follow the discussion here.

Happy deferred lighting!

WebGL – Deferred

It took a while, but I finally found the time to play around with WebGL and three.js in particular. I was overly impressed by Florian Bösch’s WebGL demo showing an implementation of deferred irradiance volumes, and so I decided to try to write my own deferred renderer for three.js. You can check the live demo at our demo section at redPlant.

It currently supports point light sources as well as deferred shadow maps. It does not yet support everything else such as spot lights, point light shadows, etc… There’s still a lot to do.

The pipeline works roughly as follows:

  • In a first pass store depth as postprojection z/w to a floating point rendertarget.
  • The second pass stores view space normals into a rendertarget.
  • In a third pass render a shadow map for a simple directional light source. This is just plain old shadowmapping.
  • Next render a proxy sphere geometry for each point light inside the scene. Inside the fragment shader for this sphere, sample the depth buffer and reconstruct the pixels view space position by unprojecting z/w and multiplying it with the inverse projection matrix.
  • Figure out the lights position in view space and calculate its attenuation with respect to the pixels view space position. I’m using the attenuation formula from this guy.
  • Write the result into the framebuffer. Repeat this step for each light source and accumulate every lights contribution.
  • In the last pass the lightbuffer is sampled by using the uv’s of a fullscreen quad.
  • The pixel’s view space position is again reconstructed as described above.
  • The occlusion of the shadow map is determined by projecting the reconstructed view space position into light space. This is done by multiplying view space position with the inverse view matrix. The result is the world position. Multiplying with the light’s viewProjectionMatrix yields the light clip space position.
  • Depth of the projected position is compared with the corresponding pixel from the shadowmap and the pixel’s occlusion can be determined. Standard deferred shadow mapping, so to say.
  • In a last step compute the directional light’s contribution based on it’s position and the view space normal from the second rendertarget.

The performance is not necessarily jaw-dropping, it can however handle 1.500 point lights on a GTX560. The demo renders around 440 point lights plus one directional light.

I’m sure I will release the source some day, but before that I need to clean up a couple of things. There is still a lot of room for improvements.

In this context, I would like to also point out that we have another demo, that demonstrates how WebGL can be used for realtime product configuration and visualization. The example shows a realtime configurator for furniture and allows the user to freely switch between different materials for pillows, seats and other components.

That’s it for now.

Edit: I reduced the number of lights in the demo, as 440 seemed a bit too heavy for some mobile cards.