Jump to content
  • entries
    943
  • comments
    5,899
  • views
    923,728

Lighting optimizations in version 2.31


Josh

2,688 views

 Share

I got the volume intersection tests working, and it won't be hard to extend this to make trigger and fluid volumes. The image below shows a point light divided up into six volumes. Each pyramidal volume represents the camera frustum of one face of the shadow cubemap. In version 2.3 and earlier, whenever an object moves within the spherical volume of the point light, the shadow is considered invalidated, and all six faces of the shadowmap are redrawn. This is why point lights are so expensive to render compared to spot lights, which only require a single draw when the shadow is refreshed. The shadow updating was originally designed this way because it was thought that a geometry shader on shader model 4 hardware would allow rendering all six faces in one pass and provide a performance improvement. However, geometry shaders didn't turn out to be a good solution.

 

blogentry-1-12653312384328_thumb.jpg

In version 2.31 the engine will only redraw those faces that have been invalidated. Volume tests are used to determine which volumes an object intersects. The oil drum in the image would probably only invalidate one volume of the shadow if it moves. Of course if the light itself moves, all volumes are invalidated, but you already know a moving point light can be expensive to render.

 

There's another technique I want to implement, which I am calling double-buffered shadow maps. This involves storing two copies of a shadowmap, one for static geometry and the other for dynamic geometry. In the example below, the static room and equipment would be rendered to the static shadow map, and the oildrum and any other moving objects would be rendered to the dynamic shadow map. Whenever the dynamic shadowmap is redrawn, the contents of the static shadow map are first copied to it. If any static object moves, both the static and then the dynamic shadow map would be updated. This would make it so that instead of re-rendering all the objects around the point light, the engine would only have to copy the static shadowmap contents, and then render the dynamic objects on top of that. This will yield a huge boost in performance in scenes with lots of point lights.

 

I've had these ideas for a long time, but the reason I am devoting time to them right now is because a game is coming out relatively soon that uses Leadwerks Engine, and I want it to be the best it can be. You know who you are. :)

 Share

6 Comments


Recommended Comments

LE Tetris II? :)

 

whats the deciding factor for which shadow map a geometry will be stored to? is this something we will have to set ourselves per entity or will it automatically know by PHY or collsiontype?

Link to comment

I just changed the cast shadows checkbox to a drop-down box with more options: disabled, dynamic, and static. Existing scenes are unaffected.

Link to comment

I love this:

 

I've had these ideas for a long time, but the reason I am devoting time to them right now is because a game is coming out relatively soon that uses Leadwerks Engine, and I want it to be the best it can be. You know who you are

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...