It still looks cg and horrible. Its like putting makeup on a pig.
>>590862Oh look, it’s this thread again, and those lenses still look shit. As is Leica would be caught dead producing a coat material that looked like that irl.>>590863Metal/rough was made to simplify workflows by allowing the shader to make assumptions about the glossiness and specularity of an object based on whether or not it’s a metal, not to look better.Spec/Gloss actually offers more flexibility for those people who like to refer to spectral response graphs and flex their autism, as for example there do exist materials that may not be metal but exhibit unusually high specularity, like gemstones.
For CG? Nothing new.For realtime? Absolutely worthless.
>>590866Yeah if you're working with unusual materials or plan to create stuff that isn't 100% PBR, better go with the specular workflow for more flexibility.. otherwise anything considered dielectric will have its IOR and Specular values locked. You could technically have metalness maps with grey values, but that doesn't make much sense in the real world.>>590862It's very useful to have a standard workflow when it comes to realistic or somewhat realistic games. For very stylized stuff, I'm guessing it's alright but not mandatory, though it probably helps the integration inside PBR engines (shaders, lighting, camera post-effects, conservation of energy, etc.)
>>590874>For CG? Nothing new.True>For realtime? Absolutely worthless.Wrong
>>590863>what is PBR, the post
>>590876>WrongThere is no point in having physically based materials in a real time environment where the lighting and reflections are still inaccurate.
>>590863Go back to /tv/
>>590887Yeah well some things still have to be cheated, that applies to all CGI. But when engines, materials, cameras, physics, units, etc. all comply to real-life parameters, it's goddamn better than having all those things behaving according to their own individual shit. Reflections are still tricky, though doable, and lighting (also based on irl properties) is getting quite fine now when blending direct lights, baked GI, and realtime shadows/occlusion.Saying that there's no point in it is just ridiculous. It's not mandatory, but it sure does make sense for most of the situations you might encounter. A bit of standardization is a good thing overall considering it has zero impact on creativity.Just watch this talk and you'll understand how chaotic shading was back in the days. https://www.youtube.com/watch?v=IyUgHPs86XM
>>590887incorrect!what if you're going for the "uneasy" vibe and it's a horror movie?uncanny valley is real af.
>>590863>>590887These people don't get it. The main benefit of PBR isn't that it instantly makes results more appealing. The benefit is that it is standardized, easy to transfer across render engines, easier to achieve consistent results mixing work from multiple texture artists, easier to transfer assets from movies to game engines, and easier to reason about and develop from a theoretical mathematical perspective.>>590895This guy gets it.
>>590972(You) and (me) >>590895 broFinally some sense in one of these threads
>>590972PBR was developed to ensure the materials you make are consistent across all different lighting setups for your project so you no longer had to make a dozen different materials to switch between so the old hack-job speculars don't get completely blown out the moment something moves into the shadows. Instead you get materials that still look like complete shit because the reflections, the key element that makes PBR materials look decent, aren't accurately implemented into any real time renderer and the only way to fix that is to move things to a pathtracing solution which also means people would be moving on to use something like Disney's principled shaders instead.PBR is worthless.
>>590874>worthless for realtime>every single game engine uses PBR >yfw composing that postPBR is far more intuitive, painting a diffuse and specular map separately is retardedas soon as offline renderers update their 30 year old workflow non-PBR will be a thing of the past
>>591070>as soon as offline renderers update their 30 year old workflow non-PBR will be a thing of the pastimplying professional artists in texturing/shading/lighting/lookdev/rendering/etc arent working according to PBR principlesyeah, we could reuse your Homer jpg here
>>591062>the only way to fix that is to move things to a pathtracing solution which also means people would be moving on to use something like Disney's principled shaders insteadyou'll have to elaborate on that
>>590887>no point There certainly is a point. People find the visuals more appealing. Even super inaccurate basic techniques for handling reflection like cube maps and screen space reflections are used to good effect. And pbr models take good effect from these techniques. Obviously none of this stuff is perfect but for many realtime applications you don't need to have it be perfect you're just pushing to be close to the top of the industry. >>590972https://en.m.wikipedia.org/wiki/Physically_based_renderingI disagree. The point of PBR is to emulate our physical world. Whatever standardization benefit you may experience is secondary. And I frankly disagree on that point. Even in pbr environments we have different shaders for different tasks. You won't take a game asset from one game and throw it into another and have it look the same. Any standard (such as having explicit formats for diffuse maps and normal maps, which we didn't at one point) helps that. But there's a lot of work outside of the 3D artists space. PBR doesn't cover all desired aspects of rendering, naturally.
>>591094I mostly agree with the points you're trying to make, but I'm confident PBR's goal isnt to make "visuals more appealing". You can have very appealing and/or stylized results that are super wrong considering physics. PBR is just streamlining the workflows in a coherent manner; what comes out of it is somewhat irrelevant.Using basic shading (albedo, ao, spec, gloss, normal), you could, yes, throw assets from an engine to another and virtually have the same result (or quite close to it). When the engines emulate the physical world properly, as you were saying, its bound to happen.
>>591062Isn't Disney's principled shader a PBR shader anyway?
>>591130IIRC, it is, so >>591062 is clearly misinformed.
Professionals both working on games and advanced game engines: PBR is good, easier to use, has got great functionality and tools built around it, the realtime reflectivity calculations improve visuals in a way we can't with other formats and put games a step closer to photorealism.Random dudes on gaming forums: Durr it's absolutely worthless hurr why even try if you can't go full raytracing immediately, I expect to be taken seriously while saying engines should jump straight to full GI, a thing I think today's hardware can handle at the framerate required of a game engine. See also: people who seriously think Voxels will be a thing in the near future.
I think people would faster see the concept if they ignored the buzzword name of Physically-Based Rendering.That's dependent on the shaders most of all, like many people have said it mostly just offers standardized names for different sorts of textures and splits different tasks between those textures, such as how reflective something needs to be.There's really nothing stopping someone from abandoning the implied "physically-based" aspect to any degree; be it multiplying a little bit of AO to the albedo, or just plain painting a fully lit cartoon texture for the albedo and using the metalness texture to control reflections on it and AO to keep global light out of the shadows you painted on.Just strip away the preconceptions about their use as a whole and look at the jobs the textures are given in the naming convention, not even in a shader.Albedo is just what color the model is. It not having AO or shine or shadows painted or bake on is just an implication, and what you'd do if you wanted to use it for realism.Roughness is just controlling how sharp or soft reflections are.AO just controls how much or how little global lighting appears on the model.None of these -have- to be used for realism, or really in any one way. There's just a standard for it to be used in a realistic manner, and the separation of jobs between textures is inspired by how materials and shading work in real life. It's a fine workflow that makes sense for any possible style in any conceivable level of "realism", and if you happen to need another texture for some special effect like Transformers Devastation's Wakame Shader then there's nothing stopping you from altering the shaders. It's a starting point that you can deviate from at any time, just be sure you know how to replicate your altered shaders if you need to switch between programs.
>>591142kek I'll never understand why some people consider it to be just a "buzzword" or a fad when it's currently the standard way of doing things.. its like if a modeler was saying he doesn't believe in supporting edge loops, or a compositor not interested in AOVs/render passes.. it's just part or the workflowanyway, great post anon, you absolutely get it
>>591160It's just the name that's a buzzword, it's renaming old technologies to make it seem hip and fresh and modern when it later more commonly replaced the old standard of diffuse + specular in video games.It's got that PR stink to it so companies can boast their game's graphics are realistic and life-like because of their "physically-based rendering" which carries a lot of implications and assumptions.
>>591142>AO just controls how much or how little global lighting appears on the model.wrong.AO controls the amount of indirect lightning on a model only.
>>591166>global lighting>indirect lighting>global illumination>GI
>>591169what did you mean by this
>>591170doesnt >>591166 seem to be arguing over two things that are the same?
>>591173no, global illumination in realtime CG has two parts, direct lightning and indirect lightning. AO is only multiplied by the indirect which then gets added to the directyour end result being>Ci = vec4(sumDirect + sumIndirect, alphaM);
>>591174oh, alright then, thanks
>>591174Oh okay, Global Illumination is all of the lighting together. The ambient / indirect level is just one half, I got you.
>>591176you dont really use the term Global Illumination in realtime CG
>>591178Well you do. You're usually lying when you do. And you say things like how AO helps approximate GI (though AO is really shit at it).