PBR: Principles, Practice, and Prepwork

And how did you manage to add nodes toolbar in substance designer? SD v5 feature? v5 upgrade from v4 cost 75$ :cry: Not sure if it worth the cost...

http://i.imgur.com/PmLaUdy.jpg Blowup of that with the types to look for. Started with 4 during thier upgrade offer, so should work for either.

Do note that depending on output format, you may need to swap the roughness and metalness output chans.

I'm not sure if I understand what you mean... I asked about how you add those special nodes icons on top of the node graph view (The little colored boxes), I don't have that and can't find how to add those, should be a v5 feature.

Edit: Confirmed to be a v5 feature, I got the trial and I have the icons. I will have 30 days to decide if it worth the upgrade cost :)

Oh. um... dunno. Been sticking purely to known-quantities this end.

Edit: looks like http://i.imgur.com/knPw4Cc.jpg toggles it.

Edit: because edit.

Ok thanks for your help, my system is shaping up. I have create some composite map with Substance Designer so it's more simple to test changes :) I tried to play with EnvVolume and LevelInfo Cubemap, I noticed that the cubemap change doesn't get applied live. When I change LevelInfo cubemap, I won't see changes until I add and delete a envVolume object. Is that an issue with my editor or stock editor does the same? Any workaround?

And how the MipTest cubemap should be used? I notice some yellow where metal should be and my composite map seem to leak on the texture (or it's the MipTest image...)

http://mud-h.com/miscweb/t3dforum/PBR/envvolumeA.jpg

If you look on the ground, there's some yellow/green color appearing. It's a normal behaviour with the MipTest?

http://imgur.com/a/7c5ot 3's about midrange blurriness of reflection. 5's trending towards the blurriest end. (max 8. source that does that bit https://github.com/Azaezel/Torque3D/blob/PBR/Engine/source/shaderGen/HLSL/shaderFeatureHLSL.cpp#L1878)

Stock editor does the same for swapping static cubemaps on the fly, though it does check objects in motion to see if they're still in volumes, so a nudge and reversion will let you see alterations without a restart. No such workaround at present for adding or removing reflectordescs at present (that's where you can override levelinfo *and* envVolumes and go back to the stock (ish) method for generating cubemaps dynamically from the centerpoints of the objects themselves. An option propagated to other stuff, but very much WIP in that reguard. )

On reflection ( no pun intended) not sure I recall why that downward mip adjustment... put it back to 11+1, netting us:

http://i.imgur.com/bmIOEMw.jpg / http://i.imgur.com/reqNPkZ.jpg (sharper potential reflections). Also threw in the re-linearization, though I really thing it'll be a better long-term solution to track down why that's getting faded on out, and looks like I missed registering a namedfeature with flipRB on the hlsl side.

On reflection ( no pun intended) not sure I recall why that downward mip adjustment... put it back to 11+1, netting us:

I have lost you on that part... What should be put back to 11+1?

Anyway, thanks for all the informations. That's a lot of new stuff for me and it will take some time to catch up... Before today, Mip was the sound of Roadrunner for me...

I still haven't notice a change when playing with the Accumulation properties... I will try the smoothness to see if it work fine in my editor. The Smoothness range for the slider should be set to 0 to 8? What about the metalness? Currently they are both at 0 to 1, maybe it's why they seem to do nothing.

It's a percentile in both cases. So nah, 0-1.0.

To clarify the mip bit: https://github.com/Azaezel/Torque3D/commit/532956a83ddfecae5a81399d5413296539ff31bd#diff-e8fb16d4fbe7e782211d7a2cbb0bcce0L1879 Basically, to save clockticks on light-diffusion/scattering/bluring effects, you do up a cubemap, and have it blend between the two closest mip-levels to the roughness percentage of the overall mip range for that cube. The point of the debug one is to give a nice contrasty quick look at what should show as mirror vs blured a bit vs so blurred out you're pretty much just getting a reflected smear of general color vs using say... http://i.imgur.com/7nA6C0k.png or http://i.imgur.com/1IxXjzW.png to tell what's going on.

