<div dir="ltr"><p dir="ltr">Regarding the Unreal compatibility, I believe the main thing there is the PBR material node that I mentioned earlier. This would use the Disney principled BRDF, which is an easy to use BSDF model combining diffuse and glossy (typically GGX microfacet as implemented in Cycles). This is sometimes called the "PBR shader" in the realtime world.</p>
<p dir="ltr">This BSDF goes along with more advanced realtime light integration methods. There's multiple variations and extensions, but I believe the main things for creating game assets in Blender would be:</p>
<p dir="ltr">Direct light is computed more or less the same as it is now, looping over lights in the shader and using shadow maps for shadowing. Some kind of support for area lights could be added, though generally it's not really accurate, using tricks like blurring the shadow maps or increasing the glossy roughness to approximate them.</p>
<p dir="ltr">For indirect light the basic method is to use an environment map, with ambient occlusion for shadowing. To handle BSDFs with varying roughness, you make a kind "mipmap" of the environment map, with multiple levels from sharp to blurry. For a sharp BSDF you do a lookup in the sharp levels, for a diffuse or rough glossy you do a lookup in the blurry levels. For accurate results the filtering to create these levels should take into account the BSDF shape.</p>
<p dir="ltr">This is of course a rough approximation to full indirect light, but generally it works well enough for rendering individual assets. You can do more advanced things like light probes, VXGI, SSS, deferred lighting, but I won't go into these things.</p><p dir="ltr">A lot of infrastructure is already there. There is direct light and shadow map code (though it's coupled tightly to the old material system). We have a GGX microfacet BSDF in Cycles, screen space ambient occlusion in the viewport and code to render the world environment into a texture. But actually implementing it will require some tricky decisions about how things fit together and how to handle compatibility issues.</p>
<p dir="ltr">On Sun, Jan 10, 2016 at 5:23 PM, Alberto Torres <<a href="mailto:kungfoobar@gmail.com" target="_blank">kungfoobar@gmail.com</a>> wrote:<br>
> Ton,<br>
><br>
> I forgot to mention: yes, I'll publish it as open source as soon as<br>
> something works.<br>
><br>
> Cheers.<br>
><br>
> On Sun, Jan 10, 2016 at 12:16 PM, Ton Roosendaal <<a href="mailto:ton@blender.org" target="_blank">ton@blender.org</a>> wrote:<br>
>><br>
>> Hi Alberto,<br>
>><br>
>> It's very nice that people develop own engines to use with Blender. But if<br>
>> you don't have that as a public project, then it's not relevant here.<br>
>><br>
>> Here - on this mailing list - we target at working on Blender itself;<br>
>> which is a complete free/open source suite for artists to make compelling 3D<br>
>> content, including games or content for games. That is the main and first<br>
>> goal.<br>
>><br>
>> For people who want to use their own engines with Blender, they can help<br>
>> by making sure we use designs that work in general - specifically also for<br>
>> others who would develop external engines - and in a way our own goals can<br>
>> be achieved as well.<br>
>><br>
>> Within that context, feel welcome to share design proposals or code.<br>
>><br>
>> -Ton-<br>
>><br>
>> --------------------------------------------------------<br>
>> Ton Roosendaal - <a href="mailto:ton@blender.org" target="_blank">ton@blender.org</a> - <a href="http://www.blender.org" target="_blank">www.blender.org</a><br>
>> Chairman Blender Foundation - Producer Blender Institute<br>
>> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands<br>
>><br>
>><br>
>><br>
>> > On 9 Jan, 2016, at 19:21, Alberto Torres <<a href="mailto:kungfoobar@gmail.com" target="_blank">kungfoobar@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hello Ton, Brecht,<br>
>> ><br>
>> > I've used Blender GLSL shaders extensively and I've been planning in<br>
>> > making my own material architecture that can do many things the current GLSL<br>
>> > nodes can't. For now it's a side project but once done it will be useful on<br>
>> > my day work, too.<br>
>> ><br>
>> > So far I've "reverse engineered" the Material node, which does too many<br>
>> > things, and I finally understand in detail what it does (and its warts). A<br>
>> > great first step will be separating it in two stages: textures and lights.<br>
>> > (In fact my current shader trees have two types of Material nodes, shadeless<br>
>> > textures and textureless lighting). This would allow to add "stages" or<br>
>> > "buffered channels" for deferred rendering and other advanced rendering<br>
>> > techniques.<br>
>> ><br>
>> > Another step is having energy-conserving BRDF(s); I'm not sure whether<br>
>> > we have this already in the GLSL library but it should be clear to the user,<br>
>> > and set by default, to have FBR or FBR-like setups that are believable and<br>
>> > easy to tweak.<br>
>> ><br>
>> > Another important feature is having object-controlled parameters instead<br>
>> > of being per-material. To some degree, this is already possible for<br>
>> > numerical values (obcolor, UV, VCol), but there's no way to say "this object<br>
>> > will have material X but with textures A and B".<br>
>> ><br>
>> > Also, many existing features of Blender Render are technically feasible<br>
>> > in GLSL but are absent, such as having some other object for texture<br>
>> > coordinates, or "blend" textures (having to use a color ramp node instead).<br>
>> > Although in general this point is not important if we're planning an<br>
>> > overhaul.<br>
>> ><br>
>> > Bottom line, I'm planning in developing a stand-alone GLSL-based (or<br>
>> > SPIR-V or some abstraction for both) graphics engine which can be<br>
>> > potentially integrated into Blender both as render engine and as viewport<br>
>> > renderer.<br>
>> ><br>
>> > Cheers.<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > On Sat, Jan 9, 2016 at 2:49 PM, Ton Roosendaal <<a href="mailto:ton@blender.org" target="_blank">ton@blender.org</a>> wrote:<br>
>> > Hi Brecht,<br>
>> ><br>
>> > "Vision" is a big word, it can mean a lot. Currently there's nobody with<br>
>> > sufficient time to tackle the design, that's true. But such problems could<br>
>> > be solved by active recruitment and/or funding.<br>
>> ><br>
>> > What I miss is a mention of using the Unreal shader design. It was<br>
>> > suggested to align as close as possible to Unreal shaders for our 2.8<br>
>> > viewport, and use that to make viewport previz possible for Cycles or other<br>
>> > engines.<br>
>> ><br>
>> > I also miss active contributors giving feedback. It's not so much about<br>
>> > ideas or visions, I want to hear what people would suggest to work on,<br>
>> > however small it is.<br>
>> ><br>
>> > Alexander: there's a whole lot of open patches from you indeed. I think<br>
>> > we should more seriously look into that with high priority. For as long<br>
>> > things stay compatible (old files render same), we can be quite flexible<br>
>> > here. Provided you're around to maintain the issues a chance causes of<br>
>> > course.<br>
>> ><br>
>> > Laters,<br>
>> ><br>
>> > -Ton-<br>
>> ><br>
>> > --------------------------------------------------------<br>
>> > Ton Roosendaal - <a href="mailto:ton@blender.org" target="_blank">ton@blender.org</a> - <a href="http://www.blender.org" target="_blank">www.blender.org</a><br>
>> > Chairman Blender Foundation - Producer Blender Institute<br>
>> > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands<br>
>> ><br>
>> ><br>
>> ><br>
>> > > On 8 Jan, 2016, at 19:26, Brecht Van Lommel<br>
>> > > <<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>> wrote:<br>
>> > ><br>
>> > > Ok, so it seems that currently there isn't really a vision for a<br>
>> > > better realtime shading system. At least not from people reading the<br>
>> > > bf-viewport and bf-gamedev mailing lists.<br>
>> > ><br>
>> > > I'll review the patches that seem reasonable to me and don't really<br>
>> > > break compatibility, and those can go into Blender 2.77. For bigger<br>
>> > > changes someone else would need to take the responsibility.<br>
>> > ><br>
>> > > On Fri, Jan 8, 2016 at 1:48 PM, <<a href="mailto:a.romanov@blend4web.com" target="_blank">a.romanov@blend4web.com</a>> wrote:<br>
>> > >><br>
>> > >>> Adding these Cycles node features to BI seems all reasonable to me,<br>
>> > >>> particularly if the target would be to unify things more with Cycles<br>
>> > >>> material nodes instead of adding a completely new system<br>
>> > >>> specifically<br>
>> > >>> for the viewport.<br>
>> > >> It's very good, because we are primarily interested in such things.<br>
>> > >> And patches with support for BI and GLSL could even go into the 2.7<br>
>> > >> branch as it does not break backward compatibility, isn't it?<br>
>> > >><br>
>> > >>><br>
>> > >>> The issue with incremental changes is that you're also pretty much<br>
>> > >>> forced to incrementally break compatibility over many Blender<br>
>> > >>> versions, which is annoying for users. If it was mostly about<br>
>> > >>> parameters, just adding a new PBR material node would be a good<br>
>> > >>> solution for compatibility.<br>
>> > >>><br>
>> > >> Primarily we are interested in the stable branch of viewport<br>
>> > >> corresponding to current state of BI. So it could be 2.7 branch with<br>
>> > >> simplified material workflow, that could be done by adding a new PBR<br>
>> > >> material node.<br>
>> > >><br>
>> > >>> But there's issues with the way lights and materials interact, how<br>
>> > >>> transparency and ray tracing are wrong in subtle ways, distinctions<br>
>> > >>> between specular/reflection and diffuse/environment light, and more.<br>
>> > >>> In my experience keeping those exceptions while also adding a new<br>
>> > >>> PBR<br>
>> > >>> mode makes the code extremely complicated.<br>
>> > >>><br>
>> > >>> I don't want to go into too much detail here, but here's some old<br>
>> > >>> notes about design issues if you're interested:<br>
>> > >>><br>
>> > >>> <a href="http://wiki.blender.org/index.php/Dev:2.5/Source/ShadingSystem/Implementation" target="_blank">http://wiki.blender.org/index.php/Dev:2.5/Source/ShadingSystem/Implementation</a><br>
>> > >>> <a href="http://wiki.blender.org/index.php/User:Brecht/RenderIdeas" target="_blank">http://wiki.blender.org/index.php/User:Brecht/RenderIdeas</a><br>
>> > >>><br>
>> > >> Thanks for the tip. I need more deeply to learn.<br>
>> > >><br>
>> > >>> Anyway, maybe it is fine to incrementally break compatibility during<br>
>> > >>> the Blender 2.8 release cycle and users will just have to accept<br>
>> > >>> that?<br>
>> > >>> Whatever way we do this, it would still be good to have some kind of<br>
>> > >>> vision for what the end result should be.<br>
>> > >> In Blend4Web we keep deprecated features in 3-5 releases and our<br>
>> > >> users<br>
>> > >> have time to adjust. But we have releases per month.<br>
>> > >> It's important to understand exactly what is the aim of the first<br>
>> > >> release of 2.8. I'm also not sure I understand. But, from the<br>
>> > >> conversation it seems to me that BI should stay.<br>
>> > >><br>
>> > >><br>
>> > >> _______________________________________________<br>
>> > >> Bf-viewport mailing list<br>
>> > >> <a href="mailto:Bf-viewport@blender.org" target="_blank">Bf-viewport@blender.org</a><br>
>> > >> <a href="http://lists.blender.org/mailman/listinfo/bf-viewport" target="_blank">http://lists.blender.org/mailman/listinfo/bf-viewport</a><br>
>> > > _______________________________________________<br>
>> > > Bf-gamedev mailing list<br>
>> > > <a href="mailto:Bf-gamedev@blender.org" target="_blank">Bf-gamedev@blender.org</a><br>
>> > > <a href="http://lists.blender.org/mailman/listinfo/bf-gamedev" target="_blank">http://lists.blender.org/mailman/listinfo/bf-gamedev</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > Bf-gamedev mailing list<br>
>> > <a href="mailto:Bf-gamedev@blender.org" target="_blank">Bf-gamedev@blender.org</a><br>
>> > <a href="http://lists.blender.org/mailman/listinfo/bf-gamedev" target="_blank">http://lists.blender.org/mailman/listinfo/bf-gamedev</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > Bf-gamedev mailing list<br>
>> > <a href="mailto:Bf-gamedev@blender.org" target="_blank">Bf-gamedev@blender.org</a><br>
>> > <a href="http://lists.blender.org/mailman/listinfo/bf-gamedev" target="_blank">http://lists.blender.org/mailman/listinfo/bf-gamedev</a><br>
>><br>
>> _______________________________________________<br>
>> Bf-gamedev mailing list<br>
>> <a href="mailto:Bf-gamedev@blender.org" target="_blank">Bf-gamedev@blender.org</a><br>
>> <a href="http://lists.blender.org/mailman/listinfo/bf-gamedev" target="_blank">http://lists.blender.org/mailman/listinfo/bf-gamedev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Bf-gamedev mailing list<br>
> <a href="mailto:Bf-gamedev@blender.org" target="_blank">Bf-gamedev@blender.org</a><br>
> <a href="http://lists.blender.org/mailman/listinfo/bf-gamedev" target="_blank">http://lists.blender.org/mailman/listinfo/bf-gamedev</a><br>
></p>
</div>