Physically Based Rendering - Page 3

Physically Based Rendering

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

User avatar
ivand
Posts: 134
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 27 Jan 2019, 12:51

Thanks @MaDDoX. Glad to hear, my work resonates.

Yeah as far as number of materials, the only limitations are:
  1. ALU (**) and bandwidth performance. I have GTX 1070, so my card does loops and texture fetches in the amounts, the shader requires, easily. But it can put some strain on less performant GPUs. Only testing can reveal the real limitations here as I don't see them locally.
  2. GPU memory footprint. The way spring draws maps (SMF) currently that main texture "diffuse" is broken down into 1024x1024 chunks during compilation stage and then rendered in sequential calls. Together with @gajop and @Anarchid we decided that the PBR terrain shader would NOT follow the "tiled" principle for now, instead all textures are defined on the "global" level. I'll leave out rationale for such decision, but mention that in such approach textures themselves might need to be better details/larger file size. Also as @MaDDoX pointed out, the rendering pipeline can leverage up to 32 textures (spring and general mid-age OpenGL version limitation). These together impose increased demand on GPU memory size. Again only testing can reveal details.
  3. Number of addressable texture units - 32. Implementation (algorithm) itself has no limitation on the amount of materials artist defines. Can be one per map, could be 100. However usually materials are represented with a set of textures and distribution of materials is represented with texture as well. So here, the number of textures that can be bound at a given time kicks in. The practical limitation is that the number of simultaneously used textures cannot exceed 32. That said, the number of textures available to the artists is even less, because auxiliary textures like $shadow, $reflection, $info, $normals, BRDF LUT, POM-prepass (in the future) eat up resources from the same pool. Realistically only around 24 textures will be available for the artists (***).



(**) ALU - An arithmetic logic unit.
Also there exist two fundamentally different material blending principles.
  • One is output blending, the one is used now. Basically what it does it takes non-zero weighted materials, evaluate material shades (PBR diffuse, specular, IBL) and then the outputs of the each material shading are mixed together according to the weights.
  • Another one is inputs blending (currently not implemented). This is the mode where PBR inputs, like color, metalness roughness, etc are mixed according to weights in the first place and then the resulting/pre-mixed PBR inputs are used to to perform PBR shading evaluation (PBR diffuse, specular, IBL) only once per pixel. The use of such blending principle will reduce the ALU and bandwidth load drastically.
    Why is it not default? Some smart folks told me the end result would look incorrect. Sure it will not be correct, however I'm not hesitant to get a proof myself how big quality hit it will be. So inputs blending is on my (long) TODO list.

(***) There might be a place for some tricks, to alleviate this limitation a little bit (like a prepass to see what materials are used by a specific tile), however this is not reliable nor trivial to do. The real solution is to adopt OpenGL bindless textures or go vulkan. Although I'm not even sure the amount of the bound textures will be a bottleneck.
0 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10225
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT » 27 Jan 2019, 13:14

*** Every single trick ever used turned into a limitation later in game. The tile system is super performant, but does not allow for efficient texture overdraw. Kloot is busy removing the old trickery, lets not put new trickery on top of that.
0 x

User avatar
ivand
Posts: 134
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 08 Feb 2019, 01:03

Small update from my side on terrain PBR.

The project is not dead (yet), despite I haven't been able to find volunteers for testing the concept.

Last couple of week or I so I spent on making the soft shadows. While the current shadows are a bit better than standard spring shadows, because of the amount of taps used in Percentage Closer Filtering, it still looked quite dumb in a way that shadow softness was never the function of distance between occluder and occludee, but was rather a static property. The soft shadow algorithm was supposed to take the aforementioned distance into account and soften edges of the shadows so that shadow has hard part (umbra) and soft part (penumbra).

To implement such shadows people mostly use variant of NVidia PCSS algorithm, so did I.
Unfortunately the implementation that worked well in other frameworks and tech demos, was stubbornly refusing to work as expected on spring soil, which led to huge amount of time spent to debug it and trying to make it work.

I'm not completely satisfied with visual result, even less satisfied with implementation (it has some value hackery I'm ashamed of inside).
Anyway, here we are. On the screenshot below there are two occludee units that cast shadows on the ground. One is up in the air, so shadow is more soft and a bit less pronounced, another one is on the ground, so shadow is hard and firm. Make sure to open up full-sized attachment to observe it better.

Image

There is performance impact of enabling soft shadows, so I plan to introduce configuration presets and feedback mechanism to change the implementation and quality based on the average FPS. This, though, goes to my pie-in-the-sky list, as currently there is no demand for such functionality.

P.S. I'd like to sincerely thank Kloot, who was able to provide help, engine implementation and advises in timely and delicate manner.
Attachments
screen00357.png
(3.38 MiB) Not downloaded yet
10 x

MasterBel
Posts: 159
Joined: 18 Mar 2018, 07:48

Re: Physically Based Rendering

Post by MasterBel » 09 Feb 2019, 03:21

ivand wrote:
08 Feb 2019, 01:03
I'm not completely satisfied with visual result, even less satisfied with implementation (it has some value hackery I'm ashamed of inside).
Don't be! It looks beautiful and you were working with limits. It's awesome that you found a way around those limits, no matter how hacky it is!
… that feels super cheesy since I'm not a spring dev but whatever :D Thanks!
2 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10225
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT » 09 Mar 2019, 22:31