On the accumulation end. haven't really poked at that since the initial conversion. Probably something we'll need to retool.

Some of the char/weapon textures I ran through Bitmap2Material.

The fp and tp character atlases and the ryder.

Only one color key with a range each for rough and metallic in B2M so these

aren't perfect. Just placeholder / testing stuff.

Edit

The dds atlases were saved from photoshop with mips since B2M wasn't behaving for me when

saving dds.

https://www.dropbox.com/s/db1tjwnbzf3wamz/PBRcharacter.zip?dl=0

Yeah, as noted upthread, substance designer doesn't like generating dds files with mips either. Can really mess with the engine at present, so as a crosscheck, re-converted the pngs to dds's.

Quick observations before I dart out the door for my day-off:

sbsprs looks like it may be a b2m or painter file format. Designer can't make heads or tales of it.

Ryder metalic seems to have gone full-white, so the grips reflective too. Seems a similar effect occured with the player in spots: http://i.imgur.com/mefj6Xy.jpg (Note the upper vs lower arm in particular.) We'll likely need a few more samples to tell if that's b2m side, or engine side (leaning towards the former given inspection in paint.net, but can't rule out possibly makin it worse.)

Can't say I'm familiar with a config that would end with normals greyscale, so left those stock.

Renames, material definitions, and re-conversions for doublechecking can be found in a bundle: https://onedrive.live.com/redir?resid=5FBC82584B785711!1676&authkey=!AJaXgIir1nROil0&ithint=file%2czip

sbsprs looks like it may be a b2m or painter file format. Designer can't make heads or tales of it.

B2M

B2M gives you the color keys and you can get it close using those. The shiny spot on the arm is an example of not close. :)

Just running the existing art through B2M isn't going to yield anything satisfying or useful for most of the existing atlases.

https://www.dropbox.com/s/ovx5fk88eajhq0n/roughmetalB2MSliders.png?dl=0

Substance Painter

Picked up Substance Painter and pulled in a Torque player model I had. You can paint color, height, rough, metal etc. directly on the model or the UV shell.

You can just export those textures, you can use your existing maps, you can bake a high rez normal map... It's nice. You can do it all from here.

Nice with existing substances though since you have all those convenient sliders :) Still bunches of work.

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

If we have a real artist in the house this is what I'd recommend when we get around to authoring new Torque assets.

I'll try to make something useful for debugging once I get used to Painter.

Cheers

Just throwing this over verbatim so I don't *completely* forget to jot it down:

[9/9/2015 2:21:12 PM] JeffR: not related to anything, but I was thinking about using some cubemaps for my game, and was trying to see if there's a way to save out cubemaps from inside torque, so I could set up a level, bake the cubemap and then use it on dynamic shapes and stuff

[9/9/2015 2:21:20 PM] JeffR: could've sworn there was a way to do that, but i'm not finding it

[9/9/2015 2:21:59 PM] JeffR: suppose at worst, I could just hijack the screenshot system

[9/9/2015 2:22:47 PM] az: welcome to the next step for that envVolumes thing I keep trying to frigging get to

[9/9/2015 2:22:50 PM] JeffR: ah

[9/9/2015 2:24:00 PM] JeffR: at my glancing of the code, it 'should' be possible to set up a cube reflector, then fetch the cubemap's textures, right? though I hadn't seen any way to really directly access them. getCubemap returns a handle, but i'm not sure if you can covert that to a gbitmap

[9/9/2015 2:25:51 PM] az: https://github.com/GarageGames/Torque3D/pull/721/files you may be thinking of that, which never worked

[9/9/2015 2:26:15 PM] JeffR: ah, dang, yeah I think I am

