[Bf-viewport] Blender 2.8 Viewport Development

Thu Sep 29 23:46:26 CEST 2016

I'm just wondering, how will freestyle fit into the new viewport/render? My
memory is a little foggy, but I think freestyle has (had?) some ties to BI.
With the new viewport and all, will it then become independent and usable
by all external renderers and the viewport itself?

On Thu, Sep 29, 2016 at 11:16 AM, Alexander Romanov <a.romanov at blend4web.com
> wrote:

> Hi all!
>
> I agree with Brecht and Clément about the lack of some features for NPR in
> Cycles. And I did some investigation about how to make BI external. Here is
> some notes about this https://wiki.blender.org/
> index.php/BI_temporary_removal .
>
> I stopped at the point where must decide what to do with the texture
> nodes. In my opinion they should be removed and shader nodes from cycles
> related to procedural textures should be ported to BI.
>
> On 29.09.2016 12:47, Clément FOUCAULT wrote:
>
> My input on the BI debate:
>
> I'm not in favor of throwing it away because like brecht said all
> functionnality can't be handled by realtime opengl.
>
> I propose to build an API for both viewport and Offline rendering
> (currently existing) in order to make BI external / optionnal to blender
> like Cycles. I don't know how much work it is though and this would break
> Backward compatibility.
> This way each renderer can specify it's own materials settings and
> rendering code for Opengl and Offline renders.
>
> Blender would only feed the renderers with datas and have a minimum set of
> shaders for editing tasks.
> The API would be flexible enough for external engine to render whatever it
> wants.
>
> Nothing would change about workflow modes and plates. Just the top quality
> renders (material mode?)  would be plugged to this API. The PBR side would
> be handled via this API so it has to cover a lot of needs.
>
> In the future BI could be revamped and use GPU power to raytrace things.
> But waiting this time it could be put aside as an optional part of blender
> not slowing dev time.
>
> I know this would require much more work than just upgrading the viewport
> but it may worth keeping things flexible that way.
>
>
> 2016-09-28 22:39 GMT+02:00 Brecht Van Lommel <brechtvanlommel at pandora.be>:
>
>> 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
>> _______________________________________________
>> Bf-viewport mailing list
>> Bf-viewport at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-viewport
>>
>
>
>
> _______________________________________________
> Bf-viewport mailing listBf-viewport at blender.orghttps://lists.blender.org/mailman/listinfo/bf-viewport
>
>
> --
> Alexander Romanov
>
> Developera.romanov at blend4web.com
>
> Blend4Web: Unleashing the Power of 3D Internethttps://www.blend4web.com
>
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender immediately.
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> https://lists.blender.org/mailman/listinfo/bf-viewport
>
>

-- 
khalibloo®
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20160929/017dba67/attachment-0001.htm 