PBR: Principles, Practice, and Prepwork

Materials, textures, lighting, postfx
  • 1
  • 2
  • 3
  • 4
  • 5
  • 17
165 posts Page 1 of 17
Azaezel
Posts: 383
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Mon Feb 16, 2015 11:50 pm
How it started:
http://www.garagegames.com/community/fo ... ead/136389
First set of prepwork
http://www.garagegames.com/community/fo ... ead/137917
Contributing crew:
Andrew Mac
Tim Newel
Haladrin
Timmy
Anis
Luis
MangoFusion

Principles:
The general high-level philosophical approach to PBR vs more traditional rendering workflows is a more accurate representation of how light bounces around a given scene,
which presents both a set of more consistent results, as well as a better set of tools to provide scene-based results. http://en.wikipedia.org/wiki/Cornell_box would be one sample thrown around as a test-case.

Workflow differences:
At the end of the day, from an artist perspective, the art pipeline largely differs in terms of specular inputs: http://www.marmoset.co/toolbag/learn/pbr-practice (jmp to inputs)
For folks already in production, and used to the old system, the conversion process at time of writing and using the current design can best be sumed up as:
1) The red channel of the specular map is used to manipulate how blurry a reflection is. (roughness).* **
2) Strip out your AO mask that you're used to baking into a diffuse texture, and put that in the green channel.* **
2) Take the alpha mask you're used to using to modulate cube mapping via 2 diffuse layers, and chuck it into blue instead for metalness.* **
http://i.imgur.com/WMjMzPz.jpg (http://i.imgur.com/etSly9A.jpg )
*note for the deferred transitional branch, we're sticking to a dot product approximation of colored specular that turns it into a single-channel result for roughness lookup)
** alternatively, tech was developed to allow swapping channel i/o around, simply do not feed the material a specular map, and instead feed it at least a metalness and roughness map, specifying channels: http://i.imgur.com/TpzSLpc.png

Present status:
I'll have more on this later, but to quickly address this end of things for folks:

Ron Kapaun wrote:Cool, I seriously thought I missed something that was 'complete'. If you are not tracking it being 'good to go' then I am all about waiting. PBR (physically based rendering) in a practical sense would be a game changer for T3D. I know and am following the current work. Just thought I might have missed something. Too be honest, I get the PBR thing, but at the SAME time, whoever is doing it NEEDS to make MASSIVE changes to the material tools as well. (since PDR uses 'special' mats).

Oh yeah, I get the deferred shading v. deferred lighting but, in the end.... isn't it just 50% and half a dozen of another? Just asking since I STOPPED following once CryEngine 2 came out. i see where one v. the other can make a difference but.... I don't see any (mathematically) difference in performance.


PBR isn't. deferred_complete refers to the last submisison-series where it was broken up, and needed clarifications for how to resolve the PRs since they conflicted when broken into steps (has since also been expanded to include additional fixes found since.Edit: and also kept up to date with development on a semi-daily basis so folks can see what they'd end up with were it rolled in). There's some prepwork in there already, like the 'specular' map being shunted on over to a scalar derived from rgb, and a reserved for metalness as an alternate to the cubemapping layer requirement in stock, and the like.

PBR proper simplifies that on down to the g and a channels for the 'specular' map (roughness and metalness respectively), since those are the highest fidelity ones for dxt5s. (also gives us an additional channel to play with for AO, once (if) we get to that point.). Also changes the specular power and strength entries on over to roughness and metalness internally and in-editor, and adds automatically applied IBL in the form of a levelinfo fallback, and envVolumes (areas taking a different ibl entry). That last may be entirely superseded by the LPV end that Mac and Jeff(r) are focusing on, depending on how that pans on out. Wil try and do up a more full report some time this week, but in the mean time, layout and thinking can best be summed up with the internal comit docs: https://github.com/GarageGames/Torque3D/pull/867

Do note that while the backwards compatible end of things was intended for inclusion in 3.7, too many other things have cropped up, so it'll likely be going up for a third review post 3.7, once the opengl/linux system is nailed down, and likely after the repo structure has been reworked (which makes sense to me at least, since theres quite a few alterations to game/core, game/shaders, and a few in game/tools that need to accompany the source-side alts.
Last edited by Azaezel on Sun Apr 19, 2015 3:59 pm, edited 6 times in total.
nophone
Posts: 1
Joined: Tue Feb 17, 2015 8:18 am
by nophone » Tue Feb 17, 2015 8:30 am
Sorry if this has been asked before, I didn't look through the whole previous thread. It sounds like you are going with the metal/roughness Disney method? What kind of perfomance hit you are seeing when moving to PBR?

I saw a mention in the previous thread about making the PBR a runtime option. This didn't make sense to me, since everything I've looked at implies that PBR requires entirely different art assets, created in a whole different mindset. I don't see how it could be something you could just switch on and off. Am I missing something? Apologies if this was already discussed.

