[Bf-viewport] Preliminary slides

[Paul Geraskin]

@Daniel Stokes Deffered rendering is used in MarmosetTool Bag, Unreal,
Unity, Modo 901, Houdini.
This is modern and advanced.

Final user should not write his own deffered lighting. It's the same as to
force 3d artists to write in C language. This should do devs.

But you (dev) decide sure.


I hope you will design the viewport so that not to rewrite it again. :)

On Wed, Jun 10, 2015 at 9:41 AM, Daniel Stokes <kupomail at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> http://lists.blender.org/mailman/listinfo/bf-viewport
>
>


-- 
Hello World!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20150610/b99b8526/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/20150610/b99b8526/attachment.gif