[Bf-viewport] Blender 2.8 Viewport Development

[Brecht Van Lommel]

On Wed, Sep 28, 2016 at 10:58 AM, Dalai Felinto <dfelinto at gmail.com> wrote:
>>  The relation between realtime Blender Internal and the PBR viewport is not clear to me.
>
> There is no real relation between them. The PBR realtime solution is
> aimed at Cycles and external game engines.
>
> That said, we are not simply making sure all the Blender Internal GLSL
> nodes look the same in viewport as they do in offline rendering. We
> will most likely have to resort to techniques used by PBR game engines
> - cubemaps, screen reflections, SSAO, ...).

The current Blender Internal GLSL only supports a small subset and
approximation of the offline renderer functionality. For it to become
a viewport renderer that can replace an offline renderer, I expect it
will need improvements. There's no procedural textures, texture nodes,
hair, halos, quad lights, GI, etc.

So would the viewport project then develop two separate realtime
renderers, and is there a plan for who will do that? Or would the
Blender Internal viewport be mostly left as is?

>From my point of view the underlying PBR shading and lighting system
is not fundamentally different than what you would want from an
improved Blender Internal viewport. It should be possible to combine
the best of both worlds, providing an easy to use uber material and
texture stack, and allowing e.g. NPR tricks that you can't do in
Cycles. It could share a lot of shader code at least?

>> It's not really obvious where tasks fit. We have screens which also corresponds to a specific workflow or "task", but it's not as fine grained. Multiple viewports in a screen could have different shading but not a different object mode. The easiest would be to say a task is a shading mode preset, but maybe there's ideas here to tie screens/modes/tools into it as well.
>
> A task is a shading mode preset (different options per plates and all
> that), also tied to a mode and in some cases tools (e.g., mesh
> widgets).
>
> I have to confirm this with Sergey, but I believe the way he is
> designing the "datagraph" we will be able to have different viewports
> working in different modes. On top of it, someone artists like to
> always work in maximized editor, so the idea of a Screen with
> pre-defined 'plates-presets' for a given workflow may be less relevant
> than allowing for quickly switch (or tweak) a 'plates-preset' from
> within a viewport. A user is not expected to "multi-task" anyways. But
> basically to go over different tasks back and forth during a given
> workflow.

A single object being in different modes is not feasible I think.
Being in edit mode and sculpt mode at the same time, or being in
different selection modes would be a synchronization nightmare. For
users it would probably be confusing to be in different modes in
different viewports as well.

I don't expect a user to be multi-tasking in that way. But I think the
idea of combining shading mode preset and object mode into a single
"task" concept somehow needs to be clarified or tweaked to work with
multiple viewports.

> This is also something to be tackled at the workflow and usability
> sprint in late November, since it involves the usability of Blender as
> a whole, not only the viewport.

Definitely.

>> * Alpha order handling seems a like it could be something that makes cleanly separating plates tricky, but I guess this a general problem in realtime rendering.
>
> I will leave this for Clément or Mike to reply. But I believe that
> engines like Unreal handles PBR, screen shaders (SSRD, SSAO, ...) and
> alpha with no problems.

I think all existing engines have alpha "problems" in that they're all
making approximations for performance reasons. If you want to draw an
object between semi-transparent surfaces from an earlier plate, that
will not be possible unless the buffers have some kind of depth.
Applying depth of field or motion blur on semi-transparent objects is
also problematic (same problem as we have in the compositor). SSAO,
SSRD, .. have limitations here too, as well as renders coming out of
Cycles.

And I think that's fine and part of the trade-offs to make things
realtime, but depending on the algorithm the plates might have to deal
with more than flat buffers.

Regards,
Brecht.

>
> Regards,
> Dalai
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
>
>
> 2016-09-27 18:10 GMT-03:00 Brecht Van Lommel <brechtvanlommel at pandora.be>:
>> Thanks for the write up! Great to see the ideas that have been
>> floating around confirmed in this document. There's lots of questions
>> I could ask about the specific implementations, but it's probably too
>> early for that. But a few general ones:
>>
>> * The relation between realtime Blender Internal and the PBR viewport
>> is not clear to me. Would the plan be to maintain the existing BI
>> shading/lighting system, and add a PBR system in addition, or would
>> they overlap, get merged or share code somehow?
>>
>> * It's not really obvious where tasks fit. We have screens which also
>> corresponds to a specific workflow or "task", but it's not as fine
>> grained. Multiple viewports in a screen could have different shading
>> but not a different object mode. The easiest would be to say a task is
>> a shading mode preset, but maybe there's ideas here to tie
>> screens/modes/tools into it as well.
>>
>> * Alpha order handling seems a like it could be something that makes
>> cleanly separating plates tricky, but I guess this a general problem
>> in realtime rendering. I'm not too familiar with the latest methods
>> though so perhaps there's algorithms that fit the plates model well.
>>
>>
>> On Tue, Sep 27, 2016 at 2:00 PM, Dalai Felinto <dfelinto at gmail.com> wrote:
>>> Dear all,
>>>
>>> For the past few days we had a Blender 2.8 viewport development
>>> workshop at the Blender Institute.
>>>
>>> We focused our discussions in the user experience, but deliverables
>>> were decised based on the expected progression of the code
>>> development. The implementation and usability (UI, ...) are still
>>> pending, but the big picture here presented is enough to structure the
>>> oncoming code architecture.
>>>
>>> The overall design was just posted on the development blog:
>>> https://code.blender.org/2016/09/blender-2-8-viewport-development/ ‎
>>>
>>> We welcome any comments and feedback you may have *BUT* please let's
>>> use the bf-viewport mailing list for that, just to keep it more
>>> focused.
>>>
>>> Apart from that we will soon announce an open-call for helping with
>>> the OpenGL immediate mode to modern OpenGL effort. That will be the
>>> easiest way for other developers to get involved with the viewport
>>> project.
>>>
>>> Best regards,
>>> Dalai
>>> --
>>> blendernetwork.org/dalai-felinto
>>> www.dalaifelinto.com
>>> _______________________________________________
>>> Bf-viewport mailing list
>>> Bf-viewport at blender.org
>>> https://lists.blender.org/mailman/listinfo/bf-viewport
>> _______________________________________________
>> Bf-viewport mailing list
>> Bf-viewport at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-viewport
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> https://lists.blender.org/mailman/listinfo/bf-viewport