This seems like a great way to improve the reusability of art assets, and make art easier to create in general. Looking forward to playing around with it!
Azaezel
Posts: 383
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Tue Feb 17, 2015 10:44 am
The numbers aren't anything I'd write home about at present:
(All shots taken at highest settings for maximum load.)
stock:
http://i.imgur.com/ltJBBN4.jpg
deferred:
http://i.imgur.com/awl8lGW.jpg
pbr:
http://i.imgur.com/NY144Zu.jpg

There's a few more places we can make gains, like ditching the shader-inserted linearization methodology for a hardware driven sRGB loading solution. (That end is pending an opengl -side equivalent.). Ditching the general specular-color to single-range converter left in to ease folks' transitions will also take some load off.

Additionally, to make some headroom for the calculation load, we revisited how shadows are calculated, and instead of the present stock re-render every frame, went with a 2-phase solution:
http://i.imgur.com/4KKD7iV.jpg
+
http://i.imgur.com/O6vsHZX.jpg / http://i.imgur.com/9Z4kMxq.png
How that works is pretty simple: tag a given material as a dynamic shadow caster or not, and it'll use a given light's static or dynamic listing for how often to refresh that asset's shadow. (At time of writing, for backwards compatibility, everything still defaults to rendering using the dynamic rate. 8MS was picked to ensure it's pretty much always going to be refreshed per frame, while you'll note for the pointlight, static refreshes at a rate of 1/4sec by default (but is tweakable if needed.).

On a switch... while technologically possible, from a pragmatic perspective, the experiments we attempted to run with that ended up turning it into... the kindest thing I can say is it turned into a hot mess real quick. Rewiring the gbuffer, lighting shaders, shader features... yeah. Not happening without somone absolutely dedicated to that end so we can actually get the rest of this stuff in a truly useable state.
LukasPJ
Site Admin
Posts: 348
Joined: Tue Feb 03, 2015 7:25 pm
 
by LukasPJ » Tue Feb 17, 2015 10:56 am
Wait, so there's already a PBR build?


The numbers look fine, there's a lot of odd things about the deferred shading compared to lighting. Like all the rendered terrain cells are override cells, and there is in general a higher polycount (although fewer drawcalls?) :P Also the level doesn't look like it's exactly the same :P
Azaezel
Posts: 383
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Tue Feb 17, 2015 11:01 am
Higher polycount/fewer drawcalls bit is due to the pair of shadowmaps cycling at different (in the scene the same, since scattersky is configured for dynamic shadow motion) rates. and yeah, linerization is used to get a result that closer matches art-tools spit-out for textures. (that and dear god the contortions you'd have to make to the PBR math otherwise.)
Timmy
Posts: 307
Joined: Thu Feb 05, 2015 3:20 am
by Timmy » Tue Feb 17, 2015 11:17 am
You have made awesome progress Az, well done :mrgreen: :mrgreen:

Slightly off topic but one of the biggest things i have seen that is really holding T3D back, is just how CPU bound it is. Using T3D now on a decent size level it quickly becomes very apparent how under utilized the GPU is. It needs multi threading.
Azaezel
Posts: 383
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Tue Feb 17, 2015 11:19 am
Host of folks need thanking for getting it this far. Matter of fact, updating the OP with Da List, since it occurs to me not everyone follows links...
LukasPJ
Site Admin
Posts: 348
Joined: Tue Feb 03, 2015 7:25 pm
 
by LukasPJ » Tue Feb 17, 2015 11:37 am
@
User avatar
Timmy
started the multithreading discussion at this post.
Timmy
Posts: 307
Joined: Thu Feb 05, 2015 3:20 am
  by Timmy » Tue Feb 17, 2015 12:08 pm
Timmy wrote:You have made awesome progress Az, well done :mrgreen: :mrgreen:.


Sorry my mistake, everyone involved of course ;)

LukasPJ wrote:@Timmy started the multithreading discussion at this post.


Sweet no problem.
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Tue Feb 17, 2015 5:28 pm
Azaezel wrote:Higher polycount/fewer drawcalls bit is due to the pair of shadowmaps cycling at different (in the scene the same, since scattersky is configured for dynamic shadow motion) rates. and yeah, linerization is used to get a result that closer matches art-tools spit-out for textures. (that and dear god the contortions you'd have to make to the PBR math otherwise.)


The static/dynamic shadowmap mixing will take up more memory usage because of both maps, but the total rendered polys should be roughly the same since stock renders all the shadows all the time. Unless things are being shadow casted more than once, there should be no difference in polys with static/dynamic shadow system.

I have no idea why deferred shading is reporting more polys in those screenshots. The reflection on the water seems very different, and would have a major impact on polys if it were not working correctly, or rendering different distances in stock. Additionally, if you're using dynamic cubemaps on anything for PBR in that scene you're gonna tank your performance and increase your polys significantly.
  • 1
  • 2
  • 3
  • 4
  • 5
  • 17
165 posts Page 1 of 17

Who is online

Users browsing this forum: No registered users and 1 guest