[9/9/2015 2:27:56 PM] az: also: https://github.com/GarageGames/Torque3D/blob/6b9e5dd15e67b152500a3ed0e3e58c695d2c959d/Engine/source/scene/reflector.cpp#L430

[9/9/2015 2:28:27 PM] JeffR: i spotted that and resolveTo, which writes to a texture object

[9/9/2015 2:29:03 PM] az: least that's where I was thinkin it'd make the most sense to hook in. say checkbox that says freeze on it, outputs the result to a gbitmap, gens the material.cs file, ect.

[9/9/2015 2:30:15 PM] az: meaning get that reflectcube with the player filterfix, adjust till it looks rightish, hit freeze, done.

[9/9/2015 2:30:42 PM] JeffR: hm, so when we call resolve, it writes the rendertarget to the attached texture

[9/9/2015 2:30:46 PM] JeffR: which would be our cubemap, right?

[9/9/2015 2:30:50 PM] JeffR: if i'm reading this correctly

[9/9/2015 2:31:01 PM] az: yep. well, one of the faces.

[9/9/2015 2:31:04 PM] JeffR: right

[9/9/2015 2:31:12 PM] JeffR: you'd loop through to hit them all

[9/9/2015 2:31:36 PM] az: yep. https://github.com/GarageGames/Torque3D/blob/6b9e5dd15e67b152500a3ed0e3e58c695d2c959d/Engine/source/scene/reflector.cpp#L338

[9/9/2015 2:31:54 PM] JeffR: ya, i'd just found that, lol

[9/9/2015 2:32:02 PM] JeffR: so it does that, runs resolve

[9/9/2015 2:32:08 PM] JeffR: then we'd have to grab the texture after that

[9/9/2015 2:33:18 PM] az: yeppers

[9/9/2015 2:34:13 PM] az: prolly run the objectID through the same method that mounting does for it's key (and same with that trigger->objectID thing I suggested the other day)

*note: all of that is C++ side, and could be applied to either envVolumes, or that pseudo-light experiment upthread.

Hi Azaezel

I encounter few problems today after making 2 builds from your pbr branch:

Building with SDL is crashing the engine and without the SDL the camera sometime is spinning randomly when i move the mouse.

I use VS 2012 community edition.

Hi Azaezel

I encounter few problems today after making 2 builds from your pbr branch:

Building with SDL is crashing the engine and without the SDL the camera sometime is spinning randomly when i move the mouse.

I use VS 2012 community edition.

Straight check out and recompile with vs 2013 community, 32 bit, sdl, and directx/opengl for release and debug aren't allowing me to replicate a crash. got any more data your end, say a console log, or a stack trace? (I'll also note sdl is the same between PBR and the development branch, so if that's the end acting up, I'd appreciate it if you could try the latest main development as well.)

I reinstall VS 2012 community edition and now everything works fine for the pbr and development branch. I have no idea why that happened so i apologize for wasting your time.

I still haven't notice a change when playing with the Accumulation properties...

Followup to this one: http://forums.torque3d.org/viewtopic.php?f=12&p=3108#p3108 Stock flaw, though there is still a bit of overly bright discoloration due to the not-quite-completed conversion there: http://i.imgur.com/H2xzpzp.png

I'm back into playing with PBR and I'm not sure how I should deal with the texture maps. Is it normal that the Smoothness and Metalness slider only change something when either the metal map or smoothness map is empty? So if you use a composite PBR map, those sliders are useless?

I tought it was a bad scripting in my TorqueLab editor but it does the same in the FullTemplate with latest PBR code.

Yes. Same as it would be pointless to have pixspecular and those sliders on if you were feeding it a spec map in head.

OK good to know as I'm a noob about rendering vocabulary...