If one where to do a whole rts with this- would you recommend a atlas- or having all materials as texture per unit baed into those textures?
1 x

User avatar
ivand
Posts: 134
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 10 Mar 2019, 17:51

PicassoCT wrote:
09 Mar 2019, 22:31
If one where to do a whole rts with this- would you recommend a atlas- or having all materials as texture per unit baed into those textures?
If you talk about models PBR, It's hard to argue against atlases as they reduce memory footprint and don't need to be swapped as rendering loop goes from one unit to another. Though the performance tax of working with per-unit textures should not be too noticable for modern GPUs.
1 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10225
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT » 14 Mar 2019, 23:11

A wild naked victory dance later:

Image


Now for some texturing of my own. It really looks awesome beyond compare..

only trouble is my day and nightshift.. how does one accomodate a dynamic suncolour into the shader?
Attachments
screen00018.jpg
(278.19 KiB) Not downloaded yet
2 x

User avatar
ivand
Posts: 134
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 15 Mar 2019, 05:14

Hi! Thanks for the interest!

If your request is about the sun color, then this https://github.com/lhog/spring-models-p ... ff9b31f58f should do the trick.
NB: I haven't tested this yet, if it doesn't work, please report back.
NB2: PBR doesn't operate with "ambient", "diffuse", "specular" terms of sun color as defined in spring, so for now I tied "diffuse" to be out sun color. Perhaps we should combine "diffuse" values with something else. Only testing on real maps can reveal how mappers set up sun colors.

Sun sky position should have been operational without any recent changes already.
1 x

User avatar
Silentwings
Moderator
Posts: 3586
Joined: 25 Oct 2008, 00:23

Re: Physically Based Rendering

Post by Silentwings » 15 Mar 2019, 13:39

Many maps use a combination of baked & dynamic shadows (from a chosen sun dir) to create their terrain shadowing - consequently in most cases the game should not risk changing the sun pos.
1 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10225
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT » 15 Mar 2019, 16:57

Thuse the hacks of the past, become the limitations of the future. What now? Take a negative light an do a prepass, to shadow all things equally?
1 x

User avatar
ivand
Posts: 134
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 16 Mar 2019, 05:09

I'm not sure I know what the baked shadow in spring map context is.
Can someone enlighten me?

@PicassoCT does my code work?
0 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10225
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT » 16 Mar 2019, 09:58

Shame on me for loosing the link to the blob. I thought i send myself a email with it.
0 x

Google_Frog
Moderator
Posts: 2436
Joined: 12 Oct 2007, 09:24

Re: Physically Based Rendering

Post by Google_Frog » 17 Mar 2019, 09:18

A baked shadow in the context of maps is a map with shadows drawn as part of the map texture. Here is an example: https://zero-k.info/Maps/Detail/9766
0 x

User avatar
ivand
Posts: 134
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 17 Mar 2019, 10:55

Yeah I kinda guessed the meaning. What I really wanted to know was why do that in the first place?

Shadow mapping will be done for units and features anyway so it is not about performance.

Are standard spring shadows not good enough? Are some nuances of visuals not covered by standard shadows?
0 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10225
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT » 17 Mar 2019, 12:14

Alot of people turned off standard shadows for potatoes reasons in the past.
2 x

Google_Frog
Moderator
Posts: 2436
Joined: 12 Oct 2007, 09:24

Re: Physically Based Rendering

Post by Google_Frog » 17 Mar 2019, 13:59

Spring shadows may not have existed at the time. There was definitely a time where shadows could not be used at the same time as LOS view.
1 x

User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10225
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT » 19 Mar 2019, 19:53

kloot wrote:"This engine needs a potatoe blight, something biblical, like the irish famine. Some event to once and for all up the standards, if necessary by lowering those unworthy into a ditch..."
2 x

User avatar
ivand
Posts: 134
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 30 Sep 2019, 20:16

After I pronounced my attempts to plant PBR on spring soil dead several months ago, I've actually come across a good way to estimate the environment irradiance from the reflection map.

The lack of sane radiance was the bane of my previous PBR implementations, because units looked vastly different on different maps/environments and it was impossible to find the good looking middle ground.

With the new technique to sample diffuse and specular environment maps, the PBR idea might have come back. The shader is currently implemented in BAR/BYAR and it strictly follows the reference PBR implementation that can be found here: https://www.shadertoy.com/view/3dy3zD

After the previous failures, I'm a bit hesitant to celebrate, but the first shots look good and sane.

Metalness 0, Roughness 0
Image

Metalness 0, Roughness 1
Image
Attachments
M0R1.png
(5.6 MiB) Not downloaded yet
M0R0.png
(5.64 MiB) Not downloaded yet
4 x

User avatar
ivand
Posts: 134
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand » 30 Sep 2019, 20:17

Metalness 1, Roughness 0
Image
Metalness 1, Roughness 1
Image

One can compare these 4 extrema as depicted on the tank with reference "sphere" implementation https://www.shadertoy.com/view/3dy3zD

P.S. Some in-game shot (the metalness-roughness are not even specifically tuned for PBR, but rather inherited from older non-PBR implementation) on the dark map (dark environments used to be a big problem previously):
Image
Attachments
screen01224.png
(3.54 MiB) Not downloaded yet
M1R1.png
(5.61 MiB) Not downloaded yet
M1R0.png
(5.69 MiB) Not downloaded yet
4 x

Post Reply

Return to “Engine”