PBR: Principles, Practice, and Prepwork

So. 3 it is then. If were going the route of bypassing simple shadergen-based texture lookups anyway, going whole hog with the thing and tacking on one more thing that it's not built for. Scripted channel specifications.

http://i.imgur.com/kO3oIUy.png

General result should be the capacity to feed 2 additional maps into an origional (went with roughness at present) and bind that to the material reference. (Folks can see how that's generally handled https://github.com/GarageGames/Torque3D/blob/7d376386d1e01790eb57300780d967e8ffcda347/Engine/source/materials/processedMaterial.cpp#L451-L457)

Haven't taken a serious look into a cached texture file yet, probably won't for a good long while, though if someone wants to look into that end, by all means. Still need to fully script it up and tie things together for a pragmatic usage test. (And roll in LPV and apply those results.)

Currently the alpha channel in diffuse defines reflectivity of the cubemap, will this stay this way?

For the system in design, you could point the texture you're using for layer1 at the metalness slot and select alpha, yes. *******Always assuming this doesn't end up blowing up.

http://i.imgur.com/ykWIO9x.jpg / http://i.imgur.com/TfSIQU2.jpg

https://github.com/Azaezel/Torque3D/commit/f03e2f607708e6ca03c70f116b77e96052d48096

Beat it up. Known Issue Notes: Still need to handle .dds files gracefully. *(FIXD. thanks mango)

Edited February 25, 2015 by Azaezel

Alright, that's pretty slick, there :D

@az

From digging in the DDS code for a minute I'd say you'll want to look at this bit:

https://github.com/Azaezel/Torque3D/blob/9b2b4ed7da47a33cbdcea92c33bcd7d6cdb4fcb3/Engine/source/gfx/bitmap/ddsLoader.cpp#L751-L770

It puts the DDS into a GBitmap and then saves it to disk. Should be trivial to change that into returning the GBitmap after creating it. Then you can just treat it like any other map.

Op updated with workflow flexibility support alterations.

Been a bit since there was a status report, so:

Still working out a few kinks, but Mac threw over a revision that fills in mips for the 3dtexture, which allowed us to integrate roughness:

TODO list there: need to track down why there's a rendering conflict with multiple viewports (side by side rendering not shown in the vid, but the material cube display should give a good hint of how that distorts). Need to do up a bit of research into the diffuse texture angle. (Hangs.).

looking good

This looks pretty much like the rendering in modern games, so this is the feature that makes them look so much different than default Torque.

So on the LPV thing. Been a bit, still more to go, but: https://youtu.be/0wJzbkNMLq4

Overhauls include shifting to a more scalable 'raycast' methodology that stops once the .a channel has accumulated to 1 or more (presently using detected structure as the stopping point there), voxel display cleanup, UV detecton cleanups, texture caching, and general standardization.

Left On Da List for LPVs:

1) Reloading maps can and will crash, so something isn't being freed properly. (resolved)

2) https://github.com/GarageGames/Torque3D/issues/1266

Left On Da List period:

1) Screenspace Reflection.

2) Should probably give envVolumes the same projection-treatment rather than mapping every object and simply having those control what cubemap is used. (not a *requirement* so much as a *if there's time*)

Thanks for the hard work Azaezel.

Downloaded your latest git and noticed that the Diffuse red channel seems to be modulating the roughness also.

The packed Spec map works as expected but the smoothness/cube map reflectivity seems to also depend on whether I empty the

red channel of the diffuse map.

I know it's a work in progress and it's going to rock when it's done :)

Thanks again!

Thanks. Will look into that.

Edit: quick doublecheck doesn't show that occurring this end... mind dumping a material def and a screenshot?

Edit 2: shots: http://i.imgur.com/tNCRnpD.pnghttp://i.imgur.com/vdphrmw.jpg

The two images and the spec map in photoshop plus two Torque screenies. Only "reflective" without the diffuse red channel.

Tested it quite a bit and it seems that both the red channel in the spec map and the diffuse map affect roughness.

This is awesome work!

Cerberus gun looks nice in OpenGL :)

EDIT: It does matter what the color is for the diffuse map, approx center gray allows cube map reflect with the non-red channel diffuse map.

Simply swapped diffuse textures in the same material for the screenshots.

http://i1260.photobucket.com/albums/ii567/aurobooth/diff_all_zps2zhhcy7c.png

