[Bf-viewport] Preliminary slides

[Daniel Stokes]

I do not feel that deferred shading is a good fit for the viewport, mostly
for the same reasons that Antony pointed out already. Something using a
light buffer (inferred lighting/deferred lighting/light prepass) or
per-pixel linked-list lighting would likely work better. Per-pixel
linked-lists is basically an optimization on forward rendering, so it would
be very compatible with the way things work already, but unfortunately it
requires (or is at least made a lot simpler by) computer shaders. This
would make the feature only available to users with OpenGL 4+ hardware.

As a long term goal, I would love to see a user be able to set up their own
deferred rendering if they wanted to do so. In general I would like
complete control of the render pipeline. This would require some revamping
of the composting nodes by giving them some of the viewport/GLSL love.

Regards,
Daniel

On Tue, Jun 9, 2015 at 2:53 AM, Paul Geraskin <paulgeraskin at gmail.com>
wrote:

> Thanks for the answer. The forces be with you. [?]
>
> On Tue, Jun 9, 2015 at 12:46 PM, Antony Riakiotakis <kalast at gmail.com>
> wrote:
>
>> Closures are basically the same as in OSL, yes. Think of it as the way
>> or function the surface interacts with light given a few parameters
>> that will be controllable from a node tree or shader source. Basically
>> it's the same idea as Cycles shaders. Probably "shader" is a better
>> term here, alas it's used as "GLSL source" as well and it makes things
>> confusing so I preferred "closure" in this context.
>>
>> While it's self evident that we would not like to be stuck in a circle
>> of unraditude and Deferred Shading == rad therefore blender has to
>> have it, I would not like to maintain a "I want the same toy little
>> John has" mode in this list, especially when John is a camel (ie Game
>> Engine) and blender is a monkey (ie DCC program). There are many rad
>> things in computer graphics so it would be good to focus on things
>> that will actually help with content creation, movies and game asset
>> preview. I would rather hear people say "I want deferred shading
>> because my work <link> apparently needs many lights and a deferred
>> engine would help".
>>
>> Deferred shading looks interesting because it decouples lighting from
>> shading, but it comes with a big memory cost too and it also needs
>> extra resolve passes to deal with multisampling. Personally I have it
>> on my radar and I think it looks really interesting. We'll need both
>> even if we use it, since transparent objects need forward shading
>> anyway, so I expect we can do tests between the two anyway. The thing
>> is to also make a system that will be easy to extend and maintain. Is
>> deferred shading such a system? Maybe, I'd love to hear from people
>> who have worked on such a thing even. And do people really use too
>> many lights in 3D scenes? In some cases maybe, but are they enough to
>> seriously consider basing the whole blender viewport architecture on
>> it? Also deferred shading can be -more- expensive with directional
>> lights such as suns. It only helps with bounded point lights such as
>> spheres which means that we will have to change how point lights
>> interact with the scene slightly. Not everything is roses here.
>>
>> Instances is a no brainer, we will support instances wherever we can,
>> particles, duplis and whatnot.
>>
>> Custom filters are not a priority but the initial idea for viewport
>> compositing was to also allow custom node trees. It just needs very
>> careful buffer management - most GPU techniques generally operate in
>> half or quarter resolution or so and it would be nice to make this
>> possible somehow in our system. But as I said not a priority now, at
>> least from me.
>>
>> New viewport will have shader based <everything>. That should allow
>> better edges too, and we also hope, transparency as well.
>> _______________________________________________
>> Bf-viewport mailing list
>> Bf-viewport at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-viewport
>>
>
>
>
> --
> Hello World!
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20150609/0631c281/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 96 bytes
Desc: not available
Url : http://lists.blender.org/pipermail/bf-viewport/attachments/20150609/0631c281/attachment.gif