I'd definitely want to see a good database of PBR material values. Right now it's all over the place and very confusing for a simple artist. This stuff needs to be streamlined and I'll gladly pay for a subscription to a service that could provide all this information I need to make materials I want.
I understand the idea of unifying materials and archiving their values for consistent results and for sake of ease establishing a base, but can we really expect to remove all creative/artistic decision from the material creation process?
I think that's a nice dream to think of. The world where you just pick a material from a list of every possible thing and combine it all together to make whatever you can possibly need without any artistic decisions from your part, just observations and knowledge of materials. Sounds boring, but It can help the industry by making texture creating a lot faster and more accessible, which isn't a bad thing (for the industry)
I think that's a nice dream to think of. The world where you just pick a material from a list of every possible thing and combine it all together to make whatever you can possibly need without any artistic decisions from your part, just observations and knowledge of materials. Sounds boring, but It can help the industry by making texture creating a lot faster and more accessible, which isn't a bad thing (for the industry)
It was a semi rhetorical question. Short of having a computer simulate environmental effects on a material I'd say its impossible, or very unreasonable, to remove all artist decision from material creation. Not only in regards to how they brush damage, or mask things, but the values of materials themselves.
People keep using the word "Accuracy". Well, accurate to what? Lets say quixels values where dead on for a tarnished steel. Does that mean their reference and their data is accurate to my reference and what i'm attempting to recreate? I really don't know for sure, but my gut is saying no.
Like I said, maybe i'm wrong or misunderstanding the goal. its very possible as I'm not a master of materials.
you can find the albedo values for almost everything with a point and shoot camera(as long as it has a flash) and a cheap pair of passive 3d glasses.
put one lens horisontally across the flash, the other vertically over the camera lens, take your photo. it will strip out all of the specular highlights (for best results, do this in a dark room where there is little or no ambient light to interfere).
getting the reflectance values is a little more tricky, it involves taking the same photo from the exact same angle and position, but without the filters, converting the images to linear space, and then subtracting the highlight from the flat image. HOWEVER, a lot of that work is quite unneeded... keep your reflectance values low (or just use the metalness workflow) and you'll be surprised how many non-metals will work with this method.
I think that's a nice dream to think of. The world where you just pick a material from a list of every possible thing and combine it all together to make whatever you can possibly need without any artistic decisions from your part, just observations and knowledge of materials. Sounds boring, but It can help the industry by making texture creating a lot faster and more accessible, which isn't a bad thing (for the industry)
Models still need to be modeled, colors still need to be decided, and roughness maps still need to be made, and stuff like dirt and stuff still needs to be applied, so it's not like the creative process is all gone
This thread looked attracted a lot of attention while I was asleep haha.
@almighty_gir - that's pretty neat! I did not know that actually. If you have a reliable source I'd like to add that into a section. It's really cool to think you can do that so "simply".
@s6 - please note that I have changed the name to Encyclopaedia (the name may change a 3rd time) from Bible. It's just that the thread name does not update unfortunately
I don't know why everyone thinks you need a super strict database of values. You do need some good core values to start, but you don't need exact values for everything. As long as you are staying close to the core values you are fine. You need to work visually still. Authoring textures has not turned into a paint by numbers scenario. I mean what do you do when you have a metal that is made up. You are never going to find the exact values for that, but you can base it off of something real. Say I have a metal that is supposed to be like iron, but it's purple. I can take the reflectance value from iron hue and saturation shift until I have something that looks good. That is basically how you should be approaching things. Find something close tweak it until it looks good.
Suggesting a company, or group, could accurately create an archetype or ideal for what every material should be is equally as laughable.
All I'm suggesting, as Shrike originally suggested, is that people learn why materials behave the way they do instead of relying on a cookie cutter system to drag and drop materials onto their asset.
This isn't in response to a PBR encyclopedia, which I think is a great idea/utility, but more in response to those who are looking for a silver bullet look up for materials.
I don't know why everyone thinks you need a super strict database of values. You do need some good core values to start, but you don't need exact values for everything. As long as you are staying close to the core values you are fine. You need to work visually still. Authoring textures has not turned into a paint by numbers scenario. I mean what do you do when you have a metal that is made up. You are never going to find the exact values for that, but you can base it off of something real. Say I have a metal that is supposed to be like iron, but it's purple. I can take the reflectance value from iron hue and saturation shift until I have something that looks good. That is basically how you should be approaching things. Find something close tweak it until it looks good.
Maybe I'm missing the point or misunderstanding the goal of a "bible" but I know one thing: I'm not going to blindly create my art based on pre established archetypes that may more may not apply to what i'm attempting to recreate.
Its like 3py0n said; "guessing after guidelines"
Thats not a artistic choice, its just lack of information
Having better documentation will not suddenly take your artistic choice away, how did you imagine that ? : P
@all - yea my want...I guess should've been better worded. I was saying that it'd be great to have core values or base values and adjust accordingly. But I guess after texturing for so long some people just know what kind of value range they'd need.
Regardless I'll be updating the doc more today. Only worked on it a bit yesterday.
you can find the albedo values for almost everything with a point and shoot camera(as long as it has a flash) and a cheap pair of passive 3d glasses.
put one lens horisontally across the flash, the other vertically over the camera lens, take your photo. it will strip out all of the specular highlights (for best results, do this in a dark room where there is little or no ambient light to interfere).
getting the reflectance values is a little more tricky, it involves taking the same photo from the exact same angle and position, but without the filters, converting the images to linear space, and then subtracting the highlight from the flat image. HOWEVER, a lot of that work is quite unneeded... keep your reflectance values low (or just use the metalness workflow) and you'll be surprised how many non-metals will work with this method.
Sooner or later most AAA studios will have the libraries and everyone working there will have to adjust anyways I guess, we either wait until a large one goes public or we create one ourselves, or we continue feeding a accurate system with inaccurate data in the hope its close enough to the accurate values
damn im getting too heated up, having too strong of a opinion again hah
@ shrike - It's impossible to be 100% accurate with your textures. Unless you are sampling every pixel of your texture and making sure it's 100% what it would be in real life you a never going to be perfectly accurate. Also the difference you are talking about is so subtle you won't even notice it. You don't need an extensive library. It just isn't that useful to have every .01 difference in reflectivity scanned and in a database. You still need to be an artist and interpret things. As I said there is no ability to scan materials that don't exist. You will always be approximating these thing and ya know what it doesn't make a difference.
Sooner or later most AAA studios will have the libraries and everyone working there will have to adjust anyways I guess, we either wait until a large one goes public or we create one ourselves, or we continue feeding a accurate system with inaccurate data in the hope its close enough to the accurate values
damn im getting too heated up, having too strong of a opinion again hah
Why do you think large libraries won't be disclosed? Because it takes time, expertise and money to create them. I know for a fact that if I disclose too much sensitive info that I've gained directly from the studio I work for, I'll be reprimanded by them. Why do you think all the other experienced PBR guys on here who work for big companies (like Xoliul for example, sorry to call you out Laurens) are being very careful what they say about it publically?
e/ disclosing the info is likely not because the people "in the know" don't want to give it to you. It's probably because they don't want to put their own job on the line. NDAs are serious business.
Yeah, unless studios are going to profit off the content/library itself, there is very little motivation to make it public. Theres also various issues with calibration and workflow/engine specific stuff as well (you might need different values than X studio uses).
A library built by various individuals is unfortunately prone to all sorts of issues as well, again calibration and whatnot.
Personally I have more faith in Megascans than anything else when it comes to the idea of a publicly available library that covers a wide ranger of material types.
I agree, my personal opinion is that megascans and some kind of conversion table for the "correct" values for Unreal4 will eventually become the de-facto standard go-to for most people's personal/portfolio work involving PBR. Quixel's Megascans service is one of the most interesting things that's being brought to the PBR table that I know of.
Yeah, the Quixel guys are working on that as far as I know (UE4 support), at least when used with DDO. Not sure how will it would integrate into other texturing workflows, but I have to imagine it wouldn't be that difficult to figure out if all the base scans are calibrated in the same way.
updated the doc some more. Added a change log to the OP.
Will be making a more indepth and detail-oriented table of contents soon. But at the moment this is the hierarchy.
Blue Headings
Orange Headings
Red Headings
Black Headings
Also want to do a shoutout to d1ver while I'm at it. He's developed a pretty nifty tool!! Though I'd be cautious for newcomers to the PBR realm and try to do a project on your own with little to no helping tools first to get the hang of this newer form of workflow. Just my 2 cents.
Metal and non-metal can both be done with a single PBR material can't they?
Only issue is metallic IOR map needs to be coloured (rgb) and not just a single perpendicular reflectivity value like non-metals (ie single channel or alpha or whatever)
So ideally can we do all nice PBR materials with this?
That seems pretty reasonable to me to cover everything, or did I miss anything?
If you need alpha for transparency can we just dump AO or cavity, or even just re-arrange if it's not got metals in there and free up some channels in the spec map too!
Ok so I work with Vray on a daily basis creating photo-realistic materials... and even then I'm getting stuck with PBR techniques. We don't have any definite values and we very rarely use "roughness". The majority of the time its more like guesswork/approximation; we use gloss, diffuse(no lighting info), bump and falloffs the majority of the time. Vray has nice control over how the material receives light and how's its cast i.e. focused/spread.
Anyone have a couple of minutes to clarify the main differences between this workflow and PBR for games?
Ok so I work with Vray on a daily basis creating photo-realistic materials... and even then I'm getting stuck with PBR techniques. We don't have any definite values and we very rarely use "roughness". The majority of the time its more like guesswork/approximation; we use gloss, diffuse(no lighting info), bump and falloffs the majority of the time. Vray has nice control over how the material receives light and how's its cast i.e. focused/spread.
Anyone have a couple of minutes to clarify the main differences between this workflow and PBR for games?
I'm not asking this to be an asshole, but have you read the document in the OP of this thread? or any of the documentation on PBR yet? There is a lot of info on the first page of this thread alone, plus the Marmoset tuts, the TB2 threads, etc.
Gloss, Roughness, and microsurface are more or less interchangeable terms. Albiedo(diffuse) should be familiar to you if you're used to no lighting info. The biggest thing you may have to get used to is how PBR handles reflectivity and microsurface. Albiedo and Reflectivity (specular) do less of the heavy lifting and microsurface does a bit more.
Metal and non-metal can both be done with a single PBR material can't they?
Only issue is metallic IOR map needs to be coloured (rgb) and not just a single perpendicular reflectivity value like non-metals (ie single channel or alpha or whatever)
So ideally can we do all nice PBR materials with this?
That seems pretty reasonable to me to cover everything, or did I miss anything?
If you need alpha for transparency can we just dump AO or cavity, or even just re-arrange if it's not got metals in there and free up some channels in the spec map too!
Thanks
Dave
If using the metalness workflow, you can pack metalness, gloss, and cavity into 1 24bit image.
Generally its best to avoid packing in alphas, as that will double your compressed texture memory for those textures, only exception is if you're running out of texture calls or something.
For instance, even if you need 5 single channel maps, lets say:
alpha
metalness
gloss
ao
cavity
It would be better to pack these into 2 24 bit images, and have an empty channel in one, than pack the two extra into the alpha channel of 2 32bit images, as that would give you the texture usage equivalent to one extra 24bit image of the same resolution.
If using the metalness workflow, you can pack metalness, gloss, and cavity into 1 24bit image.
Generally its best to avoid packing in alphas, as that will double your compressed texture memory for those textures, only exception is if you're running out of texture calls or something.
For instance, even if you need 5 single channel maps, lets say:
alpha
metalness
gloss
ao
cavity
It would be better to pack these into 2 24 bit images, and have an empty channel in one, than pack the two extra into the alpha channel of 2 32bit images, as that would give you the texture usage equivalent to one extra 24bit image of the same resolution.
Just to be clear you mean to say it's better to pack information into the RGB channels than it is to pack it into the the alpha channel because the alpha channel is the same a having a full 24 bit texture. I have a quick question then why does Marmoset only support alpha in the alpha channel of the albedo texture? Wouldn't it be better to input it into a separate map where you can cut down the expense?
Just to be clear you mean to say it's better to pack information into the RGB channels than it is to pack it into the the alpha channel because the alpha channel is the same a having a full 24 bit texture. I have a quick question then why does Marmoset only support alpha in the alpha channel of the albedo texture? Wouldn't it be better to input it into a separate map where you can cut down the expense?
Yes, that is what I am saying. With DXT compression, when you add an alpha channel you double the size in memory, so you can use another full color map, with up to 3 inputs instead. This isn't specific to PBR or anything, but rather general optimization.
As far as why Toolbag only supports alpha from diff.a, its a simple limitation due to the fact that that is where people commonly store a transparency mask. A couple people have requested loading transparency from a separate map and its a good idea that I would certainly like to see as well, we just haven't had time to implement it yet.
If using the metalness workflow, you can pack metalness, gloss, and cavity into 1 24bit image.
Generally its best to avoid packing in alphas, as that will double your compressed texture memory for those textures, only exception is if you're running out of texture calls or something.
For instance, even if you need 5 single channel maps, lets say:
alpha
metalness
gloss
ao
cavity
It would be better to pack these into 2 24 bit images, and have an empty channel in one, than pack the two extra into the alpha channel of 2 32bit images, as that would give you the texture usage equivalent to one extra 24bit image of the same resolution.
Hrmm...wasn't aware you could pack it so much. But does it depend on the engine/nature of the project you're working on that would warrant such a route? I don't see why one would (for standard portfolio purposes) pack so many maps into 1. (ex. the metalness workflow)
Hrmm...wasn't aware you could pack it so much. But does it depend on the engine/nature of the project you're working on that would warrant such a route? I don't see why one would (for standard portfolio purposes) pack so many maps into 1. (ex. the metalness workflow)
Right, exactly how you optimize or pack your content is going to be engine, or perhaps project and even asset specific, and again content packing isn't specific to PBR, this is more of a general concept.
However, the same could be said for the metalness workflow, its a very much pipeline specific technique and isn't mutually exclusive to PBR.
Its not something you necessarily need to worry about for your portfolio, but understanding how to pack content, or rather how much memory adding a bunch of extra maps and packing them inefficiently takes up in a real world scenario is important for every artist.
@EQ - Ahhh yea that's true. The project that comes to mind is Tor Frick's sci-fi hallway-of-sorts. Insane.
Oh yea for all, please refer to the original post for updates on the doc. I've been updating everyday but only recently made it known via a post that an update has occurred, just incase anyone thought that it wasn't being worked on, etc.
@3py0n I just wanted to let you know that I really appreciate what you are doing. Mad props to you and everyone else that has been contributing to this. +1 power levels to everyone.
So I don't have time to do a tutorial, but here is a little write up about my process:
So the very first thing I will do even before baking is I bring my High Poly into Marmoset and I prototype my materials. There are a couple of reasons for this. First it allows me to see what the final product might look like and determine if I am happy with the sculpt. Second it gives me a base to start my textures.
The basic process of prototyping my materials is I will look up something close to what I want for the reflectivity. So with the daggers I started with gold which I pulled the value from the Crytek PBR chart. I wanted something a bit less bright and a bit more orange. So I just shifted the values until I got something I was happy with. I used the same process for getting the reflectivity of the other materials.
For albedo I generally don't reference any charts. I just try to make sure it falls into more of a mid range. You don't want it to be too dark or too bright ( except for some special cases like snow). If you look at the don't nod Albedo values chart even coal only goes as low as 50 in RGB values.
I don't worry about gloss so much. I prototype out the values, but I don't really follow them that much as I have to convert them from linear to srgb. I just use it as more of a visual target than actually grabbing the value.
That's it! I just pull those values directly from marmoset and put them into may textures. I do tweak them from there, but it's really good for getting started and getting a feel for what you want your model to look like.
Most of this is really about referencing what you have values for and tweaking it to where you want. You just need to make sure you are with in range and it will look good.
If anyone has any questions let me know.
Hope this helps you all out.
Here is a screenshot comparing my prototype and my final model:
Thanks for that stevston89! Directions are fairly clear and informative. I've been reading up and found that a number of people figure out their materials prior to baking as well.
I think for me, it's more of just getting used to translating between linear and sRGB...which will be a little tricky for me as I've not done it before and even having the knowledge from doing the PBR doc, without practice I don't feel comfortable yet
@ 3pyon - On the subject of linear to srgb the only place you have to worry is with gloss and personally I just polish based on looks. Since there is no standardized value for gloss like the is for reflectance I wouldn't really worry too much. Any surface can be rough or glossy ( except some materials like water) so it really is about making it look right in engine and less about making sure you have accurately measured values.
Oh yeah and the reason you don't have to worry about the linear conversion for albedo and reflectance is because the values given to you on most PBR charts are already converted to srgb and most engines convert that back to linear for you. So you can just work in srgb.
I don't know if photoshop has that option. I just make my gloss textures normally and polish them to look right. This might be completely wrong, but I don't know of a way to work in linear space.
You don't need to worry about it in photoshop at all. Photoshop will give you a preview of the map in SRGB/gamma space, but what the map looks like in PS doesn't matter.
What matters is how it looks in your game engine/renderer, and thats where you will check when authoring content.
Only other thing to really keep in mind is if say, you preview your textures in Marmoset Toolbag (linear for gloss by default) and then load into Unreal or another engine, just make sure to set the texture to linear there as well.
are linear values controled by the levels adjustment layer in photoshop?
when working in pbr should i care for the linear/gamma values or just work on the textures like i did in the legacy workflow? (Does that question make any sense?)
I have read through most of the info out there on pbr but the linear/gamma confuses alot.
Do I adjust the linear value in photoshop or MT2, UE4 etc?
I'm asking this because when I see values on toolbags website that are 0.04 or so i get confused.
From my interstanding, you just texture as you normally would. But when you preview your texture or when you are texturing, be sure to check it out in the final engine you are using. So for example, if it was for a portfolio piece, be sure to check out your texture work in the engine you plan to present it in, and not in max...unless you plan to present it in max.
What it looks like in the engine is the most important bit. If you're previewing in say, Marmoset Toolbag, but the final engine is Unreal 4, you want to make sure that for all of your textures, you're using the same color space.
In TB2, you can click on the per-texture options button and enable or disable sRGB. sRGB on means gamma corrected, sRGB off means linear space. In UE4, there is also an sRGB check in the texture properties I believe.
Normal maps are the only map that really HAS to be linear space, normal maps don't work at all when loaded as sRGB. This is true if you have pbr shaders or not. In UE4 and TB2 normal maps will load with sRGB off by default.
Gloss/roughness maps and metalness maps tend to be linear space as well, but they don't necessarily have to be. From a practical persective, any input that defines a percentage value (like gloss and metalness), makes sense to use linear color space for the texture input. This is so you can easily mock up a material will a parametric input in your shader (which tends to be linear space), and then easily duplicate that value in photoshop by selecting the color with the brightness input in the color picker. The values for these maps will not be accurately visualized in photoshop though (which works in gamma space by default), so its important to verify the results in the actual shader/game/renderer and not worry about what it looks like in 2d.
Albedo and specular color maps tend to be sRGB, but again they can be linear space too. Generally its more helpful to have an accurate visualization for these types of maps (and full RGB parametric inputs can be in gamma space as well, as is the case in TB2), which is why these maps are often sRGB. Though again, you can use the same workflow as above and work in linear space, with the understanding that the visual representation will not be accurate and you need to check the results in game, which is important no matter the workflow.
Generally its important for this to be consistent throughout your project, which maps are in linear or gamma space. Its not something that should vary per asset, so talk to your technical artist, engineers, etc if you're confused about which to use.
Again, you don't need to set photoshop up in a special way to use linear space textures, just remember to check the final result in game.
There are some more technical things to consider, like if you're using gamma space specular but find a measured reflectance value in linear space. In that case you will need to convert the values.
Here is the math required to do the conversion(courtesy Jeff Russell):
Lastly, all your textures do not need to be linear space "to be pbr", I've heard this before, I'm not sure what the source of this information is but its factually incorrect. Color space simply defines how much precision is used for the darker values (more in the case of sRGB) vs a linear distribution of precision for the data (linear space). Color space in regards to texture inputs actually has nothing to do with physically based rendering (other than the fact that you may need to convert your measured base values - which depends on the source of said values). However, most renderers that have PBR shaders, the renderer itself is in linear space(for a variety of technical reasons), but this is something different entirely.
Lastly, all your textures do not need to be linear space "to be pbr", I've heard this before, I'm not sure what the source of this information is but its factually incorrect.
If using the metalness workflow, you can pack metalness, gloss, and cavity into 1 24bit image.
Generally its best to avoid packing in alphas, as that will double your compressed texture memory for those textures, only exception is if you're running out of texture calls or something.
For instance, even if you need 5 single channel maps, lets say:
alpha
metalness
gloss
ao
cavity
It would be better to pack these into 2 24 bit images, and have an empty channel in one, than pack the two extra into the alpha channel of 2 32bit images, as that would give you the texture usage equivalent to one extra 24bit image of the same resolution.
Hey thanks for the reply!
But I'm a bit baffled still.
Where does the texture data get doubled? In storage or when unpacked at that render call?
I'm guessing this is just because DDS compressions are optimised for 3 channels and not 4 channels? Ie, rather than being 4/3rds the size, it's 2x the size! Not ideal for filling up VRAM!
As per metalness work-flow what exactly does metalness mean? Is that just interchangeable with IOR, and perpendicular reflectivity etc?
Doesn't metal material need a coloured specular response, which means it needs an entire RGB texture to itself?
Also if we do rgb for ior, gloss and cavity, usually it's best to do IOR in gamma because it boosts the data for all those materials in the low-end of reflectivity at perpendicular angles.
If we run one channel in gamma, can we still easily load the other channels in linear space (gloss and cavity) which they seem to be better used in?
I'm easy whichever way, it's just good to be educated about as many different approaches and pros/cons as possible. At least that way you can just make the choice about optimal packing of the bits you do need into the right places in textures
Where does the texture data get doubled? In storage or when unpacked at that render call?
I'm guessing this is just because DDS compressions are optimised for 3 channels and not 4 channels? Ie, rather than being 4/3rds the size, it's 2x the size! Not ideal for filling up VRAM!
Yes this is a basic DDS compression issue, 24 bit images compress to 1/4th the original size, while 32 bit compresses to 1/2 the size of a 24 bit uncompressed texture (so the same vram as using 2 24bit DXT compressed textures).
As per metalness work-flow what exactly does metalness mean? Is that just interchangeable with IOR, and perpendicular reflectivity etc?
There is a lot of info on that in this thread and the tutorial linked in my sig, I won't explain it all again here. But basically, the metalness map is a toggle, it tags materials as metallic or not. For metals, IOR/base reflectivity is pulled from the albedo, for non metals, its set to a fixed value of 0.04. Metalness does not directly set IOR, instead, it defines where the IOR value is set (either with the albedo, a fixed value, or a mix of the two with values other than 0 or 1).
Doesn't metal material need a coloured specular response, which means it needs an entire RGB texture to itself?
Yes, metals need color, while non-metals typically do not. So for materials flagged as metalic the reflectivity is pulled from the full color albedo (metals have very little diffuse reflection, so the albedo channel is generally unused).
Also if we do rgb for ior, gloss and cavity, usually it's best to do IOR in gamma because it boosts the data for all those materials in the low-end of reflectivity at perpendicular angles.
Yep, that is one of the benefits of gamma space, better range in the lower values, which tends to make up a good portion of most images.
If we run one channel in gamma, can we still easily load the other channels in linear space (gloss and cavity) which they seem to be better used in?
I don't think that this is generally possible, but may be in certain engines. But usually if you're setting IOR directly, you'll have a full color spec map to do so.
I'm easy whichever way, it's just good to be educated about as many different approaches and pros/cons as possible. At least that way you can just make the choice about optimal packing of the bits you do need into the right places in textures
Replies
same
It was a semi rhetorical question. Short of having a computer simulate environmental effects on a material I'd say its impossible, or very unreasonable, to remove all artist decision from material creation. Not only in regards to how they brush damage, or mask things, but the values of materials themselves.
People keep using the word "Accuracy". Well, accurate to what? Lets say quixels values where dead on for a tarnished steel. Does that mean their reference and their data is accurate to my reference and what i'm attempting to recreate? I really don't know for sure, but my gut is saying no.
Like I said, maybe i'm wrong or misunderstanding the goal. its very possible as I'm not a master of materials.
put one lens horisontally across the flash, the other vertically over the camera lens, take your photo. it will strip out all of the specular highlights (for best results, do this in a dark room where there is little or no ambient light to interfere).
getting the reflectance values is a little more tricky, it involves taking the same photo from the exact same angle and position, but without the filters, converting the images to linear space, and then subtracting the highlight from the flat image. HOWEVER, a lot of that work is quite unneeded... keep your reflectance values low (or just use the metalness workflow) and you'll be surprised how many non-metals will work with this method.
Models still need to be modeled, colors still need to be decided, and roughness maps still need to be made, and stuff like dirt and stuff still needs to be applied, so it's not like the creative process is all gone
@almighty_gir - that's pretty neat! I did not know that actually. If you have a reliable source I'd like to add that into a section. It's really cool to think you can do that so "simply".
@s6 - please note that I have changed the name to Encyclopaedia (the name may change a 3rd time) from Bible. It's just that the thread name does not update unfortunately
All I'm suggesting, as Shrike originally suggested, is that people learn why materials behave the way they do instead of relying on a cookie cutter system to drag and drop materials onto their asset.
This isn't in response to a PBR encyclopedia, which I think is a great idea/utility, but more in response to those who are looking for a silver bullet look up for materials.
Edit:
This^
Problem is you need a eye as well
Its like 3py0n said; "guessing after guidelines"
Thats not a artistic choice, its just lack of information
Having better documentation will not suddenly take your artistic choice away, how did you imagine that ? : P
Regardless I'll be updating the doc more today.
Sooner or later most AAA studios will have the libraries and everyone working there will have to adjust anyways I guess, we either wait until a large one goes public or we create one ourselves, or we continue feeding a accurate system with inaccurate data in the hope its close enough to the accurate values
damn im getting too heated up, having too strong of a opinion again hah
Why do you think large libraries won't be disclosed? Because it takes time, expertise and money to create them. I know for a fact that if I disclose too much sensitive info that I've gained directly from the studio I work for, I'll be reprimanded by them. Why do you think all the other experienced PBR guys on here who work for big companies (like Xoliul for example, sorry to call you out Laurens) are being very careful what they say about it publically?
e/ disclosing the info is likely not because the people "in the know" don't want to give it to you. It's probably because they don't want to put their own job on the line. NDAs are serious business.
A library built by various individuals is unfortunately prone to all sorts of issues as well, again calibration and whatnot.
Personally I have more faith in Megascans than anything else when it comes to the idea of a publicly available library that covers a wide ranger of material types.
http://www.polycount.com/forum/showthread.php?p=2089327
haha great tut!!! For anyone who wants to do a kinda self-hack for values that's pretty cool. I'll add it.
Will be making a more indepth and detail-oriented table of contents soon. But at the moment this is the hierarchy.
Blue Headings
Also want to do a shoutout to d1ver while I'm at it. He's developed a pretty nifty tool!! Though I'd be cautious for newcomers to the PBR realm and try to do a project on your own with little to no helping tools first to get the hang of this newer form of workflow. Just my 2 cents.
Metal and non-metal can both be done with a single PBR material can't they?
Only issue is metallic IOR map needs to be coloured (rgb) and not just a single perpendicular reflectivity value like non-metals (ie single channel or alpha or whatever)
So ideally can we do all nice PBR materials with this?
rgb diffuse, alpha AO
rgb spec, alpha gloss (linear)
rgb normals (linear), alpha cavity
That seems pretty reasonable to me to cover everything, or did I miss anything?
If you need alpha for transparency can we just dump AO or cavity, or even just re-arrange if it's not got metals in there and free up some channels in the spec map too!
Thanks
Dave
Anyone have a couple of minutes to clarify the main differences between this workflow and PBR for games?
I'm not asking this to be an asshole, but have you read the document in the OP of this thread? or any of the documentation on PBR yet? There is a lot of info on the first page of this thread alone, plus the Marmoset tuts, the TB2 threads, etc.
Gloss, Roughness, and microsurface are more or less interchangeable terms. Albiedo(diffuse) should be familiar to you if you're used to no lighting info. The biggest thing you may have to get used to is how PBR handles reflectivity and microsurface. Albiedo and Reflectivity (specular) do less of the heavy lifting and microsurface does a bit more.
As Joe posted on the first page: http://www.marmoset.co/toolbag/learn/pbr-theory
That page should get you pointed in the right direction.
If using the metalness workflow, you can pack metalness, gloss, and cavity into 1 24bit image.
Generally its best to avoid packing in alphas, as that will double your compressed texture memory for those textures, only exception is if you're running out of texture calls or something.
For instance, even if you need 5 single channel maps, lets say:
alpha
metalness
gloss
ao
cavity
It would be better to pack these into 2 24 bit images, and have an empty channel in one, than pack the two extra into the alpha channel of 2 32bit images, as that would give you the texture usage equivalent to one extra 24bit image of the same resolution.
Just to be clear you mean to say it's better to pack information into the RGB channels than it is to pack it into the the alpha channel because the alpha channel is the same a having a full 24 bit texture. I have a quick question then why does Marmoset only support alpha in the alpha channel of the albedo texture? Wouldn't it be better to input it into a separate map where you can cut down the expense?
Yes, that is what I am saying. With DXT compression, when you add an alpha channel you double the size in memory, so you can use another full color map, with up to 3 inputs instead. This isn't specific to PBR or anything, but rather general optimization.
As far as why Toolbag only supports alpha from diff.a, its a simple limitation due to the fact that that is where people commonly store a transparency mask. A couple people have requested loading transparency from a separate map and its a good idea that I would certainly like to see as well, we just haven't had time to implement it yet.
Hrmm...wasn't aware you could pack it so much. But does it depend on the engine/nature of the project you're working on that would warrant such a route? I don't see why one would (for standard portfolio purposes) pack so many maps into 1. (ex. the metalness workflow)
As well I have updated the doc with the information from more sources, including:
http://www.marmoset.co/toolbag/learn/pbr-theory
and some from: http://www.marmoset.co/toolbag/learn/pbr-practice
Have not finished with the pbr-practice page yet as there is a lot of information there.
now try it out with a 24bit texture and a 32bit texture.
Right, exactly how you optimize or pack your content is going to be engine, or perhaps project and even asset specific, and again content packing isn't specific to PBR, this is more of a general concept.
However, the same could be said for the metalness workflow, its a very much pipeline specific technique and isn't mutually exclusive to PBR.
Its not something you necessarily need to worry about for your portfolio, but understanding how to pack content, or rather how much memory adding a bunch of extra maps and packing them inefficiently takes up in a real world scenario is important for every artist.
Cool!
Oh yea for all, please refer to the original post for updates on the doc. I've been updating everyday but only recently made it known via a post that an update has occurred, just incase anyone thought that it wasn't being worked on, etc.
So the very first thing I will do even before baking is I bring my High Poly into Marmoset and I prototype my materials. There are a couple of reasons for this. First it allows me to see what the final product might look like and determine if I am happy with the sculpt. Second it gives me a base to start my textures.
The basic process of prototyping my materials is I will look up something close to what I want for the reflectivity. So with the daggers I started with gold which I pulled the value from the Crytek PBR chart. I wanted something a bit less bright and a bit more orange. So I just shifted the values until I got something I was happy with. I used the same process for getting the reflectivity of the other materials.
For albedo I generally don't reference any charts. I just try to make sure it falls into more of a mid range. You don't want it to be too dark or too bright ( except for some special cases like snow). If you look at the don't nod Albedo values chart even coal only goes as low as 50 in RGB values.
I don't worry about gloss so much. I prototype out the values, but I don't really follow them that much as I have to convert them from linear to srgb. I just use it as more of a visual target than actually grabbing the value.
That's it! I just pull those values directly from marmoset and put them into may textures. I do tweak them from there, but it's really good for getting started and getting a feel for what you want your model to look like.
Most of this is really about referencing what you have values for and tweaking it to where you want. You just need to make sure you are with in range and it will look good.
If anyone has any questions let me know.
Hope this helps you all out.
Here is a screenshot comparing my prototype and my final model:
I think for me, it's more of just getting used to translating between linear and sRGB...which will be a little tricky for me as I've not done it before and even having the knowledge from doing the PBR doc, without practice I don't feel comfortable yet
Oh yeah and the reason you don't have to worry about the linear conversion for albedo and reflectance is because the values given to you on most PBR charts are already converted to srgb and most engines convert that back to linear for you. So you can just work in srgb.
What matters is how it looks in your game engine/renderer, and thats where you will check when authoring content.
Only other thing to really keep in mind is if say, you preview your textures in Marmoset Toolbag (linear for gloss by default) and then load into Unreal or another engine, just make sure to set the texture to linear there as well.
when working in pbr should i care for the linear/gamma values or just work on the textures like i did in the legacy workflow? (Does that question make any sense?)
I have read through most of the info out there on pbr but the linear/gamma confuses alot.
Do I adjust the linear value in photoshop or MT2, UE4 etc?
I'm asking this because when I see values on toolbags website that are 0.04 or so i get confused.
Basically what EarthQuake said.
In TB2, you can click on the per-texture options button and enable or disable sRGB. sRGB on means gamma corrected, sRGB off means linear space. In UE4, there is also an sRGB check in the texture properties I believe.
Normal maps are the only map that really HAS to be linear space, normal maps don't work at all when loaded as sRGB. This is true if you have pbr shaders or not. In UE4 and TB2 normal maps will load with sRGB off by default.
Gloss/roughness maps and metalness maps tend to be linear space as well, but they don't necessarily have to be. From a practical persective, any input that defines a percentage value (like gloss and metalness), makes sense to use linear color space for the texture input. This is so you can easily mock up a material will a parametric input in your shader (which tends to be linear space), and then easily duplicate that value in photoshop by selecting the color with the brightness input in the color picker. The values for these maps will not be accurately visualized in photoshop though (which works in gamma space by default), so its important to verify the results in the actual shader/game/renderer and not worry about what it looks like in 2d.
Albedo and specular color maps tend to be sRGB, but again they can be linear space too. Generally its more helpful to have an accurate visualization for these types of maps (and full RGB parametric inputs can be in gamma space as well, as is the case in TB2), which is why these maps are often sRGB. Though again, you can use the same workflow as above and work in linear space, with the understanding that the visual representation will not be accurate and you need to check the results in game, which is important no matter the workflow.
Generally its important for this to be consistent throughout your project, which maps are in linear or gamma space. Its not something that should vary per asset, so talk to your technical artist, engineers, etc if you're confused about which to use.
Again, you don't need to set photoshop up in a special way to use linear space textures, just remember to check the final result in game.
There are some more technical things to consider, like if you're using gamma space specular but find a measured reflectance value in linear space. In that case you will need to convert the values.
Here is the math required to do the conversion(courtesy Jeff Russell):
sRGB to linear: http://www.wolframalpha.com/input/?i...here+S+%3D+0.5
linear to sRGB: http://www.wolframalpha.com/input/?i...here+L+%3D+0.5
Lastly, all your textures do not need to be linear space "to be pbr", I've heard this before, I'm not sure what the source of this information is but its factually incorrect. Color space simply defines how much precision is used for the darker values (more in the case of sRGB) vs a linear distribution of precision for the data (linear space). Color space in regards to texture inputs actually has nothing to do with physically based rendering (other than the fact that you may need to convert your measured base values - which depends on the source of said values). However, most renderers that have PBR shaders, the renderer itself is in linear space(for a variety of technical reasons), but this is something different entirely.
Hey thanks for the reply!
But I'm a bit baffled still.
Where does the texture data get doubled? In storage or when unpacked at that render call?
I'm guessing this is just because DDS compressions are optimised for 3 channels and not 4 channels? Ie, rather than being 4/3rds the size, it's 2x the size! Not ideal for filling up VRAM!
As per metalness work-flow what exactly does metalness mean? Is that just interchangeable with IOR, and perpendicular reflectivity etc?
Doesn't metal material need a coloured specular response, which means it needs an entire RGB texture to itself?
Also if we do rgb for ior, gloss and cavity, usually it's best to do IOR in gamma because it boosts the data for all those materials in the low-end of reflectivity at perpendicular angles.
If we run one channel in gamma, can we still easily load the other channels in linear space (gloss and cavity) which they seem to be better used in?
I'm easy whichever way, it's just good to be educated about as many different approaches and pros/cons as possible. At least that way you can just make the choice about optimal packing of the bits you do need into the right places in textures
Thanks
Dave
Yes this is a basic DDS compression issue, 24 bit images compress to 1/4th the original size, while 32 bit compresses to 1/2 the size of a 24 bit uncompressed texture (so the same vram as using 2 24bit DXT compressed textures).
There is a lot of info on that in this thread and the tutorial linked in my sig, I won't explain it all again here. But basically, the metalness map is a toggle, it tags materials as metallic or not. For metals, IOR/base reflectivity is pulled from the albedo, for non metals, its set to a fixed value of 0.04. Metalness does not directly set IOR, instead, it defines where the IOR value is set (either with the albedo, a fixed value, or a mix of the two with values other than 0 or 1).
Yes, metals need color, while non-metals typically do not. So for materials flagged as metalic the reflectivity is pulled from the full color albedo (metals have very little diffuse reflection, so the albedo channel is generally unused).
Yep, that is one of the benefits of gamma space, better range in the lower values, which tends to make up a good portion of most images.
I don't think that this is generally possible, but may be in certain engines. But usually if you're setting IOR directly, you'll have a full color spec map to do so.
np