Principled v2 BSDF #99447
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
63 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#99447
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This task is to track the work on the overhaul of the Principled BSDF node.
Feedback should be posted on the Principled v2 devtalk thread.
Planning
Breaking Changes (4.0 Bcon1)
5f9b518)8367167626)Polishing (4.0 Bcon2)
5e67e44)Further
Background
Important note
This is an ongoing project, and nothing is 100% certain yet. Additional components/options might be added, existing components/options might be removed and the behavior of existing options might change.
Also, Principled v2 is just a placeholder name until someone comes up with something better.
Goal of this project
The point of the Principled BSDF is to present a unified BSDF node that implements all commonly used shader elements, so that a wide range of materials can be created by simply adjusting its inputs. Further, it should be physically based, but allow for artistic control when needed, and should have intuitive and artist-friendly parameters.
While the current Principled BSDF fulfills this goal, there are some issues with it:
Many of these issues have been addressed by research in the last few years, so it makes sense to revisit this topic and rework the Principled BSDF to include these improvements.
Additionally, there have been new developments in the shading research world that simply aren't part of the Principled BSDF yet.
An additional goal is to have good compatibility to what other renderers are doing - in general, it looks like the entire industry is currently converging on a "default shader" with certain components, and it would be great if Cycles' new all-in-one node is compatible with what e.g. MaterialX, glTF, USD, OSL, other renderers and/or game engines are using so that assets can be easily transferred.
For compatibility reasons, the "old" Principled BSDF will also be preserved in its current form, at least for now.
Solutions to the issues listed above
mix(F_0, F_90, (1-cosI)^(1/f))rather thanmix(F_0, 1.0, (1-cosI)^5)) or the artist-friendly remapping [ https:*jcgt.org/published/0003/04/03/paper.pdf | proposed here .Components of the new Principled BSDF
Things that need to be fixed
Things that could be added
Note: These are just some ideas, it's entirely possible that none of them make it!
Additional notes
https://wiki.blender.org/wiki/User:Lukasstockner97/Principled_v2
Changed status from 'Needs Triage' to: 'Confirmed'
Added subscriber: @LukasStockner
Added subscriber: @Dangry
Added subscriber: @TheRedWaxPolice
Added subscriber: @rjg
Added subscriber: @scopelma
Added subscriber: @Patrick-Huang
Added subscriber: @fclem
I think we should discuss how we could implement the specular workflow (i.e: EEVEE's Specular BSDF node) into this v2? This would remove the need for a dedicated node that isn't even be supported by Cycles.
To my knowledge, it is just a matter of exposing the F0 specular color directly. Some renderers do energy conservation and subtract the F0 from the albedo but other don't. I don't know if there is an industry standard way of doing this.
Moreover, specular color below a certain threshold might be consider shadowing and just fade the whole reflective layer.
Note that both of the aforementioned effects (energy conservation and specular shadowing) are not modeled by the current EEVEE's Specular BSDF node implementation.
Added subscriber: @Alaska
Added subscriber: @blendersamsonov
Added subscriber: @JulienDuroure
Hello,
I am currently working on adding some glTF extension to importer/exporter.
With current Principled BSDF, sheen and specular models are not 100% compatible between Blender and glTF.
I didn't (yet) read in details what are your plan for Principled v2, but I hope it will be easier to convert from and to glTF.
Here are link to glTF implementation:
https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_materials_sheen/README.md
https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_materials_specular/README.md
Added subscriber: @PascalSchon
Added subscriber: @JanErik
Added subscriber: @thomasmcs
Added subscriber: @Roggii-4
Added subscriber: @makizar
Added subscriber: @Yacine-Teach
Added subscriber: @lsscpp
Added subscriber: @s12a
Added subscriber: @EAW
Added subscriber: @zanqdo
Added subscriber: @dabuxian
Added subscriber: @donmccurdy
Added subscriber: @KenzieMac130
Added subscriber: @AndyCuccaro
Added subscriber: @VDC
Added subscriber: @Eary
Added subscriber: @proog128
This is a great initiative! Since glTF and the importer/exporter are explicitly mentioned here, I'd like to share a couple of insights into trade-offs we made when defining the glTF "PBR Next" material extensions and mention a few details that might be easy to miss in the long discussion threads in glTF pull requests. It would be great if glTF and Blender are aligned well, a huge win for the open ecosystem. I hope this post useful, my appologies if I am just repeating stuff you already know. If this is not the right place for this post, let me know where to put it instead and I will move it there.
glTF PBR Extensions
Dielectric Fresnel and Specular/Specular Color
The dielectric specular defined in KHR_materials_specular adds a specular color parameter that is compatible to traditional spec-gloss workflows (in particular the now deprecated KHR_materials_pbrSpecularGlossiness). In case Schlick Fresnel is used, it boils down to computing f0 and f90 as follows:
And the base layer (diffuse) weight:
specularColoris a color,speculara scalar weight.The three important bits are:
max_value(c), i.e., the maximum of the RGB colors, because that prevents color shifts due to the1 - xterm. Also, it is required to be compatible to the old KHR_materials_pbrSpecularGlossiness.f0_from_ior(ior) * specularColorterm (not includingspecular). This is required to be (easily) compatible to the Disney BRDFspecularparameter. Disneyspeculargreater than 0.5 maps to glTFspecularColorgreater than 1.0. To ensure energy conservation, the clamp is needed.Although all examples in the glTF specification use Schlick Fresnel, it is designed in such a way that it also allows to use the accurate Fresnel equations. This requires the remapping that is already present in the Blender Principled V1 shader. Main reason for using the correct Fresnel equations in case of dielectric is the high error when the IOR approaches 1, which often happens with nested dielectrics when traveling through a volume boundary with similar IORs on each side.
The design consideration that underlies the Fresnel behavior in glTF is the following: by default, the material is "physically plausible", but optionally artistic tweaks are possible. In the default configuration,
IOR = 1.5,specular = 1andspecularColor = (1,1,1). The preferred option to modify reflection/refraction behavior should always be theIORparameter. TheIORparameter of KHR_materials_ior affects both refraction and reflection simultaneously, hence it's physically-plausible. This should be enough for most use-cases. Only in those rare cases where more control is needed,specularandspecularColorfrom KHR_materials_specular should be considered. Typical cases are:IORparameter is not texturable.specularColor, on the other hand, is texturable, but only affects reflection.IOR = 0or a reasonably high value forIOR. This includes measured materials, for example AxF. Moreover, there are cases in which the material model is just not expressive enough, and KHR_materials_specular is kind of a "backdoor" to make up for missing effects (e.g., complex car paints or fabrics).specular(specular reflection weight) andspecularColor(specular refractive index).specularColorin range (0,0,0) to (2,2,2).A final note regarding comaptiblity of KHR_materials_specular to Principled V1: Principled
SpecularandSpecular Tintcan be converted to KHR_materials_specular without loss, as long as the original configuration is energy conserving. This is not always the case due to the normalization with luminance in Principled V1, which may result in Fresnel values above 1. @JulienDuroure implemented this conversion in the glTF Blender Importer/Exporter. The conversion is described [here]]. The conversion is based on a survey of Fresnel models in common materials I did some time ago, see [https:*docs.google.com/document/d/1SvXWa6XGnFgsRXa1z4xw6QR1_jMmNSUTdRAmalCgoeI/edit?usp=sharing | here.Metallic Fresnel
There were some discussions about whether to include a metallic "edge" color (f82/f90 color) in glTF or not. So far it's not available and also not on the roadmap. It was discussed whether the generalized Schlick model with f0 and f90 color is accurate enough (probably yes), if Gulbrandsen's artistic-friendly metallic Fresnel is a better alternative (no, for the reasons Naty Hoffman described [here]]), and if we can do better (most likely, see Adobe's [https:*substance3d.adobe.com/documentation/s3d/files/225969599/225969601/1/1647019577092/Adobe+Standard+Material+-+Technical+Documentation.pdf | Novel aspects of the Adobe Standard Material).
Iridescence
The iridenscence extensions [KHR_materials_iridescence]] is almost ready. It is based on Belcour and Barla's [https:*belcour.github.io/blog/research/publication/2017/05/01/brdf-thin-film.html | Practical Extension to Microfacet Theory for the Modeling of Varying Iridescence. Since this model requires a complex IOR for the base, @PascalSchon came up with a few clever tricks to integrate it into glTF. This is described in the extension and as part of the code in the glTF sample viewer. It might be a good solution for Principled V2.
Volumes and Nested dielectrics
KHR_materials_volume allows to toggle between thin-walled materials (the default) and volume boundaries. The latter enables refraction and nested dielectrics. However, there is no priority in glTF yet. Some renderers are able to determine the priority automatically for common use-cases, but to my knowledge there is no fully automatic solution that works in all cases. Therefore, the missing priority could be seen as a shortcoming of glTF that may have to be addressed sooner or later.
One note regarding the
thicknesstexture in glTF: It's only purpose is to provide the (precomputed) thickness of an object for renderes that are not able to compute it at run-time. Which typically means all rasterizers. The idea is that by providing a correct thickness map for the rasterizer, it will render an image with refraction and attenuation that looks consistent to the rendering of a ray tracer. The ray tracer does not need the thickness map, it will simply ignore it and take the distances from ray travelling.Thin-Walled
Thin-walled materials are the default in glTF. Thin-walled disables volumetric refraction, attenuation and subsurface scattering. Nevertheless, the roughness has still an effect on the transmission lobe, mimicing refraction through uncorrelated microfacets on either side of the surface. This is detailed in KHR_materials_transmission.
Diffuse Transmission
Diffuse transmission is currently under active discussion. PR#1825 shows the current state. In essence, the implementation is straight-forward, but there is lots of debate whether or not it is useful, under which circumstances (thin or volumetric), and whether or not to include a separate diffuse transmission color parameter. (Without separate diffuse transmission color, the diffuse transmission BSDF would be multiplied by the base color).
In case of thin-walled, diffuse transmission is intended to be used for leaves, paper, etc. A separate color parameter allows to independently change the color for reflection and transmission. In the glTF PBR TSG we believe that although probably a niche feature, it is easy to have and adds some expressibility that could be nice for plants. If you know good use-cases for such a color parameter or have example scenes, please share it.
In case of volumetric, diffuse transmission is the gateway to subsurface-scattering. In fact, it is compatible to the Blender Principled v1 SSS implementation, which uses a white diffuse transmission when entering the surface. This is another reason for having a separate diffuse transmission color parameter. In order to be compatible to Blender Principled v1, diffuse transmission color has to be set to white.
In both cases, an alternative to an explicit diffuse transmission lobe would be to use a rough glossy transmission lobe. This has two main disadvantages:
SSS
Random-walk SSS is easy to implement in a path tracer, but not for rasterizers. The challenge is to use a heuristic to find out which approximation to use for a certain parameterization. There are mainly two cases: clear volumes and dense volumes. The problem is that it depends on volume parameters and object geometry.
For this reason glTF provides two ways of enabling volumetric effects:
Both BTDFs are mixed according to a weight, which means it's not a binary decision. The idea is that the mixed BTDF defines the scattering behavior when entering or leaving the volume beneath the surface, and the scattering inside the volume is then defined separately by attenuation/scattering coefficients and phase function.
Unfortunately, the choice for microfacet or diffuse transmission (clear or dense volume) is a user choice, so it might be suboptimal for a renderers heuristic. The parameterization of dense SSS in combination with a microfacet BTDF is still possible, and probably also required in some cases. Ideally, a rasterizer can detect such cases and switch to dense SSS, but it's hard to design a heuristic that works in all cases.
A path tracer doesn't care about this difference, it just uses the one or the other BTDF to enter the medium.
Regarding "white edges":
There is an early draft for a subsurface scattering extension to glTF that describes the reasoning in more detail, see PR#1928.
Texturable vs. non-texturable parameters
The volume parameters are not texturable in glTF: IOR, attenuation coefficient, scattering coefficient. This ensures that light transport is symmetric, making it possible to implement the material in a bidirectional path tracer.
A side effect of this is that these parameters are only of limited use if the material is thin-walled. In fact, attenuation and scattering coefficients have no effect at all. IOR is still taken into account, but if users want to texture the index of refraction, they have to fall back to
specularColor, which is a multiplier to the f0 color as described before.MaterialX and MDL
There are implementations of glTF in [MDL]] and [https:*github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/gltf_pbr.mtlx | MaterialX. Both are neither feature complete nor perfectly spec-conformant, as they have to deal with the limitations of the respective material language. Especially KHR_materials_specular and KHR_materials_iridescence are tricky to get correct in all details in high-level material languages.
Added subscriber: @MarvinW
Added subscriber: @Steve-Hanff
Added subscriber: @emackey
Added subscriber: @mcamen
Added subscriber: @renderart
I share this here too (I apologize) because I consider it to be something important, even so the next tests I will publish on Devtalk. If I have to remove this from here, please let me know.
Hello, I have loved this development, thank you very much I am happy.
https://docs.unrealengine.com/5.0/Images/designing-visuals-rendering-and-graphics/materials/material-editor-user-guide/interface/material-editor-ui-full.png
I haven't tried much the new system yet, but the first thing I noticed is:
In the link I shared there are 3 initially important nodes (Specular, Base color and Roughness) to add these 3 important textures, How could I use these textures (Specular) in the new system? Do I have to use a Mix of the Roughness and Specular Textures to connect them to the new Roughness?. I have that concern.
I'm going to try more on other engines to make comparisons. Thanks for: Energy conservation, Sheen, Sheen roughness, Metallic Edge, Metallic Falloff... They are amazing
Added subscriber: @geocentric_wage
Added subscriber: @Christophe-Hery
Thanks for all the input so far, especially the fantastic comment from @proog128!
From the discussion here and on Devtalk, it seems that the most interesting and tricky point is the Fresnel model used.
As far as I can tell, the model used by
KHR_materials_specularshould indeed cover most use cases - it gives people their specular slider from Principled v1 back (though it needs a multiply by 2), it gives tint control over highlights, it gives compatibility with specular/glossy (by setting IOR to zero, so that the base F0 is 1.0 and the tint input effectively becomes an F0 input) and can be integrated with the energy conservation logic. And by simply not touching the non-physical controls, you keep the realistic model.Answering specific comments:
As mentioned above, the "diffuse color + F0 color + roughness" input should be representable when we have the
KHR_materials_specular-style controls by connecting diffuse to the Base Color input, F0 to the Specular Tint input and setting IOR=0 and metallic=0. The energy conservation is indeed a good point - if this is an issue, we could disable it for IOR==0 (since that only makes sense for this one particular case anyways).Both will be compatible, as far as I can tell. Sheen is based on the same model, Principled v2 just needs the color input which is planned. For Specular - see the discussion above, I think it makes sense to add those options.
This post is definitely useful here!
Some quick replies to your sections (I'll go into more detail later):
I guess that specular input controls the strength of the highlight? If yes, that's covered by the Fresnel topic above, there will be an input for this.
I've just pushed an update that replaces the generalized Schlick Fresnel with the Adobe F82 model.
I'm really happy with the results - I've built a script to fit base and edge color values to real-world data from https://refractiveindex.info/ (in the hope that people will stop picking three random wavelengths from the graphs there and using them as RGB values) and the F82 model manages to reproduce some metals much better than the basic Schlick model. Trying to fit the generalized model for comparison didn't really work since it kept putting the edge color to 1 in order to reproduce the grazing incidence response, and when restricing the fit range to 0-80° it also gave weird solutions.
Here's the script and a comparison between the best fit to Nickel with and without the edge color parameter (plot is reflectivity in sRGB w.r.t. cosI, dots are ground truth from measurement data, line is the fitted model):
metalfit.py
And here's the obligatory table with real metals and their fitted parameters (for linear sRGB), based on measurements from Johnson and Christy:
Added subscriber: @moisessalvador
What if I want my own subsurface setup with principled's specular setup? One aspect that is also true of Principled v1 is that the specular/metallic/roughness/fresnel layer is complex enough that it cannot be exactly replicated with separate nodes by an user, which is important in case users want to use their own transmission/diffuse component, as it's the case with custom multilayer subsurface approaches, but with the much better approach to specular that principled offers. It would be nice if that specular layer was its own node that takes the transmission nodetree bsdf as input so the user doesn't have to worry about the mixing math. Something like this:
The main difference being that this shader doesn't pick up Base Color for tinting the specular or metal, that's up to the user
Added subscriber: @MirceaKitsune
Added subscriber: @AlexeyAdamitsky
Removed subscriber: @moisessalvador
@moisessalvador
Feedback should ideally go in the feeback thread. https://devtalk.blender.org/t/principled-v2-feedback-discussion-thread/24997/
However I just wanted to comment that Lukas appears to already be considering something like this.
Source: https://wiki.blender.org/wiki/User:Lukasstockner97/Principled_v2
Added subscriber: @moisessalvador
Removed subscriber: @moisessalvador
Yes sir, it is for easy control of the Highlight (BW Texture). Thanks for everything
Added subscriber: @ktdfly
Added subscriber: @GeorgiaPacific
Added subscriber: @Max-Knol
Added subscriber: @strangerman
Added subscriber: @baybaypras
Added subscriber: @Yuro
Removed subscriber: @Yacine-Teach
Added subscriber: @htuncay-4
Added subscriber: @LifeLight
Added subscriber: @johannes.wilde
Added subscriber: @Emi_Martinez
Added subscriber: @Zeirus
Added subscriber: @JoniMercado
Added subscriber: @costa
Added subscriber: @baoyu
I just want to make sure this clearcoat BUG will be fixed in V2?
https://developer.blender.org/T99087
Added subscriber: @Lt-Knb
Added subscriber: @RedMser
New version of the branch is finally up, including a merge of the latest master changes.
I've also added initial support for thin film iridescence - only on dielectric specular and transmission yet, not on metals.
Implementation is based on https://belcour.github.io/blog/research/publication/2017/05/01/brdf-thin-film.html and should be compatible with glTF as far as the parameters go.
That should be fixed regardless of v2 ;) I'll have a look.
So excited watching your presentation at BCON22! Glad that the clearcoat BUG will be fixed!
Added subscriber: @ArmandoTello
Added subscriber: @liudeyuan
Added subscriber: @Sparazza
Added subscriber: @Austin-Berenyi
Added subscriber: @ReinhardK
Added subscriber: @Beinaido
Added subscriber: @ROBYER1
Just chiming in here that preview of KHR_materials_specular within Eevee when authoring shaders has been impossible due to the Principled v1 shader setup only really supporting Metallic/Roughness models rather than Specular Glossy workflows where we are required to use the gltf Material Output node. Are there any plans for Principled BSDF v2 to allow for editing and visualisation of these GLTF PBR material properties within Blender? Having the ability to view GLTF materials the way they view in any GLTF viewer/importer would make Blender the one-stop-shop for editing/importing/exporting GLTF PBR files with accurate materials which so far it has not been.
Hello Robert,
It seems you miss-understand the glTF Material Output node.
Specular Glossy (with glTF extension KHR_materials_pbrSpecularGlossiness) is now archived. This extension is not implemented at export, as glTF does recommand to not create new file with this extension.
The recommandation is now to use pbrMetallicRoughness. This model is mostly compatible with Principled v1.
Some extensions of the pbrMetallicRoughness (specular, sheen) are not compatible with Principled v1. Here comes the glTF Material Output node, used to plugged glTF that are not compatible with Principled v1.
At import, we try to convert as soon as possible (but with loss) these data to plug into Principled v1. Original data (without conversion) are also plugged into the glTF Material Output node.
At export, you can should either to export original data, or converted data (that are converted back, again with some loss)
With Principled v2, the node will be compatible with specular & sheen glTF. That means that the glTF Material Output node will no more be needed for these extension. (but still for AO, IIRC)
To phrase that another way — Principled BSDF v2 will be compatible with
KHR_materials_specular(control of specular reflection, within a metal/rough workflow in glTF), but not compatible withKHR_materials_pbrSpecularGlossiness(outdated spec/gloss workflow in glTF).Lossless conversions from spec/gloss to metal/rough glTF materials are possible, too, if that's something anyone needs.
Thanks for the clarification, the main issue has been using Blender's Eevee Renderer viewport to edit and preview specular reflection of materials such as a shiny plastic as it wouldn't render those khr specular extensions with Principled BSDF v1 in the viewport. We could only see the export gltf material node properties working in external GLTF viewers like WebGl ones. Obviously for a workflow for metal surfaces this was fine but my work's 3D team are moving to using Blender primarily for GLTF model authoring where we are hitting these issues when we just want to edit the specular reflection glossiness of materials that are not requiring metallic properties.
Apologies if I sounded misinformed about the extensions, I'm purely focusing on KHR_materials_specular which is what is needed for more accurate reflective plastic materials in some scenarios (with no metal properties) as my 3D team pointed out to me.
Hello Lukas @LukasStockner ,
Do you have any plan to have it finished for 4.0 release, later this year?
This will be a breaking release, so the ideal release for having this merged into main.
@LukasStockner Can we use this oportunity to add an Ambient Occlussion input into the shader?
I know it's not "neccesary" if you use GI but:
1 - If the render settings are set to AO disabled (Eevee) or direct rendering (Cycles) then an AO input becomes very useful since it might be bringing prebaked AO or dynamically sampled AO from the Cycles Ambient Occlusion node.
2 - For completeness and compatibility with game export and baking (it is a feature in GLTF).
A practical example of an export setup to GLTF in current versions:
This setup exports correctly but the effect of the AO map is invisible in Blender's rendering.
In order to see the effect in Blender we have to multiply it to the Base Color input
Now we can see the effect of the AO in Blender but we have effectively BROKEN the GLTF export. We have to switch it back in order to export :/
Hi! Are there some updates or news to the principled v2? The branch can also not be downloaded anymore from blender experimental anymore :/
Greetings!
@LukasStockner I checked the Thin-Film Iridescence implemented in Principled v2 and found some differences to what is shown in the supplemental material of the original paper from Laurent Belcour and Pascal Barla: Supplemental Material
I also prepared a comparison rendering for the dielectric base material case, which can be found in the document on pages 6-7. You can find it in the attached documents. Additionally, I also did the same for the glTF Iridescence extension implementation in Three.js, which looks way closer to the reference (with a small adjustment of the IOR in the last column as the approximation fails for those large values, forcing me to use a smaller value).
@LukasStockner Any news on the timeline about it?
This change will impact glTF importer/exporter, and I need to plan it, depending on when this will land in main.
Hello @LukasStockner
(Also tagging @ThomasDinges as coordinator)
Seems the current status is behind the initial planning for 4.0
I'd like to have a updated status of each item: what will be in 4.0, what is postpone to 4.1 or later ?
Any changes here can have some (simple or heavy) impact on glTF I/O, and any news helping me to build a planning for it
Thanks :)
Yeah, the remaining items for BCon1 got delayed a bit, but the three big remaining pieces (subsurface, coat, emission) are merged now. The only missing part out of the breaking changes now is the Specular Tint handling, and that shouldn't take much longer. Sorry for the bad communication here.
Thanks for the (impressively thorough) info! I'll make sure to compare the results of the new revision.
This is probably way too late, sorry - but just for completeness: The approach shifted away from doing everything in one branch to working in smaller chunks and merging directly to main. So, for the latest version, just grab a regular nightly build :)
I have deleted the principled-v2 branch now that this functionality is in main. If there is anything still useful in that branch, it still exists in the
archive/blender-archiverepository.On the code side, this seems like a really simple change since Cycles already has a Oren-Nayar diffuse closure. Is there some other reason this has been delayed?
Glad to see Oren-Nayar appear here. An addition to the Principled BSDF would add a lot.
Just one quick sidenote. As a non-coder by looking at the code / patch you posted: This only means that Oren-Nayar diffuse is used if specular roughness is bigger than 0.0, right? This does not add a separate diffuse roughness, right?
In the code change I made, I am re-using roughness (which is used for Subsurface Scattering Entry Roughness, Specular Roughness, Metallic roughness, and Transmissive Roughness) to drive Oren-Nayer roughness. This was just an example and may not represent what will happen if this change gets implemented into Cycles.
Along with that, Oren-Nayer is only used if the roughness is > 0.0. This is because I based my code change on the code from the Diffuse BSDF node. I believe it's setup this way in the Diffuse BSDF because Oren-Nayer at roughness 0 renders the same as the normal Diffuse closure, however the normal diffuse closure renders faster, so why not switch to the faster closure when we can?
OK, thanks for clearing this up. Confirms everything I expected. :)
After doing a quick check, most popular renderers seem implement Oren-Nayer as a separate
Diffuse Roughnessslider.