<div dir="ltr"><div>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.<br><br></div><div>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.<br><br></div><div>Regards,<br></div><div>Daniel<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 2:53 AM, Paul Geraskin <span dir="ltr"><<a href="mailto:paulgeraskin@gmail.com" target="_blank">paulgeraskin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks for the answer. The forces be with you. <img src="cid:330@goomoji.gmail" goomoji="330" style="margin:0px 0.2ex;vertical-align:middle"></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 12:46 PM, Antony Riakiotakis <span dir="ltr"><<a href="mailto:kalast@gmail.com" target="_blank">kalast@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Closures are basically the same as in OSL, yes. Think of it as the way<br>
or function the surface interacts with light given a few parameters<br>
that will be controllable from a node tree or shader source. Basically<br>
it's the same idea as Cycles shaders. Probably "shader" is a better<br>
term here, alas it's used as "GLSL source" as well and it makes things<br>
confusing so I preferred "closure" in this context.<br>
<br>
While it's self evident that we would not like to be stuck in a circle<br>
of unraditude and Deferred Shading == rad therefore blender has to<br>
have it, I would not like to maintain a "I want the same toy little<br>
John has" mode in this list, especially when John is a camel (ie Game<br>
Engine) and blender is a monkey (ie DCC program). There are many rad<br>
things in computer graphics so it would be good to focus on things<br>
that will actually help with content creation, movies and game asset<br>
preview. I would rather hear people say "I want deferred shading<br>
because my work <link> apparently needs many lights and a deferred<br>
engine would help".<br>
<br>
Deferred shading looks interesting because it decouples lighting from<br>
shading, but it comes with a big memory cost too and it also needs<br>
extra resolve passes to deal with multisampling. Personally I have it<br>
on my radar and I think it looks really interesting. We'll need both<br>
even if we use it, since transparent objects need forward shading<br>
anyway, so I expect we can do tests between the two anyway. The thing<br>
is to also make a system that will be easy to extend and maintain. Is<br>
deferred shading such a system? Maybe, I'd love to hear from people<br>
who have worked on such a thing even. And do people really use too<br>
many lights in 3D scenes? In some cases maybe, but are they enough to<br>
seriously consider basing the whole blender viewport architecture on<br>
it? Also deferred shading can be -more- expensive with directional<br>
lights such as suns. It only helps with bounded point lights such as<br>
spheres which means that we will have to change how point lights<br>
interact with the scene slightly. Not everything is roses here.<br>
<br>
Instances is a no brainer, we will support instances wherever we can,<br>
particles, duplis and whatnot.<br>
<br>
Custom filters are not a priority but the initial idea for viewport<br>
compositing was to also allow custom node trees. It just needs very<br>
careful buffer management - most GPU techniques generally operate in<br>
half or quarter resolution or so and it would be nice to make this<br>
possible somehow in our system. But as I said not a priority now, at<br>
least from me.<br>
<br>
New viewport will have shader based <everything>. That should allow<br>
better edges too, and we also hope, transparency as well.<br>
<div><div>_______________________________________________<br>
Bf-viewport mailing list<br>
<a href="mailto:Bf-viewport@blender.org" target="_blank">Bf-viewport@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-viewport" target="_blank">http://lists.blender.org/mailman/listinfo/bf-viewport</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div>Hello World!<br></div>
</font></span></div>
<br>_______________________________________________<br>
Bf-viewport mailing list<br>
<a href="mailto:Bf-viewport@blender.org">Bf-viewport@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-viewport" target="_blank">http://lists.blender.org/mailman/listinfo/bf-viewport</a><br>
<br></blockquote></div><br></div>