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

ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand »

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.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT »

*** 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.
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand »

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
User avatar
MasterBel
Posts: 271
Joined: 18 Mar 2018, 07:48

Re: Physically Based Rendering

Post by MasterBel »

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!
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT »

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?
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand »

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.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT »

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
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand »

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.
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: Physically Based Rendering

Post by Silentwings »

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.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT »

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?
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand »

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

@PicassoCT does my code work?
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT »

Shame on me for loosing the link to the blob. I thought i send myself a email with it.
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: Physically Based Rendering

Post by Google_Frog »

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
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand »

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?
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT »

Alot of people turned off standard shadows for potatoes reasons in the past.
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: Physically Based Rendering

Post by Google_Frog »

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.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT »

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..."
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand »

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
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: Physically Based Rendering

Post by ivand »

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
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: Physically Based Rendering

Post by PicassoCT »

Sorry, if i annoy the crap out of you.. but i cant get this to work, and it would take me a month or two too figur out the innards of the pbr shader.

For my example unit i followed these recipes:
https://springrts.com/wiki/Shaders:IvandPBRShader

and kept my sourcecode as close as possible to
https://github.com/lhog/Zero-K/blob/pbr ... 10_pbr.lua

only modification is this line commented in api_custom_unit_shaders.lua

Code: Select all

 --mat_src = {shader = include("modelmaterials/Shaders/default.lua") or "s3o"}
I generated a unit the "operativeasset" for testing purposes which should have it all..
these are its 3d object definitions
https://github.com/PicassoCT/MOSAIC/blo ... et.dae.lua

Two texturesets where created, none of them where accepted by the shader.
Even the fallback to the default shader is not working.

The infolog is not indicative of any error:

download/file.php?mode=view&id=10965



My Repo:
https://github.com/PicassoCT/MOSAIC

If anyone has tryied this framework/ has a working setup.. i would be really happy for some pointers. Thanks.
Attachments
infolog.txt
(25.78 KiB) Downloaded 13 times
Post Reply

Return to “Engine”