http://www.garagegames.com/community/fo ... ead/136389
First set of prepwork
http://www.garagegames.com/community/fo ... ead/137917
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.
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
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.