http://i1260.photobucket.com/albums/ii567/aurobooth/withRedChan_zps9j4kldf7.png

http://i1260.photobucket.com/albums/ii567/aurobooth/noRedChan-ps_zpscrd4icld.png

http://i1260.photobucket.com/albums/ii567/aurobooth/noRedChan_zps6ukuremo.png

Spec map

http://i1260.photobucket.com/albums/ii567/aurobooth/spec_zpswi3fxdma.png

Material

 

singleton Material(Grid512_ForestGreenLines_Mat)
{
  mapTo = "Unnamed";
  diffuseMap[0] = "core/art/grids/512_forestgreen_lines";
  materialTag0 = "TestMaterial";
};



singleton Material(PBRTEST_PBRMetal)
{
  mapTo = "unmapped_mat";
  diffuseMap[0] = "art/shapes/textures/Metal_A.dds";
  normalMap[0] = "art/shapes/textures/Metal_N.png";
  roughness[0] = "1";
  metalness[0] = "50";
  specularMap[0] = "art/shapes/textures/Metal_S.dds";
  translucentBlendOp = "None";
  materialTag0 = "Miscellaneous";
};

singleton Material(myWood1)
{
  mapTo = "unmapped_mat";
  diffuseMap[0] = "art/shapes/textures/Wood1_A.dds";
  normalMap[0] = "art/shapes/textures/Wood1_N.png";
  materialTag0 = "Miscellaneous";
};

singleton Material(myGrey)
{
  mapTo = "unmapped_mat";
  diffuseColor[0] = "0.341176 0.341176 0.341176 1";
  materialTag0 = "Miscellaneous";
};

singleton Material(ucityHealthKit)
{
  mapTo = "unmapped_mat";
  diffuseMap[0] = "art/shapes/items/kit/healthkit_d";
  normalMap[0] = "art/shapes/items/kit/healthkit_n";
  pixelSpecular[0] = "1";
  specular0 = "0.5 0.5 0.5 0.5";
  specularPower0 = "32";
  materialTag0 = "Miscellaneous";
};

singleton Material(MYRock)
{
  mapTo = "CubeSurf";
  diffuseMap[0] = "art/shapes/rocks/MossyRock02.png";
  specular0 = "0.5 0.5 0.5 0.5";
  specularPower0 = "32";
  materialTag0 = "Miscellaneous";
};





singleton Material(MYRustySlats)
{
  mapTo = "unmapped_mat";
  diffuseColor[0] = "0.231373 0.231373 0.231373 1";
  diffuseMap[0] = "art/Greg/TestDiff.png";
  normalMap[0] = "art/Greg/X-spec_n.png";
  specularMap[0] = "art/Greg/X-spec.png";
  specular0 = "0.5 0.5 0.5 0.5";
  specularPower0 = "32";
  materialTag0 = "Miscellaneous";
};

singleton Material(myDiffuseRedChan)
{
  mapTo = "rustslats";
  diffuseColor[0] = "0.282353 0.282353 0.282353 1";
  diffuseMap[0] = "art/Greg/X-dif2_noRed.png";
  normalMap[0] = "art/Greg/X-spec_n.png";
  specularMap[0] = "art/Greg/X-spec.png";
  specular0 = "0.5 0.5 0.5 0.5";
  specularPower0 = "32";
  materialTag0 = "Miscellaneous";
};

 

Cheers :)

Will take another look at it. On re-review, looks like something also seems to have gotten mangled for translucent materials. They're detecting they're presence of the cubemap feature, but not properly passing the relevant environment map data along.

While I'm looking into that end of things, if someone wants to stick a second pair of eyes on this other that @koros brought up to speed things along, the relevant entries are

https://github.com/Azaezel/Torque3D/blob/PBR/Engine/source/shaderGen/HLSL/shaderFeatureHLSL.cpp#L1801-L1935

and https://github.com/Azaezel/Torque3D/blob/PBR/Templates/Full/game/shaders/common/lighting/advanced/deferredShadingP.hlsl#L37-L40 (revised in the main PBR branch as of tonight)

In addition, James Stanley has given me permission to note that he threw over a copy of his wetness shader work for conversion, as well as a few other things. Known issues there: screenspace normals seem a bit off for face orientation detection.

*edit: and thanks for the reminder on the cerberus thing. Thought I'd killed that on off already. Turns out that was only in the current working-branch.

