### PBR: Principles, Practice, and Prepwork

Materials, textures, lighting, postfx

#### Re: PBR: Principles, Practice, and Prepwork

Azaezel
Posts: 393
Joined: Tue Feb 03, 2015 9:50 pm

Mud-H wrote:
Azaezel wrote:Converting from fan to strip requires a re-alignment of verticies...
Sample: https://github.com/Lopuska/Torque3D/com ... 60becR1042

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 ... .h#L62-L72
converts to:

https://en.wikipedia.org/wiki/Triangle_fan (deprecated)
https://msdn.microsoft.com/en-us/librar ... 73(v=vs.85).aspx (list)
https://msdn.microsoft.com/en-us/librar ... 74(v=vs.85).aspx

#### Re: PBR: Principles, Practice, and Prepwork

Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
EDIT: I was all wrong if you read previous post version
When running in DEBUG, I get an AssertFatal in gBitmap.cpp

Code: Select all

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...

Code: Select all

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.

Code: Select all

bool GBitmap::checkForTransparency(){   mHasTransparency = false;   ColorI pixel(255, 255, 255, 255);   switch (mInternalFormat)   {      // Non-transparent formats      case GFXFormatL8:      case GFXFormatR8G8B8:      case GFXFormatR5G6B5:

#### Re: PBR: Principles, Practice, and Prepwork

Azaezel
Posts: 393
Joined: Tue Feb 03, 2015 9:50 pm

Ok, so the relevant commit for composite textures'll be https://github.com/Azaezel/Torque3D/com ... 4bcda42fec

Specifically, https://github.com/Azaezel/Torque3D/blo ... #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/com ... db65bR1062 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.

#### Re: PBR: Principles, Practice, and Prepwork

Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
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)?

#### Re: PBR: Principles, Practice, and Prepwork

Azaezel
Posts: 393
Joined: Tue Feb 03, 2015 9:50 pm

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.

#### Re: PBR: Principles, Practice, and Prepwork

Azaezel
Posts: 393
Joined: Tue Feb 03, 2015 9:50 pm

#### Re: PBR: Principles, Practice, and Prepwork

Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
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.

#### Re: PBR: Principles, Practice, and Prepwork

Azaezel
Posts: 393
Joined: Tue Feb 03, 2015 9:50 pm

Still preoccupied with the custommaterial bug reported 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/com ... reHLSL.cpp , and macroXXX started out in life as a clone of detailXXX, so a comparative analysis of that might shed some light.

#### Re: PBR: Principles, Practice, and Prepwork

luchete80
Posts: 4
Joined: Thu Jul 28, 2016 11:39 am
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

#### Re: PBR: Principles, Practice, and Prepwork

Azaezel
Posts: 393
Joined: Tue Feb 03, 2015 9:50 pm

time of writing:
[RT0]: normal.x, normal.y, depth, depth
directly accessible https://github.com/Azaezel/Torque3D/blo ... ing.cs#L67
[RT1] albedo.rgb, a -reserved for terrain blend
directly accessible via https://github.com/Azaezel/Torque3D/blo ... ing.cs#L63
[RT2] configbools, smoothness, ao, metalness
directly accessible via https://github.com/Azaezel/Torque3D/blo ... ing.cs#L65
[RT3] (environment map*lightmap).rgb, a unused.
directly accessible via https://github.com/Azaezel/Torque3D/blo ... ing.cs#L66

off to the side https://github.com/Azaezel/Torque3D/blo ... ing.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/blo ... pp#L57-L59

#### Who is online

Users browsing this forum: No registered users and 1 guest