[Bf-viewport] Preliminary slides

[Paul Geraskin]

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