PBR: Principles, Practice, and Prepwork

[Azaezel]

Converting from fan to strip requires a re-alignment of verticies...

Sample: https://github.com/Lopuska/Torque3D/commit/bcc41c211774f64dc2f74de07659db41bd539b3f#diff-b23928a4f51b948ce21b6b298da60becR1042

But this commit is already in the current D3D11 code and I shouldn't worry about it or should I?

And is there somewhere explaining what are those GFX draw types or a good documentation about how the GFX works in T3D or common engines? I really need to improve my knowledge in this area... Anyway, out of topic, might post about it somewhere else...

 

No, but if the add on you're using uses a fan, it might need conversion due to the different way things are unwound when 'wrapping' around the model:

https://github.com/GarageGames/Torque3D/blob/2044b2691e1a29fa65d1bdd163f0d834995433ce/Engine/source/gfx/gfxEnums.h#L62-L72

converts to:

https://en.wikipedia.org/wiki/Triangle_fan (deprecated)

https://msdn.microsoft.com/en-us/library/windows/desktop/bb206273(v=vs.85).aspx (list)

https://msdn.microsoft.com/en-us/library/windows/desktop/bb206274(v=vs.85).aspx

[Mud-H]

EDIT: I was all wrong if you read previous post version

When running in DEBUG, I get an AssertFatal in gBitmap.cpp

engine\source\gfx\bitmap\gbitmap.cpp(778,0): {Fatal} - Bad internal format

The mInternalFormat that cause it is: GFXFormatR5G6B5

In bool GBitmap::getColor(const U32 x, const U32 y, ColorI& rColor) const there's no case for that format but in a previous function call (That I can't find anymore but was used in my previous post...) there was a case for this format. Should it be add in the getColor function or should I find out which texture cause it and update it?

This is on the latest PBR branch code. I've got it previously and I simply changed it to AssetWarn to not "break" the debug session.

EDIT: Changing it to AssertWarn didn't work this time, I had to stop the debugging after a while of getting the AssertWarn. I have 450000 of those in my console.log...

f:\t3dprojects\t3dlab\engine\source\gfx\bitmap\gbitmap.cpp(778,0): {Warning} - Bad internal format

 

Found out the texture that cause it, it's a texture I use for smoothness, the getColor get called after GFXTextureManager::createCompositeTexture. I know some of my texture are wrong... do the roughMap, aoMap and metalMap should all be greyscale?

.

The code I post first was from checkForTransparency, I don't know why VS sent me there, it's not in the callstack but the problematic format is listed there.

