got cubemap blurring to work! now i need to make a cubemap that doesn't have mipmap seams (because these are horrible). once i've done that i can look into the environment BRDF that they're using in UE4.
but as of right now, this is a good working proof of concept, that people can at least use to practice the new workflow.
i can probably use it to make a bunch of material presets that people can blend together at some point too.
if you don't want those seams you have to use dx11 (if you used that trick from that thread).
and if you didn't, care to elaborate how you did it, always curious how people solve this in Udk.
Or is it just a lerp between a a high res and a blurred one?
yeah i did that, but i'm using one of the cubemaps that came with UDK. i'm going to generate my own cube now anyway.
also, i read about DX11... i'll try that before generating a cube. i'd prefer people of older GPU's to be able to use this where possible though (might just have to list it as a limitation though).
Almighty, what is the specular term you're using? GGX?
Also, about the Cubes. Yeah, do what Marks says. UDK's current cube blurring system is pretty terrible. Vailias even created a DX9 version of manually blurring the cubemaps (even real-time ones in UDK) but they all end up with less then stellar seams.
The next best solution would be for you to set up a process volume for your cube actor in UDK and blur it from there, although I'm not sure if that has stayed the same or change for UDK in the past updates.
Something I am curious about:
When reading some articles it's clear that putting AO in your diffuse/spec is a no-go in PBR (but it can be added later on for ao for small details that engines can't do).
And kodde's shader has a input for that.
But is that something that gets done in the "upcoming" engines (cryengine 3.5/ue4/TB2/etc).
I never seen it mentioned in relation to UE4, So what is happening with that in general + it leads me to wondering how certain "tricks" we use today such as not actually putting in a hole, but faking it in the normal map + black in the ao.
The way I went about it is still bake some AO to some degree, but to a lesser extend, except for the low poly AO wich was still kinda important (less than usual as it was more like a mid res than a low res). This was in our own custom implementation of PBL inside UE4.
If a hole was to be faked, then so be it. It's a hole. It doesn't have any specular nor is reflecting anything, thus can be faked.
Nowaday in movies, guess what? Sometimes I still fake holes when the model doesn't have any carved in for some reasons. Doesn't matter. As long as the render is good...It's not a hole that will impact how bad / good your overall material is reacting to the physical lighting.
It takes a bit of practice but everyone's gonna adapt to that "new" stuff pretty fast. The most annoying thing to comprehend is metal. But then again that was with a custom shader inside a non realtime rendering engine. Once you figure this out, you're pretty much good to go for anything. Just do charts / screenshots with color swatches, and pick away how reflective / metalic you want parts to be and paint.
This is very easy. And that's when Mari comes as a HUGE time saver. Just pile on multiple grey values on layers and paint a mask / use masks from your diffuse to reveal those values to specific places (I often copy my diffuse channel and make mask from alpha, then add a procedural color with of grey value I want, then copy paste the mask into it and voila, done, next layer. it's a breeze really, sometimes I can convert my paint to B&W to overlay on top with low opacity to add a bit of variation). Bake / export the channel, and you're done.
Unfortunately we don't have a fancy shader to display our matertials in Mari, but after a bit you're so used to what range is what that you barely need to check (but a bi of color picking here and there is fast and a sure way to check, will be even easier with realtime engine as you don't have to render again to see the changes hehe).
Thing I found is usually Roughness is way more important than specular in most cases.
Sometimes I don't even paint specular TBH. I just enter a value, But then again, this depends on your engine. We found painting specular helps quite a lot avoiding to "weird" highlights at some odd angles, and altho it was physically accurate, we putted spec back in to have more control. But that's just us with our engine. I know some people doesn't even have specular anymore (they still use a metal tint of some kind for metals tho).
Can't wait to see publicly available engines with PBL to play with at home (Crytek I am looking at you, or marmost if you have a standalone version. The faster one comes the better).
Can't wait to see publicly available engines with PBL to play with at home (Crytek I am looking at you, or marmost if you have a standalone version. The faster one comes the better).
Aren't the shaders on CE3 pretty much physically based? At least they seem to be with their blurry reflections and all.
Aren't the shaders on CE3 pretty much physically based? At least they seem to be with their blurry reflections and all.
That's only part of a PBR renderer. What really makes something PBR is the way lighting is calculated. Marmoset also has the cubemap reflections with varying sharpness based on glossiness, but the current version isn't physically based either.
Ace-Angel - i'm using page 3 from here, which is the cook-torrence model brdf, using GGX specular distribution (trowbridge-reitz) and ggx geometric shadowing (schlick matched to smith).
this may be ready for a small beta test soon. of course even the final version will be free, even the unity version (if i finish it). but i could do with some people using it and giving feedback. particularly people already familiar with any next-gen pipeline.
Are there any good articles people could recommend to begin to wrap my head around understanding physical based lighting, and the complexities of shaders in general. I am not to knowledgeable about the math and programming behind shaders, but would like to have a better understanding of them.
Didn't see that one sentence in about seven paragraphs, but I was under the impression that a specific set of textures also plays a part in a Physically Based Renderer? A diffuse/albedo without light information, gloss/roughness, AO, normal, and a surface map? I thought image-based lighting was only part of a PBR, since it just simulated the amount of reflectivity and not necessarily the actual color or anything. I realize now (since I've been following this for awhile, before it was a new thread) that we already have the ao, normal and roughness, so my mistake.
I guess the confusion is also related to the lack of information(despite engines pushing forward with PBR) and whatever info I do find is different between engines. Most of the stuff is programming talk too.
Edit: But that makes me curious, what makes TB2 more physically based?
here's what i like about the whole thing with UE4:
BaseColor - Single color. Easier concept to understand.
Metallic - No need to understand dielectric and conductor reflectance, so less room for error.
Roughness - Very clear in its meaning, whereas gloss always needs explaining.
Cavity - Used for small-scale shadowing.
it's just such a simplified process over what we have now... you choose your base colour (or in the case of my version, create an albedo/base colour map). define whether it's metallic or not, define its roughness just with a simple map... there's no "tweak this gloss slider combined with your map until it looks right", you just use your map or a value if there is no map. and multiply a cavity map over the top of needed.
I'm on the hunt for calibrated PBR textures. Specifically ground/terrain and vegetation textures. I'm gonna have a look on CoD: Black Ops and see how they've made there textures, but it feels a bit stylized?
Really what I'm looking for is to know how much hacking there is to get grass to look like grass. Is there a set value and that it? Or is there a set value for snow.
I'm asking on the behalf of Avalanche, we want to know if it's "worth it".
If you don't want or can share it here I'm on valdemar[dot]nyhlen@avalanchestudios[dot]se
I'm on the hunt for calibrated PBR textures. Specifically ground/terrain and vegetation textures. I'm gonna have a look on CoD: Black Ops and see how they've made there textures, but it feels a bit stylized?
Really what I'm looking for is to know how much hacking there is to get grass to look like grass. Is there a set value and that it? Or is there a set value for snow.
I'm asking on the behalf of Avalanche, we want to know if it's "worth it".
If you don't want or can share it here I'm on valdemar[dot]nyhlen@avalanchestudios[dot]se
Can a PBL workflow work with the most current version of UDK by default, or is this only possible in UE4? I see you guys are using lots of custom materials and posting shots from Unreal, but I am not sure what version this is from, or if UE3/UDK are setup as a linear/PBL lighting system from the start.
For example, are these custom materials bending the rules a bit and making Unreal play in the PBL space, or are they fairly standard setups?
Thanks in advance, and apologies if this was already covered.
@toren3d ya ue3/udk cant do any of this out of the box, and even with shaders written for it, it isn't perfect since ibl and blurred reflections are still a little buggy.
Not trying to break this thread up, but I really wish I could sit down with an industry experienced artist and talk about him/her about this.
I mean hell, I'm not tech a artist. I'm not an idiot but damn! I can't seem to find an 'easy read' regarding PBR.
According to polycounts facebook post, all artists must have an understanding of PBR, I have to admit I'm struggling to learn anything past the main function of PBR. :poly117:
This topic is either very complicated to understand on even the fundamental level, or no one here understands it well enough to explain it in simple terms.
This article is probably the most simple one to read. It gives you the same information as most other articles, but it restates a lot of things in simpler terms and gives examples; PICTURES instead of numbers.
The article is an easier read than most, and even has a few videos to watch to better understand the applications of this new process, and what the results are.
No need to make it harder for yourself then it should be, there is no reason to deeply understand all this math and such behind it.
Just start with understanding the important part, understanding the four textures used (diffuse/spec/gloss/normal), and how they differ from today's textures, and how they should be created.
It's really not all that different from texturing for marmoset/skyshop/ce3 in what the maps do, there are just more guidelines to follow. http://seblagarde.wordpress.com/2011/08/17/feeding-a-physical-based-lighting-mode/
And imo (but this comes from someone with basicly no experience with it, just doing a lot of reading), it won't suddenly make everything look absolutely amazing, it's more about making content easier to produce, more standardization and such.
Didn't see that one sentence in about seven paragraphs, but I was under the impression that a specific set of textures also plays a part in a Physically Based Renderer? A diffuse/albedo without light information, gloss/roughness, AO, normal, and a surface map? I thought image-based lighting was only part of a PBR, since it just simulated the amount of reflectivity and not necessarily the actual color or anything. I realize now (since I've been following this for awhile, before it was a new thread) that we already have the ao, normal and roughness, so my mistake.
I guess the confusion is also related to the lack of information(despite engines pushing forward with PBR) and whatever info I do find is different between engines. Most of the stuff is programming talk too.
Yeah a big problem is just lack of proper documentation. We (marmoset) don't have any materials specifically related to PBR or anything like that.
A diffuse / albedo / color map are really the same thing, how much (if any) lighting you have prebaked into this texture is really an art content issue more so than something specific to the shaders in an app like Toolbag or any games engine. I haven't really used directional light in my diffuse textures in years personally. Toolbag's shaders look much better if you do not bake any lighting (other than AO), otherwise you get that "painted on abs" look.
AO in a separate texture is something that TB1 does not support but TB2 will likely support (as you can do some more advanced stuff with it like mask it where an object receives direct light). There's an AO slot in TB1 but its for a 2nd uv channel thing that barely works.
A substance/surface/specular/reflectivity map, again all just different names for the same thing. Its a map to set the base reflectivity of the material (some shaders do away with it entirely in favor of gloss map and probably a global reflectivity value). What this texture looks like is again an art content question, if you're creating it logically where more reflective areas on the texture are brighter, that's going to work in TB1, and TB2, and any PBR system that has a base reflectivity map.
Roughness is just another word for a gloss map, and if black = rough or if black = glossy is just an implementation thing. The big deal with gloss maps and PBR is that rougher areas sample blurrier/dimmer areas of your IBL cube maps (and your dynamic light intensity fades with glossier reflections) because of energy conservation, which is how TB1 works as well.
I hope that helps clear it up a little.
Edit: But that makes me curious, what makes TB2 more physically based?
Sorry, TB2 is still work in progress so I can't really tell you exactly what is different (as it may change before release). But basically some of the rendering stuff is more sophisticated / based on more accurate shading models etc.
One thing I can say is that TB2 has screen-space reflections, which rules and means that instead of putting AO into your spec map to mask strange reflections in occluded areas, you get the proper content reflected in those bits, and it looks really good.
Hi, I just fell on the thread's link on facebook. I am a lighting artist and I have been working on Remember Me with Sebastien Lagarde. We just did a session at gdc europe talking about how we used PBR to match the concept art.
We just uploaded this video that shows the different textures (and 2 debug view modes to spot out of range values). Note that the green/black spheres are actually translucent spheres so they don't have any albedo/smoothness/spec... textures https://www.youtube.com/watch?v=rwz1AL6pIXg
as a vray veteran and not a game artist heres the 'gist' of pbr and the new system and some possibilities that come from it.
ALbedo: its a diffuse map, it has no material information, no shadows, no highlights, just flat color. in sebastian legarde's paper he mentions his system has a exact color match from the viewport to photoshop if the light hitting the material is pure white.
normal maps: same thing as we use now.
roughness map: a slider that goes from a matte finish to a mirror finish
spec: not really spec, but how 'large' the specular highlight is, also possibly what color you want it. that last bit depends on the system.
--the following is regarding a specific implementation that is mentioned here---
ambient diffuse: basically a pre-baked GI cubemap that gets used to show light bouncing around on the object. pretty neat if you ask me.
ambient specular: the cubemap that reflects the environment, generated at runtime for best results. super low res at 256^2 res.
Hi, I just fell on the thread's link on facebook. I am a lighting artist and I have been working on Remember Me with Sebastien Lagarde. We just did a session at gdc europe talking about how we used PBR to match the concept art.
We just uploaded this video that shows the different textures (and 2 debug view modes to spot out of range values). Note that the green/black spheres are actually translucent spheres so they don't have any albedo/smoothness/spec... textures https://www.youtube.com/watch?v=rwz1AL6pIXg
I've seen that video with the debug mode and it seems cool, but looking at it its a little confusing to me. How exactly do you know when values are off? If you could shed some more light on the process there that would be awesome.
I've seen that video with the debug mode and it seems cool, but looking at it its a little confusing to me. How exactly do you know when values are off? If you could shed some more light on the process there that would be awesome.
Are you talking about our debug modes called "check lab" and "check specular"?
The first one colors in red pixels with albedo values under srgb 0.2 (in a 0.0-1.0 range) and in blue values above srgb 0.95
The second colors in blue pixels with spec color between rgb 0.08 and 0.5 and I guess red is for under 0.02
Does that answer your question?
Speaking of spec debug mode I think they based it on that chart where they taken that non metals go into 0.02 - 0.08 range and metals go to 0.5 - 1.0 range. So probably all others values not included in there get painted as out of range.
Random question, is the specular map or the gloss/roughness map supposed to be more solid shades of black to white on the different materials in the texture, I think I've seen it both ways.
Random question, is the specular map or the gloss/roughness map supposed to be more solid shades of black to white on the different materials in the texture, I think I've seen it both ways.
From what I have seen, each material will have a relatively uniform roughness, but the final composited textures with the layered dirt and wear will look a lot more noisy.
From what I have seen, each material will have a relatively uniform roughness, but the final composited textures with the layered dirt and wear will look a lot more noisy.
So I have been reading up on this stuff, but I am still confused a little bit about the diffuse/albedo map. I understand why you don't bake any lighting into the map, and only use a little bit of the AO. I am confused about why the colors and values in the map are so important, and how they actually effect the rendering.
This is the image I am confused about.
So I have been reading up on this stuff, but I am still confused a little bit about the diffuse/albedo map. I understand why you don't bake any lighting into the map, and only use a little bit of the AO. I am confused about why the colors and values in the map are so important, and how they actually effect the rendering.
This is the image I am confused about.
How bright/dark the diffuse is, is the important part of that image, even dark charcoal isn't black, and even white snow isn't pure white. I'd love to see a bunch of these guides for all parts of a texture, diffuse/spec/gloss.
apart from BRDF's you need a really complex shader system that blends together different material properties (roughness). Like we do at RAD, known as composite layers.
apart from BRDF's you need a really complex shader system that blends together different material properties (roughness). Like we do at RAD, known as composite layers.
I don't think you "need" it, but I do agree it makes things a lot more straightforward and easier to work with. Working on every texture channel separately is such an abstract concept, and a big reason why so many (new) artists struggle with texturing.
I don't think you "need" it, but I do agree it makes things a lot more straightforward and easier to work with. Working on every texture channel separately is such an abstract concept, and a big reason why so many (new) artists struggle with texturing.
Agreed, it isn't "necessary" but imo it is a much, much nicer workflow.
Replies
now i need to figure out how to blur dem cubemaps.
http://www.polycount.com/forum/showthread.php?t=108188
It works pretty nicely, although there will be a lot of seams after a few mips. But overall it's probably the easiest way to blur cubemaps in UDK.
damn! when is the release date ?
you guys want any beta testers ? :poly142:
got cubemap blurring to work! now i need to make a cubemap that doesn't have mipmap seams (because these are horrible). once i've done that i can look into the environment BRDF that they're using in UE4.
but as of right now, this is a good working proof of concept, that people can at least use to practice the new workflow.
i can probably use it to make a bunch of material presets that people can blend together at some point too.
and if you didn't, care to elaborate how you did it, always curious how people solve this in Udk.
Or is it just a lerp between a a high res and a blurred one?
in the custom node change to
that seemed to have done the job for me
also, i read about DX11... i'll try that before generating a cube. i'd prefer people of older GPU's to be able to use this where possible though (might just have to list it as a limitation though).
Page 7 onwards of the Black Ops 2 talk is a good starting point:
http://blog.selfshadow.com/publications/s2013-shading-course/lazarov/s2013_pbs_black_ops_2_slides_v2.pdf
Almighty, what is the specular term you're using? GGX?
Also, about the Cubes. Yeah, do what Marks says. UDK's current cube blurring system is pretty terrible. Vailias even created a DX9 version of manually blurring the cubemaps (even real-time ones in UDK) but they all end up with less then stellar seams.
The next best solution would be for you to set up a process volume for your cube actor in UDK and blur it from there, although I'm not sure if that has stayed the same or change for UDK in the past updates.
The way I went about it is still bake some AO to some degree, but to a lesser extend, except for the low poly AO wich was still kinda important (less than usual as it was more like a mid res than a low res). This was in our own custom implementation of PBL inside UE4.
If a hole was to be faked, then so be it. It's a hole. It doesn't have any specular nor is reflecting anything, thus can be faked.
Nowaday in movies, guess what? Sometimes I still fake holes when the model doesn't have any carved in for some reasons. Doesn't matter. As long as the render is good...It's not a hole that will impact how bad / good your overall material is reacting to the physical lighting.
It takes a bit of practice but everyone's gonna adapt to that "new" stuff pretty fast. The most annoying thing to comprehend is metal. But then again that was with a custom shader inside a non realtime rendering engine. Once you figure this out, you're pretty much good to go for anything. Just do charts / screenshots with color swatches, and pick away how reflective / metalic you want parts to be and paint.
This is very easy. And that's when Mari comes as a HUGE time saver. Just pile on multiple grey values on layers and paint a mask / use masks from your diffuse to reveal those values to specific places (I often copy my diffuse channel and make mask from alpha, then add a procedural color with of grey value I want, then copy paste the mask into it and voila, done, next layer. it's a breeze really, sometimes I can convert my paint to B&W to overlay on top with low opacity to add a bit of variation). Bake / export the channel, and you're done.
Unfortunately we don't have a fancy shader to display our matertials in Mari, but after a bit you're so used to what range is what that you barely need to check (but a bi of color picking here and there is fast and a sure way to check, will be even easier with realtime engine as you don't have to render again to see the changes hehe).
Thing I found is usually Roughness is way more important than specular in most cases.
Sometimes I don't even paint specular TBH. I just enter a value, But then again, this depends on your engine. We found painting specular helps quite a lot avoiding to "weird" highlights at some odd angles, and altho it was physically accurate, we putted spec back in to have more control. But that's just us with our engine. I know some people doesn't even have specular anymore (they still use a metal tint of some kind for metals tho).
Can't wait to see publicly available engines with PBL to play with at home (Crytek I am looking at you, or marmost if you have a standalone version. The faster one comes the better).
Aren't the shaders on CE3 pretty much physically based? At least they seem to be with their blurry reflections and all.
That's only part of a PBR renderer. What really makes something PBR is the way lighting is calculated. Marmoset also has the cubemap reflections with varying sharpness based on glossiness, but the current version isn't physically based either.
I'm curious, what brought you to this conclusion?
http://www.polycount.com/forum/showpost.php?p=1902352&postcount=143 - if you missed that post
this may be ready for a small beta test soon. of course even the final version will be free, even the unity version (if i finish it). but i could do with some people using it and giving feedback. particularly people already familiar with any next-gen pipeline.
Didn't see that one sentence in about seven paragraphs, but I was under the impression that a specific set of textures also plays a part in a Physically Based Renderer? A diffuse/albedo without light information, gloss/roughness, AO, normal, and a surface map? I thought image-based lighting was only part of a PBR, since it just simulated the amount of reflectivity and not necessarily the actual color or anything. I realize now (since I've been following this for awhile, before it was a new thread) that we already have the ao, normal and roughness, so my mistake.
I guess the confusion is also related to the lack of information(despite engines pushing forward with PBR) and whatever info I do find is different between engines. Most of the stuff is programming talk too.
Edit: But that makes me curious, what makes TB2 more physically based?
it's just such a simplified process over what we have now... you choose your base colour (or in the case of my version, create an albedo/base colour map). define whether it's metallic or not, define its roughness just with a simple map... there's no "tweak this gloss slider combined with your map until it looks right", you just use your map or a value if there is no map. and multiply a cavity map over the top of needed.
Really what I'm looking for is to know how much hacking there is to get grass to look like grass. Is there a set value and that it? Or is there a set value for snow.
I'm asking on the behalf of Avalanche, we want to know if it's "worth it".
If you don't want or can share it here I'm on valdemar[dot]nyhlen@avalanchestudios[dot]se
http://seblagarde.wordpress.com/2011/08/17/feeding-a-physical-based-lighting-mode/
check out the X-rite passport Macbeth chart.
just released the shader i was working on.
For example, are these custom materials bending the rules a bit and making Unreal play in the PBL space, or are they fairly standard setups?
Thanks in advance, and apologies if this was already covered.
http://www.fxguide.com/featured/game-environments-partb/
http://www.fxguide.com/featured/game-environments-partb/
http://www.youtube.com/watch?feature=player_detailpage&v=_29M8F-sRsU#t=2291
[ame="
http://research.tri-ace.com/
http://seblagarde.wordpress.com/tag/physically-based-rendering/
http://www.crytek.com/cryengine/presentations/
http://graphics.pixar.com/library/PhysicallyBasedLighting/paper.pdf
I mean hell, I'm not tech a artist. I'm not an idiot but damn!
According to polycounts facebook post, all artists must have an understanding of PBR, I have to admit I'm struggling to learn anything past the main function of PBR. :poly117:
This article is probably the most simple one to read. It gives you the same information as most other articles, but it restates a lot of things in simpler terms and gives examples; PICTURES instead of numbers.
The article is an easier read than most, and even has a few videos to watch to better understand the applications of this new process, and what the results are.
http://www.fxguide.com/featured/game-environments-parta-remember-me-rendering/
A few things that stood out to me:
Calibrating for the Albedo (Diffuse)
Just start with understanding the important part, understanding the four textures used (diffuse/spec/gloss/normal), and how they differ from today's textures, and how they should be created.
It's really not all that different from texturing for marmoset/skyshop/ce3 in what the maps do, there are just more guidelines to follow.
http://seblagarde.wordpress.com/2011/08/17/feeding-a-physical-based-lighting-mode/
And imo (but this comes from someone with basicly no experience with it, just doing a lot of reading), it won't suddenly make everything look absolutely amazing, it's more about making content easier to produce, more standardization and such.
Wich brings up the next thing, you then should probably have a look at (but probably won't be able to play around with untill UE4 comes) is layered materials.
http://blog.selfshadow.com/publications/s2013-shading-course/rad/s2013_pbs_rad_slides.pdf
Yeah a big problem is just lack of proper documentation. We (marmoset) don't have any materials specifically related to PBR or anything like that.
A diffuse / albedo / color map are really the same thing, how much (if any) lighting you have prebaked into this texture is really an art content issue more so than something specific to the shaders in an app like Toolbag or any games engine. I haven't really used directional light in my diffuse textures in years personally. Toolbag's shaders look much better if you do not bake any lighting (other than AO), otherwise you get that "painted on abs" look.
AO in a separate texture is something that TB1 does not support but TB2 will likely support (as you can do some more advanced stuff with it like mask it where an object receives direct light). There's an AO slot in TB1 but its for a 2nd uv channel thing that barely works.
A substance/surface/specular/reflectivity map, again all just different names for the same thing. Its a map to set the base reflectivity of the material (some shaders do away with it entirely in favor of gloss map and probably a global reflectivity value). What this texture looks like is again an art content question, if you're creating it logically where more reflective areas on the texture are brighter, that's going to work in TB1, and TB2, and any PBR system that has a base reflectivity map.
Roughness is just another word for a gloss map, and if black = rough or if black = glossy is just an implementation thing. The big deal with gloss maps and PBR is that rougher areas sample blurrier/dimmer areas of your IBL cube maps (and your dynamic light intensity fades with glossier reflections) because of energy conservation, which is how TB1 works as well.
I hope that helps clear it up a little.
Sorry, TB2 is still work in progress so I can't really tell you exactly what is different (as it may change before release). But basically some of the rendering stuff is more sophisticated / based on more accurate shading models etc.
One thing I can say is that TB2 has screen-space reflections, which rules and means that instead of putting AO into your spec map to mask strange reflections in occluded areas, you get the proper content reflected in those bits, and it looks really good.
We just uploaded this video that shows the different textures (and 2 debug view modes to spot out of range values). Note that the green/black spheres are actually translucent spheres so they don't have any albedo/smoothness/spec... textures
https://www.youtube.com/watch?v=rwz1AL6pIXg
The slides are also available here but I think the PBR section is less detailed than the fx guide article.
http://seblagarde.wordpress.com/2013/08/22/gdceurope-2013-talk-the-art-and-rendering-of-remember-me/
ALbedo: its a diffuse map, it has no material information, no shadows, no highlights, just flat color. in sebastian legarde's paper he mentions his system has a exact color match from the viewport to photoshop if the light hitting the material is pure white.
normal maps: same thing as we use now.
roughness map: a slider that goes from a matte finish to a mirror finish
spec: not really spec, but how 'large' the specular highlight is, also possibly what color you want it. that last bit depends on the system.
--the following is regarding a specific implementation that is mentioned here---
ambient diffuse: basically a pre-baked GI cubemap that gets used to show light bouncing around on the object. pretty neat if you ask me.
ambient specular: the cubemap that reflects the environment, generated at runtime for best results. super low res at 256^2 res.
Great, glad to see you here!
I've seen that video with the debug mode and it seems cool, but looking at it its a little confusing to me. How exactly do you know when values are off? If you could shed some more light on the process there that would be awesome.
Are you talking about our debug modes called "check lab" and "check specular"?
The first one colors in red pixels with albedo values under srgb 0.2 (in a 0.0-1.0 range) and in blue values above srgb 0.95
The second colors in blue pixels with spec color between rgb 0.08 and 0.5 and I guess red is for under 0.02
Does that answer your question?
edit: beaten
Anything new coming to Substance for PBS?
This is the image I am confused about.
Some stuff beyond awesome is coming, stay tuned
:-D
How bright/dark the diffuse is, is the important part of that image, even dark charcoal isn't black, and even white snow isn't pure white. I'd love to see a bunch of these guides for all parts of a texture, diffuse/spec/gloss.
Something like this?
http://blog.selfshadow.com/publications/s2013-shading-course/rad/s2013_pbs_rad_slides.pdf
apart from BRDF's you need a really complex shader system that blends together different material properties (roughness). Like we do at RAD, known as composite layers.
I don't think you "need" it, but I do agree it makes things a lot more straightforward and easier to work with. Working on every texture channel separately is such an abstract concept, and a big reason why so many (new) artists struggle with texturing.
Agreed, it isn't "necessary" but imo it is a much, much nicer workflow.