[Bf-viewport] May the "Source" be with you

[hewi jupama]

?

________________________________
From: bf-viewport-bounces at blender.org <bf-viewport-bounces at blender.org> on behalf of Paul Geraskin <paulgeraskin at gmail.com>
Sent: 09 June 2015 09:53
To: bf-viewport at blender.org
Subject: Re: [Bf-viewport] Preliminary slides

Thanks for the answer. The forces be with you. [cid:330 at goomoji.gmail]

On Tue, Jun 9, 2015 at 12:46 PM, Antony Riakiotakis <kalast at gmail.com<mailto: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<mailto: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/606780c3/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 330.gif
Type: image/gif
Size: 96 bytes
Desc: 330.gif
Url : http://lists.blender.org/pipermail/bf-viewport/attachments/20150610/606780c3/attachment.gif