PBR: Principles, Practice, and Prepwork

Materials, textures, lighting, postfx
165 posts Page 16 of 17
Azaezel
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Tue Jan 12, 2016 9:01 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
Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
by Mud-H » Tue Jan 12, 2016 9:37 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:
     
Azaezel
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Wed Jan 13, 2016 12:01 am
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.
Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
by Mud-H » Wed Jan 13, 2016 1:19 am
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
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Wed Jan 13, 2016 1:49 am
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
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Wed Jan 20, 2016 1:04 am
Synced to head, added viewtopic.php?f=40&p=4588#p4586
Mud-H
Posts: 175
Joined: Thu Feb 19, 2015 3:08 pm
by Mud-H » Tue Feb 02, 2016 7:32 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.
Azaezel
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Wed Feb 03, 2016 2:36 am
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.
luchete80
Posts: 4
Joined: Thu Jul 28, 2016 11:39 am
by luchete80 » Thu Jul 28, 2016 6:06 pm
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
Image

Frostbite Format
Image

CryEngine from Ryse version
Image
Azaezel
Posts: 384
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Thu Jul 28, 2016 6:44 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
165 posts Page 16 of 17

Who is online

Users browsing this forum: No registered users and 2 guests