![]() ![]() This was merged for the 3.2 release so we can have some user testing to see if some nodetree breaks. ![]() Note that only the forward shading pipeline is effectively implemented. There is a placeholder lighting model to be able to check how the BSDFs are mixed. We now have material nodetree support inside EEVEE-Next. Hi everyone, I would like to announce that a second milestone was reached. I will now focus on porting EEVEE-next first bits. Any regressions not stated in the commit message should be reported to the bug tracker. I did not provide any version patching for now but this can be done easily. You would have to tweak the default values for the average SSS coloring and then the input would have just make it closer to what cycles outputs. This makes more senses and is more compatible with what you would expect from cycles. What should have been from the beginning is to use the input as a mean radius. Alas, the scaling factor makes no sense at all as a parameter. Some of you might know that the SSS radius socket default values are used to pre-compute the SSS and that the socket input is only used as a scaling factor. When working on supporting the current SSS implementation, I stumbled accross what I can described as a bad choice from past self. I am still trying to find a way to keep the old behavior but it seems complicated. This change mimics the behavior of what EEVEE-next is expected to be. The only change in behavior for the original EEVEE implementation is that now any shader using a Shader-to-RGB node will not have SSR or SSS on any of their BSDF node. ![]() The engine can choose to implement it or not. The Shader-to-RGB node is also now supported and engine agnostic. This is also important for upscalling which I am aiming to support in EEVEE-next. The choice between fine bump or fast bump (2.80 blocky style) is now the responsibility of the engine and may become a performance option for EEVEE-next. I cleaned up some of the most tricky stuff we were doing to support displacement as bump mapping. Porting to the old codebase was also a test for that and allowed to polish the design, furthering the separation between the engine and the codegen. The strings are now shader stage agnostic, meaning they can be used inside vertex shaders (i.e: true procedural displacement support for EEVEE-next). Technically, the new codegen now only produces functions strings that are then used by the render engine however it wants. Moreover, this delegate the geometry support to the engine itself, making the support for other geometry types easier. Also this makes other engine implementation easier. But this became important with the recent decision to keep EEVEE-next and the original EEVEE implementation side by side. At first glance it does not look like a major issue for Blender because EEVEE is the only engine to use the codegen. Meaning there should be no special behavior depending on the render engine that runs it. Adapting the new codegen to the old EEVEE codebase was more work that I originaly anticipated.Ī core design shift was to make the codegen render engine agnostic. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |