Just a couple of questions on PBR - We are working on mobile and looking to move over to PBR workflow for our environments. Being on mobile we have some pretty strict memory targets meaning its much more difficult to have a lot of textures in each material with normal maps being a bit of a no no on most things.
With PBR being pretty reliant on normal maps adding a fair bit of the lighting detail not having them does create some interesting questions.
So first question - how would you adjust your workflow if you where unable to use normal maps in your PBR work flow - would you be forced to add more lighting detail into your albedo maps? Or would you add more detail to the AO pass?!
My second question - When it comes to optimization in past projects the first big memory savings have been half sizing spec/gloss maps and keeping the diffuse double resolution.
With far more detail now being found in the roughness over the "diffuse" would you get better results from in fact downsizing the albedo and keeping the roughness a higher resolution.
Ta
PS - It would make sense to use the alpha channel of the albedo as the roughness and putting metal, AO, transparancy etc into RGBA of a second texture which would be down res'ed
Replies
Roughness/metalic shaders or AO doesnt make a game PBR. Its the LINEAR SHADING rendering pipeline. If you can't take advantage of an unclamped liner math renderer you are missing out on the entire meaning of PBR. You can organize your texture maps and channels any way you want, you can set up your shaders any way you want and be either PBR or not.
You can make a great looking game, especially on mobile, with great art direction and style instead of worrying about PBR rendering
We are at a stage were we are VERY early in development, and with unity 5 moving to PBR support it would seem a waste not to look into it and how we can make use of it as we move forward with content creation. At first glance we like the benefits and the results but memory issues do raise questions on how we can make use of the technology and fit it into how we want to work.
It might be that we sacrifice texture resolution for normal maps to make full use of the technology but I was just curious on other options on making use of the tech wile also making savings on the memory front.
[ame="https://www.youtube.com/watch?v=OeEYEUCa4tI"]https://www.youtube.com/watch?v=OeEYEUCa4tI[/ame]
I love the adoption of PBR by the industry at large, it makes my work so much easier and consistent. But you should not go into a project deciding on tech first and seeing how to use tech choices to make cool art. You should establish a great looking style with concept art and then see which individual pieces of technology help achieve that.
Nice one - will check it out
chronic - 100% agree with this, like you say we may well go back to a more classic diffuse/spec work flow if it gives better results on the format's we are aiming for with the final product - There are a lot of questions about how we can get the best results possible and what tech would be best suited for our needs.
Like i say, we are very much in that "investigation" stage with PBR and am just a little curious about some of the possible options with the work flow. I get the impression of you either do or you don't with very few options in between.
The albedo + normal will of course take up the RBG channels leaving two alpha channels but 3 sets of data. In that situation would you put the AO pass into the albedo and the roughness + metal into the Alpha channels? Or perhaps multiply the AO into the roughness too?
The albedo and normal would need their own textures. You can pack Rough, metal and AO into one texture. In a 16bit image, the AO should be packed into the green channel, since green has 6 bits, versus blue/red's 5 bits.
That's only scratching the surface though. Generally with PBR, you want image based lighting, and if you have complex environments, you need to blend between multiple IBL probes as the player moves around the level, and if you want the reflections to look right you need to do box correction as well, and if you want dynamic objects and self reflection in the reflection pass you need to do screen space reflections too.
Now, you don't absolutely need all of that, but most of it is common with PBR setups. PBR without IBL is going to look pretty bad so you would be better off going with more stylized textures with painted in lighting if you can't afford the shader complexity.
To the person who said you NEED super detailed textures for PBR, I don't think that is the case at all. It really depends on your art sytle, if you want super gritty realism, yeah you'll want detailed textures. If you're going for a more stylized pixar type look, you don't need high res greeble detail in every map.
To play devils advocate here, Alien:Isolation used PBR without any real sense of IBL (all deferred lighting with realtime GI) and a lot of people seem to think it looked better than "pretty bad" (would have been better with proper IBL, I'll admit).
I agree with the principle though that PBR is kind of ... one part of a high-end rendering ensemble orchestra. One trumpet won't get you all that far on its own.
With regards to memory I'll have a chat with the tech guys tomorrow and see what the options are with sticking to rgb rather then rgba. Again though, I think until we get going and get a better understanding on how we can to spend our memory its hard to make a call but it seemed worth starting the discussion on "worst" case options.
I'll be messing around with some test textures / materials over the coming week or so and will post some results.