It is currently Mon Oct 07, 2024 6:17 pm


13/11/2018

Get the latest news here.
  • Author
  • Message

dimis

  • Posts: 1
  • Joined: Sun Jan 20, 2019 3:50 pm

Re: 13/11/2018

PostWed Jan 23, 2019 5:39 pm

Hi Evolved, nice to see that you are still working on Advanced Lighting! Your current system look so up to date, i am very amazed with the results.
I would like to ask, which DBpro version you use to compile your included programs (and maybe if there are any other pluggins required besides jGfx)? Your programs run perfectly, but when i work with the code to add my models for testing, after compiling and running i get a number of bugs and error warnings. Most of them occur when i compile with the GitHub version with the 9ex upgrade, there are less bugs when i compile with an old DBpro version.
User avatar

EVOLVED

Site Admin

  • Posts: 74
  • Joined: Wed Mar 05, 2014 7:52 am

Re: 13/11/2018

PostFri Feb 15, 2019 1:27 pm

An update to the adv lighting has been made, this incorporates batching for pont and spot lights and Im going to start working on batching system for objects which will be more complicated. Shadow maps have also been slightly altered to use a poisson disk filter, but Im still not happy with the current shadow map method. I'm seriously contemplating on going back to EVSM which has better filtering and generally faster, but do produce errors in certain circumstances. I might work on a separate version with EVSM to see if it worth going back to.

@dimis
Im using dbp 1.0761, I did try the 9EX upgrade but it was seriously unstable when I tried it. all my dbp projects would fail to compile, so I went back to the last stable version. jGfx is the only plugin required.
User avatar

EVOLVED

Site Admin

  • Posts: 74
  • Joined: Wed Mar 05, 2014 7:52 am

Re: 13/11/2018

PostWed Feb 20, 2019 9:53 pm

So after geting a bit annoyed with constantly tweaking the current shadowing setup in an attempt to get better filtering I've decided to give exponential variance shadow mapping (EVSM) another try. This was the technique I using previously for quite some time, but There are some issues with this shadowing approach but 90% of the time they are pretty decent.

Advantages

Performance is better than the current setup, but not by as much as I was hoping. There are reasons for this such as having to render directional lighting and ambient lighting independently as I need to fit 4 shadow maps within the 8 texture limit, the shadows also receive a post gaussian blur. My frame rate is now around 340-400fps with EVSM whereas with the existing shadowing I'm getting 280-350fps, so around a 50 frame improvement which is not bad. I think the biggest gain will be with point or spot lights that are shadow casting and overlap each other. With the existing approach an overlapping point and spot light will esaly cause my frame rate to drop to below 200 thanks to the oversampling of shadowmaps (this is a big problem and ultimately can result in inconsistent frame rate), where as with EVSM only requires a single lookup.

Filtering is also an big advantage thanks to shadow maps keeping a linear min/mag filter, as a result the shdowmaps also have far less aliasing/shimmering artifacts which is typically noticeable with the existing approach. Shadows are blurred using a 7x7 weighted gaussian blur.

Disadvantages

Variance shadow mapping on it own is a prettey useless technique thanks to shadow with high depth complexity can cause penumbra to prodce a leek resuling light bleeding. Applying an exponential wrap to shadows depth helps to greatly reduces bleeding artifacts but they will occur when shadows overlap at the base of casters. Another big issue is that small shadow casters can be lost during the blur pass as brighter pixel will always overwrite darker neighboring pixel.

Another problem is every object has the ability to receive a shadow so all objects have to be drawn to the depth map, which means we cannot pick and choose whether an object should act as a caster or not. This is cause of a concern when it comes to draw call optimization as more objects will need to be drawn than are necessary. I will have to implement shadow caching for static lights (this something I had to do previously when using EVSM), that will capture static objects into its own depth map then when it come to updating we only have to draw dynamic objects that are moving within the bound of the lights shadowmap.

Memory is probably the biggest issue, for directional light I'm useing three 1024² 32bit (r16g16) depth textures used for static and dynamic rendering and six 1024² 64bit (a16r16g16b16) textures used for combining dynamic/static and gaussian blur. Thats approximately 60mb which is more than the gbuffer which is approximately 59mb at 1440p, And thats just for the directional light. When I start working on local point/spot lights, shadowing going to consume even more vram and in dx9/32bit apps there is a set limit. This is definitely a concern and will most likely result in removing the current virtual texture terrain system that consumes a ridiculous 216megs and go back a more simpler less memory consuming but potentially slower approch.

Here's a video capture I did earlier, errors are quite hard to see but are still there.
https://www.youtube.com/watch?v=lXFdYuMjOnA

Screenshot of trees sample.
Image
User avatar

just1

  • Posts: 10
  • Joined: Tue Mar 25, 2014 2:04 pm

Re: 13/11/2018

PostThu Feb 21, 2019 2:11 pm

What about classic shadow depth technique?
:idea:
It takes less memory and only one channel per split.
And up to 2048x2048 size.
I think there are so ways to improve quality and avoid aliasing,shadow acne and so on.
You can check this tip: http://www.dissidentlogic.com/old/images/NormalOffsetShadows/GDC_Poster_NormalOffset.png
Also 32bit shadow depth shall produce nice results or am i wrong?
Previous

Return to Announcements



cron