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
Posts: 112
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.
1 x

User avatar
Journeywar Developer & Mapper
Posts: 10026
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.
1 x

User avatar
Posts: 112
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.


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.
(3.38 MiB) Not downloaded yet
6 x

Posts: 65
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!
1 x

Post Reply

Return to “Engine”