bool GBitmap::checkForTransparency()
{
  mHasTransparency = false;

  ColorI pixel(255, 255, 255, 255);

  switch (mInternalFormat)
  {
     // Non-transparent formats
     case GFXFormatL8:
     case GFXFormatR8G8B8:
     case GFXFormatR5G6B5:

[Azaezel]

Ok, so the relevant commit for composite textures'll be https://github.com/Azaezel/Torque3D/commit/f03e2f607708e6ca03c70f116b77e96052d48096#diff-c6d03425265132a1b926a34bcda42fec

Specifically, https://github.com/Azaezel/Torque3D/blob/PBR/Engine/source/materials/processedMaterial.cpp#L459-L479 for context. What we do for quick prototyping (and again, I cannot stress this enough, I don't recommend slaping 3x the texturesheets down, it's just for a quick look.) is feed it the three textures into the resource manager and substitute the resulting cpu generated bitmap for the compostie texture (shown above those entries on the material editor. Far, far better to jot smoothness in a blue channel, ao in a green, metalness in a blue and just use that.)

Keystone for combination is https://github.com/Azaezel/Torque3D/commit/f03e2f607708e6ca03c70f116b77e96052d48096#diff-8edf411c146d8096fa6b42fc601db65bR1062 so yeah, might have issues with a) different resolutions, and b) nonuniform channels, though I have thrown .png and .dds at it for what that's worth.

[Mud-H]

Thanks for the infos! I like your source codes links but I have no action to take, right? it's only to help me understand.

Btw, did something changed for the editor script in the 2-3 last months, I haven't updated my editor script in a while. Also is there a way to get the texture format from script side so I can detect those badly exported textures and remove them from material before it crash the engine(In Debug)?

[Azaezel]

By and large that last was 'here's the specifics of how it's made' (plus note the commit writeup) in case there was something obvious, but unless something stands out, I suppose not.

Will have to dig around for the texture format detection code. Could take a bit.

[Azaezel]

Synced to head, added http://forums.torque3d.org/viewtopic.php?f=40&p=4588#p4586

[Mud-H]

I found out yesterday that the TerrainMaterials detailStrength no longer work with the PBR branch. I'm not sure what is causing it exactly, PBR or D3D11 code, is there still a updated PBR branch without D3D11 so I can test it?

Or do you have any idea what can affect the detailStrength only? detailSize, macroStrength and all other fields work fine, it's just the detailStrength. I tought it was maybe caused by my custom editor but I tried with the stock editor and I have the same issue.

I'd like to find what's wrong but I have no idea about how the detailStrength is used... Could it be a local shader stuff? I made sure to have the same shaders and core than the full template.

[Azaezel]

Still preoccupied with the custommaterial bug reported http://forums.torque3d.org/viewtopic.php?f=40&t=533&start=10#p4643 (real headscratcher where it's breaking, given that lights themselves use a customMaterial).

For what it's worth, I can say the terrain issues are likely going to be found in https://github.com/Azaezel/Torque3D/commits/PBR/Engine/source/terrain/hlsl/terrFeatureHLSL.cpp , and macroXXX started out in life as a clone of detailXXX, so a comparative analysis of that might shed some light.

[luchete80]

Hi guys, thanks for this amazing feature!!

Question: how is the GBuffer packed? (yea i know, i can see all code, but i'm new in t3d and i need to understand it first :) )

Here i've been reading some interesting options for slim buffer. Whereas cryengine works with specular PBR approach AFAIK, frostbite and disney works with specular one.

Disney Format

Frostbite Format

CryEngine from Ryse version

[Azaezel]

time of writing:

[RT0]: normal.x, normal.y, depth, depth

directly accessible https://github.com/Azaezel/Torque3D/blob/PBR/Templates/Full/game/core/scripts/client/lighting/advanced/deferredShading.cs#L67

[RT1] albedo.rgb, a -reserved for terrain blend

directly accessible via https://github.com/Azaezel/Torque3D/blob/PBR/Templates/Full/game/core/scripts/client/lighting/advanced/deferredShading.cs#L63

[RT2] configbools, smoothness, ao, metalness

directly accessible via https://github.com/Azaezel/Torque3D/blob/PBR/Templates/Full/game/core/scripts/client/lighting/advanced/deferredShading.cs#L65

[RT3] (environment map*lightmap).rgb, a unused.

directly accessible via https://github.com/Azaezel/Torque3D/blob/PBR/Templates/Full/game/core/scripts/client/lighting/advanced/deferredShading.cs#L66

off to the side https://github.com/Azaezel/Torque3D/blob/PBR/Templates/Full/game/core/scripts/client/lighting/advanced/deferredShading.cs#L64 for the shadowmap/specular highlight results from lights.

if you want to look over the engine side, you can trace

https://github.com/Azaezel/Torque3D/blob/PBR/Engine/source/renderInstance/renderDeferredMgr.cpp#L57-L59

[luchete80]

I mean: "frostbite and disney works with METALNESS one"

[Azaezel]

metalness is universal. The divide is typically specular color or roughness/smoothness (same thing, just which ends of the spectrum 0.0 and 1.0 represent). we went smoothness to save 2 buffer slots.

[luchete80]

Man, you are great!!

I'll look at all that!

[luchete80]

yeah, that's right. But besides that, I was referring to (see below), once being in PBR, the assumption of insulators with specular F0=4%. I think you've addopted the best choice in this matter.

Now, most important than that, i've to understand all this :).

I quote:

http://www.marmoset.co/toolbag/learn/pbr-conversion

" [...] The biggest difference between the two workflows is how the diffuse and reflectivity content is defined in the texture maps. In the specular workflow, these values are set explicitly with two unique texture maps.

The metalness workflow on the other hand, uses the albedo map to define both the diffuse and reflectivity content and the metalness map to define whether the material is an insulator or a metal. "

[andrewmac]

metalness is universal. The divide is typically specular color or roughness/smoothness (same thing, just which ends of the spectrum 0.0 and 1.0 represent). we went smoothness to save 2 buffer slots.

 

Incorrect. You can't substitute specular color for roughness as roughness modifies the clarity of the reflection. Specular color can make an appearance in this workflow, but its used to modify the radiance (reflection). To save space many engines (Torque 6, UE4) substitute albedo modified by metalness as the specular color. Its a hack but its works for a large majority of materials and saves GBuffer space.