So those sliders are for giving a metal-ish looks to textures without having to create PBR materials? You can get the same effects by playing with the composition maps but with better precision with the RGB channels? (I'm having trouble to explain what I mean here :oops: ) Do those sliders are linked to a texture or they are simply acting like a plain GreyScale bitmap?

Do you have any other example of T3D PBR materials to share other than those included in template (art/shapes/textures)?

Yeah, it's an either-or switch. Either use the % stored in the R and B channels per-pixel, or look em up for the whole material.

Haven't really gotten around to genning more non-personal-game ones as of yet, unfortunately, no.

I'm having an issue with my terrain texture blending, I don't know exactly when it have appeared but I have test on a fresh code base and it appear right after I add the PBR branch to my code. I think it might be from the latest changes in PBR branch or T3D Development branch. (But T3D development without the PBR code added blend the terrain textures fine...)

Here's a screenshot of what's happening:

http://mud-h.com/miscweb/t3dforum/Misc/terrainblendingissue.jpg

You have any idea what's causing it and if it's related to the PBR code? Maybe I forgot a needed script change...

Edit: I only need to add the PBR branch, right? What are the PBR_LightProbeLights , PBR_LPV and pbr_lpv_wteness_bbq branches?

Edit2: Ok, It seem to not be related to the PBR code directly, I have compiled the PBR branch alone and blending is working fine. I need to figure where I messed up...

Edit3: I wrote to fast, the issue is there when I load an example terrain from http://www.torqueterrains.com/ .So should be related to something in the material or mission file.

Edit4: I think I have track down where the blending issue come from: https://github.com/Azaezel/Torque3D/commit/66470605a70d245356c7c04d8e7ab68f7e0a20e7

The commit just before that have terrain blending working fine, but from this commit and after, it's not. I have been playing a lot with terrain materials on the Stock PBR template and it's hard to understand what's wrong... Seem like it's related to the order of the materials in some way...

Edit5: I have found what is causing the issue in that commit, I have rollback the following change and it works fine now :) I really don't know what it does, I guess you'll have a better understanding of the reason I had terrain blending problem... Do it happen for everyone or just few?

-   Var *color = NULL;
-   if (fd.features[MFT_isDeferred])
-       color = (Var*) LangElement::find( getOutputTargetVarName(ShaderFeature::RenderTarget1) );
-   else
-       color = (Var*) LangElement::find( getOutputTargetVarName(ShaderFeature::DefaultTarget) );
+   Var *color = (Var*) LangElement::find( getOutputTargetVarName(ShaderFeature::DefaultTarget) );

translation:

If we've added the deferred flag-feature (we're using what was the prepass class)
output color to the second (color) buffer for recombination later
else
output color to the standard buffer

put that back to stock for a bit to see if that'd mitigate the normal-with-hieghtmap-data blending problem mentioned upthread. will have to cook up a better solution, clearly.

Thanks for the translation but it doesn't make me understand much more. The rendering stuff and language is in my "Things to learn someday" list... I don't even know what Deferred rendering mean... (And don't bother to explain, I will get to it one day).

Keep up your good work, it's really appreciated when you don't understand rendering process :roll: (Normal with heightmap data would be a nice addition to T3D :) )

(Normal with heightmap data would be a nice addition to T3D :) )

It's there stock. Parallax slider + alpha of the normalmap. If it wasn't, I wouldn't be so concerned with trying to circle back and fix it, since folks wouldn't miss what they don't have nearly as much.

That being said, to cut down on things to wade through specifically related to PBR (and to fullfill at least par of the whole 'and prepwork' portion of the thread tag), http://forums.torque3d.org/viewtopic.php?f=9&t=387 will be one of the first subsystem extracts tossed over as soon as The Last Bug Dies.

Kinda stalled out on the query thing, so took a breather and started comparing deferred to the upcomming dx11 work.

One of the nastier conflict-points was the linearization step, so rewrote that for clarity. Now defines a toLinear and toGamma method that runs after texture loading for diffuses/albedos, instead of taking it's place in shadergen (and water).

Also cooked up a substance converter for the solider (still wip, but should give folks ideas), and cleaned up that fouled stone material. (Also rolled in the two submitted forks from the above thread)