[Bf-viewport] Viewport and shader system patches

[Brecht Van Lommel]

Hi Alexander,

I'd like understand the big picture here, how we want the material
system to evolve for 2.8 and where these changes fit. There's been
talk about evolving Blender Internal into a high quality realtime
rendering engine, and just adding more and more features to the
existing system doesn't necessarily help us end up with the best
design. The conclusion from such a discussion may be that it's fine to
commit the patches more or less as is, but I would still like to
understand everyone's ideas here.

I'm also including the bf-gamedev list.


We currently have Blender and Cycles material systems, and for the
game engine there are also single and multi texture material systems.
I think we all agree that the game engine single and multi texture
material system will be removed for 2.8, and that we should go for
GLSL, that's an easy decision.

Neither Blender nor Cycles materials are ideal for realtime rendering
now. The Blender system is based on emulating the Blender renderer
exactly, which is very complex and not efficient. The Blender renderer
is also not being actively developed. But its GLSL material system is
the most functional one we have right now, with support for lights,
shadows, etc, and Blend4Web is using it successfully.

The Cycles system has only basic GLSL support, no lights or shadows.
However I think that the decoupled shading system Cycles uses is also
the future for realtime rendering. When we think about PBR, deferred
rendering, global illumination, efficient layering by mixing
parameters, automated pipelines for baking, automated quality
degradation for different GPUs, etc, then I think it makes sense to
decouple shaders from lighting there as well. For such advanced
rendering algorithms GLSL shaders can't just be a black box, you need
them to integrate closely with the rest of the renderer.

Then there is the whole topic of NPR rendering, where I don't really
have a vision for how things should work. Ideally you want a lot of
freedom which a decoupled shading system doesn't really afford you,
but there's also only so much you can do in GLSL shaders even if you
give full access to information about lights.


It is possible to design a new material system from scratch, but it
seems to me there are not enough developers for this available, and
the transition would be quite painful for users. So perhaps we should
gradually improve the Blender and/or Cycles material systems for
realtime rendering.

There are a number of incremental changes that can be done, like
making Cycles nodes available for both renderers as done in these
patches. GLSL code can be shared here so code duplication is not a
major problem, but it does further complexify the Blender material
nodes by adding multiple ways to do the same thing. Maybe that's
acceptable if we know that it's temporary and things will be cleaned
up in the future.

Then there are changes involving lighting that are more difficult,
take for example the environment lighting. When thinking about this in
terms of PBR rendering, you typically want the environment texture to
affect both diffuse and glossy BSDFs, and you want some type of
shadowing to avoid things looking blown out, which is not done in
D810. The way environment lighting is implemented in the Blender
renderer is confusing and not quite correct as well, not quite
compatible with modern realtime PBR render techniques.

So what do we do there, try to match the Blender renderer anyway,
improve the Blender renderer and break compatibility, or use different
settings or methods for realtime and offline? These questions come up
when reviewing these kinds of patches, and so it would be good to have
some sort of policy or plan here.


Personally I think the right solution is to build a new realtime
lighting system using the Cycles shader nodes (which hopefully in the
future will include a PBR / Disney principled BSDF node). This can
then be gradually improved without breaking compatibility with the old
Blender material system, which then can be dropped entirely when the
replacement is good enough. But how high we can actually aim also
depends on the resources we have.

I can't work much on this myself since it conflicts with my work at
Solid Angle. Personally I also have no interest in figuring out how to
fit features into the old Blender material system design anymore, my
opinion on how things should fit together is already codified in the
Cycles design.


I'd love to hear where Blend4Web and others see things going, what
kind of plan or vision they have for the realtime material system.

Regards,
Brecht.


On Mon, Dec 28, 2015 at 3:17 PM, Alexander Romanov
<a.romanov at blend4web.com> wrote:
> Hi Blender coders! Especially Viewport and BGE coders)!
> I have accumulated several patches for viewport and for shader system which
> have cool abilities.
>
> You can see them on this page:
> http://wiki.blender.org/index.php/Dev:Doc/Projects/Blend4Web_proposals#Patches_under_Review
>
> And here is the copy for discussion:
> -------------------
> D909 Support of Cycles' Vector Transform node in the Blender Internal. This
> node is intended for conversions between different coordinate spaces.
> Particularly, it would be very useful to convert normals from the camera
> space (in which Blender works) to the world space. This would allow users to
> create various view-independent effects in the viewport and hence in
> Blend4Web too.
> -------------------
> D1414 Support "Image or Movie" and "Environment map" types of world texture.
> D1413 Support cube map textures in GLSL render.
> This two patches can be combined together.
> -------------------
> D1120 Support of Cycles' Normal Map node in the Blender Internal. As you can
> guess from its name, this node would give the possibility to use normal maps
> in the viewport, including tangent, object and world spaces. Currently,
> Blend4Web users are constrained to put normal maps inside extra Material
> nodes and link them via B4W_REPLACE nodes.
> -------------------
> D1542 "Do not tint cycled nodes" option for node trees.
> -------------------
> D923 Support of some Cycles' Geometry node functionality in the Blender
> Internal. Currently, the Geometry node lacks such important outputs as
> Incoming, Normal (in the world space), Tangent and others.
> -------------------
> D810 Support for Environment Lighting settings in the viewport. This would
> allow our users to see the same lighting in Blender that is seen in
> Blend4Web. For some reason, these settings currently only work in the
> Blender render.
> -------------------
> D846 Smooth Step node implementation would allow smooth transitions of
> values and colors. Currently, there is a B4W_SMOOTHSTEP node group in
> Blend4Web which consists of 9 math nodes. The Smooth Step node corresponds
> to the built-in GLSL function and would allow users to create faster
> shaders.
> -------------------
>
> I would like to discuss Viewport and BGE future plans on such improvements.
> I arranged the patches in order of importance and integration difficulty. So
> the first patch is the most recently checked and more preferable for me to
> work on.
>
> --
> Alexander Romanov (Blend4Web Team)
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> http://lists.blender.org/mailman/listinfo/bf-viewport
>