Learned 2 very important things!!! Still did not know that before watching this: Most Materials are more towards rougher values... and AO maps should´nt contain large gradients but smaller areas and microdetail. Very valuable infos you don´t find that easily elsewhere on the net. Great Video! Thanks for uploading.
It's worth mentioning that Handplane will take in 16bit images and spit out 16bit images, it's not lossy. I do all my object space baking in 16bit PNG and that works perfectly with Handplane. However, you'll probably want to downsample it to 8bit inside of Photoshop before bringing it into your game (as Photoshop's downsampling dithering does a really nice job of hiding any banding you'd otherwise see if it was just a straight conversion). Also (as the author of the Unity TSpace plugin) what issues are you seeing? It's results should be identical to Handplane's output.
xNormal will if you use TIF format. Modo will export anything you want (and the 16bit PNGs I use). Not too sure about others, I don't bake in anything else.
Game artists like post effects because unlike what real photographers capture their scenes are artificial and post-effects distort those artificial images in a way that they think seems more "organic". There's also the fact that it blurs things so it reduces aliasing. Personally, I think bloom looks great if you want to make a foggy or underwater scene. In everything else it needs to be minimal, very subtle.
Fantastic talk. Thanks! I'm glad that the whole horror of normalmap seams gets exposed more these days. I spent lots of hours digging up info and testing and figuring out things in the past, before realizing it wasn't all my fault and I'm not the only one almost going crazy about it. I always assumed everyone actually working in the industry is well versed and has no problems at all with this. I really just have one question regarding your presentation. What is the problem with Substance Designer 4 baking? I used to use xNormal and a batcher app but then tested the SD4 trial and found maps looked great in Unity since it's sync'd to that tangent basis and their blurring algorithm seems to help as well. Also with the node based system adding normalmaps from different objects is simpler/quicker than doing that in yet another app and also much more automated when rebaking. (I didn't do much hard surface yet, so maybe there's the problem?)
SD4 of course has an incredible workflow, but I've had intermittent problems with tangent basis in it, and haven't yet had the time to figure out the _guaranteed_ way to have it work. There's also the problem of when one needs to bake from a non-standard mesh source (utterly massive zbrush meshes, 3dcoat voxel files, etc.) where one simply can't use SD4/Xnormal for the bake process. For those, I've found object-space map + Handplane to be the only option.
Anton Hand Thanks for clearing that up. I plan to incorporate SD4 into my asset creation pipeline and was worried there was some deep but obvious problem I haven't encountered or failed to realize while testing the trial. There is just so much that can go wrong and lead to seams that I'm always expecting things to break (like horrible normalmap seams appearing if you have mirrored UVs overlapping in one engine, but in the other engine this happens if you do not overlap them.) Also I found some seams showing up slightly inside the SD4 viewport, while it was perfectly fine in Unity's viewport. No idea why if they are really sync'd. Where do you get the object space maps for those non-standard mesh sources you mentioned ? The biggest mystery is why this is such a huge problematic and fragmented area to this day. Normalmaps have been around for so long with massive parts of the industry relying on it, I shudder at the pure amount of hours wasted and spent in anger and frustration. But then with PBR it seems nobody can even agree on sticking to one word and we get smoothness/roughness/glossiness...
Horst-Peter Bittmann re: Object space maps: In general, if a program bakes tangent space normal maps, it does object-space ones. The nice thing about object space maps though, is that there's no basis issues. Its just a direct angle-relative-to-identity thing. So the only thing that has to be correct is your converter. Honestly, the reason I think we have this fragmentation is two-fold: 1. (and i know this is unfair) Devs dont fucking talk to artists. Fullstop. 2. The way we use normal maps has changed dramatically. They were never 'designed' to be precise topology approximations. They were designed to be able to add topological noise. It was only epic (and others) who started using them this way first in Zbrush (when it was still deludedly doing that 2.5D painting silliness). So really, we're using a mal-adapted FRAGILE data-encoding process for all our hardsurface stuff. 3. Between Mesh tangents/binormals/etc., decoding processes, etc. We have soo very many moving parts in this problem. Further, different types of developers (engine vs. authoring tool) are each responsible for different parts of it. So we have a _major_ communication problem between engineers burried in two different sorts of companies. Even behemoths like Autodesk can't even get this working _internal_ to themselves. At the end of the day, this is only going to get fixed if we hammer on everyone involved and make clear that this is _essential_ that this gets fixed, and that its truly an issue of collective concern to _everyone_ doing realtime work.
the images in the right , the ones he supposedly showed as being "worse" ,look way better than what he brags about. bloom? are you kidding me? that's so cheezy and kitchy.
+Nic Tanghe guess everyone is different, I thought the worse ones looked... worse :) I wouldn't consider him bragging, here's a guy taking the time to give us some of his knowledge and thoughts and showing two cases. The worst we could do is thank him for taking the time to prepare this.
Neer thought he ws bragging. Just think he uses to much of a certain effects. So much so that sometimes it lookes better without it. This happens allot in video games.
This is a great talk! I use Unreal Engine 4, but I find this generally very helpfull. Using PBR materials is not a religion (although some people treat it as if), but getting an understanding of all the different components involved is invaluable! Did you use Filer Forge for some of your textures shown or is it all Substances?
Hi Hi :-) I did indeed use filterforge for a bunch of those samples, or rather I used a couple maps from a given filter as seed data, and ignored the parts that don't make sense for PBR. Wonderful little tool, though mostly from the hard work its community had put into making quality filters.
Thank you for replying! I bought Filter Forge on intuition and really love it, even though I use it more for 2D (logo Design, Post FX). I don't know if that is your thing, but would you mind showing how you integrated it into your 3D-workflow? I didn't yet use it for my texturing process, but I know I should. It could also use a bit more promotion.
I'm sorry but I'm still confused. You have nothing to do with Rust by Facepunch Studios right? I just can't get over the similarities and or coincidences. The font, the slides, the color schemes of all the slides and what not of the talk are EXACTLY the same as in Rust experimental currently.
If you really want to go for graphics, Unity is not the best possible choice. CE3 is great but if youre really advanced you should go for the UDK node based mat editor
As a new developer, I tried both Unreal Engine 4 and Unity 4, and I thought the metal-roughness in UE4 was harder to tweak the way I wanted to compared to the spec-gloss style of Unity. Changing metal and roughness appeared to change more than one parameter at a time, or it was simply harder to track what effect they had, which made them more confusing and difficult to use for me. So I'm actually happy that they chose the spec-gloss model for Unity 5.
Wintran I think this is mostly inexperience with the two new models (or a lot of experience with older models that are more similar to spec/gloss). That, or you're trying to make physically improbable materials either to accommodate non pbr lighting, or to make something visually strange (like the Covenant ship material from Halo). I think you'll find with only a little bit of practice, you will be much better at guessing roughness and metal values than you will ever be at picking out spec reflectivity. For instance, What is the diffuse and spec values for tarnished silver? I have no clue (maybe diff of dark grayish yellow with a brightness of around 40?, and a spec of medium/light grayish yellow with a brightness of around 160?). Without scan data, I suspect there are very few people in the world who would be able to make reasonable guesses for these values. On the other hand, what is the color and metallicity of tarnished silver? Well, it's a yellowish grey color (brightness around 200) and fairly metallic (maybe 0.8?). Even without scan data, I can make solid guesses to these values. Also, in spec gloss, you end up having to throw out a lot of the data, for instance, nonmetals have spec ranges that are (almost) always below 40 and 60, and metals always have ranges above 180. Not only that but almost all materials have uncolored spec, but we have to have a colored spec map anyway just to account for the few metals and metallic paints that do. It's just an inefficient use of texture data (not to mention that it's also hard to compress). I guess that's just a long way of saying that I strongly disagree that Unity should be using this standard. I know you have your own opinions, and you're welcome to them, and I'm happy for you, but I don't think that it's the way Unity or the industry generally should go. :/ For more information on both standards, check out the PBR Encyclopedia which was collected by some guys at Polycount: docs.google.com/document/d/1Fb9_KgCo0noxROKN4iT8ntTbx913e-t4Wc2nMRWPzNk/edit
Ryan Gatts Thanks for the detailed info and humble post! I see your points, and I won't judge the metal-roughness model until I've tried it more. Might just be me being not used to it as you say.
Too bad color correction & screen space effects like bloom are an absolute no-no for mobile. Also color correction is neat, but fully relying on it is bad asset management.
Technically Unity 5 will have a realtime reflection system, but only for mirror-like reflections. They will not have roughness options like the pre-filtered reflection probes.
CynicatPro For Pre-computed reflections yes. For real-time ones no, due to the expense of that blurring/convolution. There is a technique called importance sampling that can give you real-time blurry reflections, but it will be several more GPU generations before one can actually use it.
***** you can make sure the normal maps are perfect, when baked from textures there may be errors and weird looking parts. Baking from textures is MUCH easier though
***** As MIRACLECHEEZ says, if you bake from mesh, you get exactly what you see in the viewport in a low poly mesh (without count the countour, obviously). but when you bake from tex, you can get a lot of glitches and undesired bumps. Its ok for quick works, but if you wanna go "pro", you need to bake ur normals (and get awesome results)~
PiroKunCL Yeah I did some research, so I'm assuming you make a low-poly mesh and have a duplicate version with high-poly details, and then bake a normal map of the high detail model to a texture, then it is now a normal map? Also how do you bake object-space maps? I'd love to learn how to use those.
He is soooo right about normal maps.. huge frustration for me!! Thank you for that plug in mentioned.
Just wanted to say thank you for sharing this! Makes the transition towards PBR workflow all the more graspable.
Learned 2 very important things!!! Still did not know that before watching this:
Most Materials are more towards rougher values... and
AO maps should´nt contain large gradients but smaller areas and microdetail. Very valuable infos you don´t find that easily elsewhere on the net. Great Video! Thanks for uploading.
Great presentation. Looking at Rust Ltd. website, very cool stuff on there. Thoroughly enjoyed the talk. :)
i love pbr the first time i herd of it i was obsessed with using it in my game.
Wicked great work, Anton... kick ass.
It's worth mentioning that Handplane will take in 16bit images and spit out 16bit images, it's not lossy.
I do all my object space baking in 16bit PNG and that works perfectly with Handplane.
However, you'll probably want to downsample it to 8bit inside of Photoshop before bringing it into your game (as Photoshop's downsampling dithering does a really nice job of hiding any banding you'd otherwise see if it was just a straight conversion).
Also (as the author of the Unity TSpace plugin) what issues are you seeing? It's results should be identical to Handplane's output.
Oh, most certainly. It slipped my mind on that point. Critically though, many apps lack the ability to bake out a 16-bit object-space normal map.
xNormal will if you use TIF format. Modo will export anything you want (and the 16bit PNGs I use). Not too sure about others, I don't bake in anything else.
Excellent talk thanks Anton
blooming is something that most professional photographers despise.
Game artists like post effects because unlike what real photographers capture their scenes are artificial and post-effects distort those artificial images in a way that they think seems more "organic". There's also the fact that it blurs things so it reduces aliasing. Personally, I think bloom looks great if you want to make a foggy or underwater scene. In everything else it needs to be minimal, very subtle.
Great talk Anton!
Great stuff Anton, as always!
Awesome talk
Fantastic talk. Thanks! I'm glad that the whole horror of normalmap seams gets exposed more these days. I spent lots of hours digging up info and testing and figuring out things in the past, before realizing it wasn't all my fault and I'm not the only one almost going crazy about it. I always assumed everyone actually working in the industry is well versed and has no problems at all with this.
I really just have one question regarding your presentation. What is the problem with Substance Designer 4 baking? I used to use xNormal and a batcher app but then tested the SD4 trial and found maps looked great in Unity since it's sync'd to that tangent basis and their blurring algorithm seems to help as well. Also with the node based system adding normalmaps from different objects is simpler/quicker than doing that in yet another app and also much more automated when rebaking. (I didn't do much hard surface yet, so maybe there's the problem?)
SD4 of course has an incredible workflow, but I've had intermittent problems with tangent basis in it, and haven't yet had the time to figure out the _guaranteed_ way to have it work. There's also the problem of when one needs to bake from a non-standard mesh source (utterly massive zbrush meshes, 3dcoat voxel files, etc.) where one simply can't use SD4/Xnormal for the bake process. For those, I've found object-space map + Handplane to be the only option.
Anton Hand
Thanks for clearing that up. I plan to incorporate SD4 into my asset creation pipeline and was worried there was some deep but obvious problem I haven't encountered or failed to realize while testing the trial. There is just so much that can go wrong and lead to seams that I'm always expecting things to break (like horrible normalmap seams appearing if you have mirrored UVs overlapping in one engine, but in the other engine this happens if you do not overlap them.)
Also I found some seams showing up slightly inside the SD4 viewport, while it was perfectly fine in Unity's viewport. No idea why if they are really sync'd.
Where do you get the object space maps for those non-standard mesh sources you mentioned ?
The biggest mystery is why this is such a huge problematic and fragmented area to this day. Normalmaps have been around for so long with massive parts of the industry relying on it, I shudder at the pure amount of hours wasted and spent in anger and frustration.
But then with PBR it seems nobody can even agree on sticking to one word and we get smoothness/roughness/glossiness...
Horst-Peter Bittmann re: Object space maps: In general, if a program bakes tangent space normal maps, it does object-space ones. The nice thing about object space maps though, is that there's no basis issues. Its just a direct angle-relative-to-identity thing. So the only thing that has to be correct is your converter.
Honestly, the reason I think we have this fragmentation is two-fold:
1. (and i know this is unfair) Devs dont fucking talk to artists. Fullstop.
2. The way we use normal maps has changed dramatically. They were never 'designed' to be precise topology approximations. They were designed to be able to add topological noise. It was only epic (and others) who started using them this way first in Zbrush (when it was still deludedly doing that 2.5D painting silliness). So really, we're using a mal-adapted FRAGILE data-encoding process for all our hardsurface stuff.
3. Between Mesh tangents/binormals/etc., decoding processes, etc. We have soo very many moving parts in this problem. Further, different types of developers (engine vs. authoring tool) are each responsible for different parts of it. So we have a _major_ communication problem between engineers burried in two different sorts of companies. Even behemoths like Autodesk can't even get this working _internal_ to themselves.
At the end of the day, this is only going to get fixed if we hammer on everyone involved and make clear that this is _essential_ that this gets fixed, and that its truly an issue of collective concern to _everyone_ doing realtime work.
Wow!! Cool!
the images in the right , the ones he supposedly showed as being "worse" ,look way better than what he brags about. bloom? are you kidding me? that's so cheezy and kitchy.
+Andy Austin The man has a crazy idea about estetic.
+Nic Tanghe guess everyone is different, I thought the worse ones looked... worse :) I wouldn't consider him bragging, here's a guy taking the time to give us some of his knowledge and thoughts and showing two cases. The worst we could do is thank him for taking the time to prepare this.
Neer thought he ws bragging. Just think he uses to much of a certain effects. So much so that sometimes it lookes better without it.
This happens allot in video games.
This is a great talk! I use Unreal Engine 4, but I find this generally very helpfull. Using PBR materials is not a religion (although some people treat it as if), but getting an understanding of all the different components involved is invaluable!
Did you use Filer Forge for some of your textures shown or is it all Substances?
Hi Hi :-) I did indeed use filterforge for a bunch of those samples, or rather I used a couple maps from a given filter as seed data, and ignored the parts that don't make sense for PBR. Wonderful little tool, though mostly from the hard work its community had put into making quality filters.
Thank you for replying! I bought Filter Forge on intuition and really love it, even though I use it more for 2D (logo Design, Post FX). I don't know if that is your thing, but would you mind showing how you integrated it into your 3D-workflow? I didn't yet use it for my texturing process, but I know I should. It could also use a bit more promotion.
Wonderful.
I'm sorry but I'm still confused. You have nothing to do with Rust by Facepunch Studios right? I just can't get over the similarities and or coincidences. The font, the slides, the color schemes of all the slides and what not of the talk are EXACTLY the same as in Rust experimental currently.
Well.. the description says he is from RUST ltd ;) so yeah
If you really want to go for graphics, Unity is not the best possible choice. CE3 is great but if youre really advanced you should go for the UDK node based mat editor
I wish unity's new default shader used a metalness-smoothness standard rather than the specular-smoothness one they're going with :/
As a new developer, I tried both Unreal Engine 4 and Unity 4, and I thought the metal-roughness in UE4 was harder to tweak the way I wanted to compared to the spec-gloss style of Unity. Changing metal and roughness appeared to change more than one parameter at a time, or it was simply harder to track what effect they had, which made them more confusing and difficult to use for me. So I'm actually happy that they chose the spec-gloss model for Unity 5.
Wintran I think this is mostly inexperience with the two new models (or a lot of experience with older models that are more similar to spec/gloss). That, or you're trying to make physically improbable materials either to accommodate non pbr lighting, or to make something visually strange (like the Covenant ship material from Halo). I think you'll find with only a little bit of practice, you will be much better at guessing roughness and metal values than you will ever be at picking out spec reflectivity.
For instance, What is the diffuse and spec values for tarnished silver? I have no clue (maybe diff of dark grayish yellow with a brightness of around 40?, and a spec of medium/light grayish yellow with a brightness of around 160?). Without scan data, I suspect there are very few people in the world who would be able to make reasonable guesses for these values.
On the other hand, what is the color and metallicity of tarnished silver? Well, it's a yellowish grey color (brightness around 200) and fairly metallic (maybe 0.8?). Even without scan data, I can make solid guesses to these values.
Also, in spec gloss, you end up having to throw out a lot of the data, for instance, nonmetals have spec ranges that are (almost) always below 40 and 60, and metals always have ranges above 180. Not only that but almost all materials have uncolored spec, but we have to have a colored spec map anyway just to account for the few metals and metallic paints that do. It's just an inefficient use of texture data (not to mention that it's also hard to compress).
I guess that's just a long way of saying that I strongly disagree that Unity should be using this standard. I know you have your own opinions, and you're welcome to them, and I'm happy for you, but I don't think that it's the way Unity or the industry generally should go. :/
For more information on both standards, check out the PBR Encyclopedia which was collected by some guys at Polycount: docs.google.com/document/d/1Fb9_KgCo0noxROKN4iT8ntTbx913e-t4Wc2nMRWPzNk/edit
Ryan Gatts Thanks for the detailed info and humble post! I see your points, and I won't judge the metal-roughness model until I've tried it more. Might just be me being not used to it as you say.
Are the slides from this available anywhere?
I found it funny when he critized AO for not being physically accurate right after talking about Bloom and Tonemapping.
Too bad color correction & screen space effects like bloom are an absolute no-no for mobile. Also color correction is neat, but fully relying on it is bad asset management.
He sounds like he is about to cry.
small question will unity 5 have a free version or will the free version stop in 4.6? and if unity 5 haves a free version what will we get?
The free version is staying free, don't worry about that.
what im afraid is that all the new improve graphic and other cool new tool will only be reseved for the pro and the free version will stay the same =(
seb lop Guess that concern has been taken care of
Very real: 7:24
are Kratos from GOW?
He has nice blue eyes.
I know how to fix the problem of the normal map,
In Unity is not Real-Time Reflections?! Damn!
Technically Unity 5 will have a realtime reflection system, but only for mirror-like reflections. They will not have roughness options like the pre-filtered reflection probes.
Joshua Ols
you can use the mip maps to blur the reflections i think.
CynicatPro For Pre-computed reflections yes. For real-time ones no, due to the expense of that blurring/convolution. There is a technique called importance sampling that can give you real-time blurry reflections, but it will be several more GPU generations before one can actually use it.
He sounds very nervous though.
weedtiger Was trying to not pass out for the first 10 minutes :-P
Its hard to be a speaker =)
Anton Hand Good thing you didn't, that would've been interesting :/
+Anton Hand ah, you did a great job
Blender can bake normal maps?
yes
PiroKunCL Ah, I usually bake normal maps from textures. What are the benefits of normal maps baked via mesh?
***** you can make sure the normal maps are perfect, when baked from textures there may be errors and weird looking parts. Baking from textures is MUCH easier though
***** As MIRACLECHEEZ says, if you bake from mesh, you get exactly what you see in the viewport in a low poly mesh (without count the countour, obviously). but when you bake from tex, you can get a lot of glitches and undesired bumps.
Its ok for quick works, but if you wanna go "pro", you need to bake ur normals (and get awesome results)~
PiroKunCL Yeah I did some research, so I'm assuming you make a low-poly mesh and have a duplicate version with high-poly details, and then bake a normal map of the high detail model to a texture, then it is now a normal map?
Also how do you bake object-space maps? I'd love to learn how to use those.