Playing with your realtime reflections... Nice! +1

Reflection sometimes seems to get "stuck", bringing up the options dialog or firing a decal onto the object sometimes "updates" the reflection.

Apologies if I am bringing up known issues, just really busy and haven't read everything yet.

Great work!

Koros, could you link to the test "X" textures you were using? Also for shits N giggles, what graphics card was this on?

System

AMD 6350, Win8.1 8GB

GPU AMD Radeon HD 7700, Driver v. 14.501.1003.0

Images

http://i1260.photobucket.com/albums/ii567/aurobooth/X-dif2_noRed_zpssjesvlev.png

http://i1260.photobucket.com/albums/ii567/aurobooth/X-dif2f_zps3vlbgihe.png

http://i1260.photobucket.com/albums/ii567/aurobooth/X-diff_zpsqjoh44v5.png

http://i1260.photobucket.com/albums/ii567/aurobooth/X-spec_zpsahkfqpcv.png

http://i1260.photobucket.com/albums/ii567/aurobooth/X-spec_n_zpsqcnvekhd.png

Photobucket preserves the channels in the png afaik ;)

Reflections

noticed that the realtime reflections getting "stuck" behavior is much better for objects scaled 1,1,1

Still occurs but objects scaled in the editor mess with the RT reflections a lot more or don't work at all.

Cheers

Does look like there's a bit more to do on the dynamiccubemap front, assuming we don't end up just straight up ripping it out for screenspace reflections. at minimum, as you noted, scaling is off, and refreshing seems to 'miss' occasionally. also need to gen mips for the thing so roughness can have it's say in the matter. (also should note that aside from pbr conversion, and tsstatic support, it's stock code, just really really hidden)

Speaking of which, both the core and branch PBR forks updated for initial translucency support, though it needs more review:

Back to the roughness report specifically, did you mean albedo impact on metalness?

if so, yeah, looks like that's still a bit 'off'. (edit: should also note oxynary was kind enough to cook up a mipcubemap for debugging roughness values: http://i.imgur.com/n47GGMV.png)

tempfix up so that there's a minimum amount of reflectivity, though the math is a bit suspect leading up to that point.

Still using the old build. I'll try to find time to test the new stuff. Youtube video looks nice.

Just started playing around with metalness, was busy checking out the dark skin :D and the terrain texture layers :(

At least with the Metalness workflow I can use some diffuse textures with roughness, I'm not gonna complain! You're putting a lot of work into this.

Been a while since I messed with glsl back in my Irrlicht days, just hacked away and got some vsm/pssm shadows going, not really up to speed on Torque's shaders.

I'll help where I can, testing for now :)

Fixed a major leak with composite textures. - Forgot to clear out the temp gbitmaps. Still a minor one lurking around, looks like.

Status for the week:

1) JeffR and I threw more known-quantity substance designer materials at the results we were getting, and found that it was getting generated in the form 0=rough, 1 = smooth, which matches the BGFX samples andrew mac has been poking at, so to cut down on the confusion there internal and script variables were altered over to smoothness. also adopted a somewhat more truncated version of the math there. (stops at mip level 5, since the box was showing otherwise for all present cubemaps). Apologies for the confusion there.

2) Still looking into a more projective solution for IBL vs per-object instance wrapping to better support terrains, though did make it a point to expose RT3 to the scripting subsystem as a fallback so if nothing else, we can hunt down and re-order the lightmapping buffer so it's applied before light shadowcasting/brightening, not after.

3) Got a bit more work on exposing Opengl 3dTextures to the lock/unlock subsystem, though it's presently spitting out the folowing in debug:

OPENGL: GL_INVALID_OPERATION error generated. Invalid PBO operation. (x6)

OPENGL: GL_INVALID_OPERATION error generated. Query object not found.
OPENGL: GL_INVALID_OPERATION error generated. Cannot begin query on an active query object.
OPENGL: GL_INVALID_OPERATION error generated. <target> does not have an active query.
repeating

Sounds good...hey did you ever find out or figure out the issue why the color to the house was gray?

The washout bit falls under that 'need to review the math' end of things that's ongoing. Probably have time to sort that out after point 2's finalized in some form, since IBL is applying at present in the wrong order vs light shadow darkening/birghtening (most obviously viewed via sticking a metallic material on outpost and letting the light cycle for a bit)