<div dir="ltr">Hi, <div>speaking of materials override, I also have my little request: wouldn't it be cool if in material settings, along with "viewport color", "pass index", etc... there was also a "don't override" material checkbox? This would be cool for fast previews (Ambient occlusion) that could also have some material not overrided, like glasses or mirrors for example. It would be really useful for archiviz workflow<br>
<div class="gmail_extra">Thanks for reading this<br><br><div class="gmail_quote">2014-02-07 12:00 GMT+01:00 <span dir="ltr"><<a href="mailto:bf-cycles-request@blender.org" target="_blank">bf-cycles-request@blender.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Bf-cycles mailing list submissions to<br>
<a href="mailto:bf-cycles@blender.org" target="_blank">bf-cycles@blender.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:bf-cycles-request@blender.org" target="_blank">bf-cycles-request@blender.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:bf-cycles-owner@blender.org" target="_blank">bf-cycles-owner@blender.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Bf-cycles digest..."<br>
<br>Today's Topics:<br>
<br>
1. Re: Optimization project (Brecht Van Lommel)<br>
2. Re: Optimization project (David Fenner)<br>
<br><br>---------- Messaggio inoltrato ----------<br>From: Brecht Van Lommel <<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>><br>To: <a href="mailto:bf-cycles@blender.org" target="_blank">bf-cycles@blender.org</a><br>
Cc: <br>Date: Thu, 6 Feb 2014 15:35:50 +0100<br>Subject: Re: [Bf-cycles] Optimization project<br>On Wed, Feb 5, 2014 at 10:12 PM, David Fenner <<a href="mailto:d4vidfenner@gmail.com" target="_blank">d4vidfenner@gmail.com</a>> wrote:<br>
> The thing about transparency counted on material override is that, for<br>
> example, you wan't to make a custom light moving around the scene but only<br>
> to be composed later. You could make all a grey shader for the render layer<br>
> to render fast, but if you use leaves or any transparent surface (or in the<br>
> future displacement) you get wrong results and the little planes would start<br>
> to appear in the render, instead of leaves. If displacement is implemented,<br>
> the surfaces would also have wrong shape. So render layer override taking<br>
> into account original shader displacement and transparency (only if its<br>
> full, no need for partial transparency) would be ideal for custom render<br>
> passes, rim lights, animated lights, gunfire lights, you name it. I know<br>
> this maybe isn't about technical/code optimizations, but the ability to do<br>
> this could make render custom passes way faster, so it does optimize the<br>
> lighting workflow.<br>
> Currently, lighting or texturing in any compositor is also impossible<br>
> because normal and uv pass don't take transparency into account, therefore<br>
> in the same leave example you end up lighting planes instead of leaves. So<br>
> it isn't possible with a custom render layer in 3D and it's also impossible<br>
> with fake compositor lights based on normal / z / uv pass.<br>
<br>
Ok, I see what you're getting at, I was thinking too much of partial<br>
transparency, with binary transparency it's easier to do things in<br>
compositing. Making it possible to do lighting and texturing in the<br>
compositor is not something I've tried to optimize. We can do a lot<br>
better here, it's not really a workflow I've considered a priority.<br>
<br>
Making override materials more flexible in what they affect would be<br>
useful. There's also some other possibilities like giving access to<br>
the current render layer in shader nodes, so you could do this kind of<br>
thing in nodes setups, although that's not as convenient always. I'll<br>
think about this more, but don't really consider it as something to<br>
tackle as part of this performance project, just general features that<br>
can be added at some point.<br>
<br>
I did now add an alpha threshold per render layer which should make<br>
render passes work a bit better with fully transparent surfaces. Not<br>
quite what you asked for, but this had been on my To Do for a while.<br>
<a href="https://developer.blender.org/rBa41648c1dc58f" target="_blank">https://developer.blender.org/rBa41648c1dc58f</a><br>
<br>
Brecht.<br>
<br>
<br><br>---------- Messaggio inoltrato ----------<br>From: David Fenner <<a href="mailto:d4vidfenner@gmail.com" target="_blank">d4vidfenner@gmail.com</a>><br>To: <a href="mailto:bf-cycles@blender.org" target="_blank">bf-cycles@blender.org</a><br>
Cc: <br>Date: Thu, 6 Feb 2014 14:33:18 -0300<br>Subject: Re: [Bf-cycles] Optimization project<br><div dir="ltr"><i><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">I did now add an alpha threshold per render layer which should make</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">render passes work a bit better with fully transparent surfaces. Not</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">quite what you asked for, but this had been on my To Do for a while.</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<a href="https://developer.blender.org/rBa41648c1dc58f" style="font-family:arial,sans-serif;font-size:12.800000190734863px" target="_blank">https://developer.blender.org/rBa41648c1dc58f</a></i><div style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<div><i><img src="https://mail.google.com/mail/u/0/images/cleardot.gif"></i></div><div>Well this does solve a lot of shortcomings. Thanks.</div>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-06 Brecht Van Lommel <span dir="ltr"><<a href="mailto:brechtvanlommel@pandora.be" target="_blank">brechtvanlommel@pandora.be</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Wed, Feb 5, 2014 at 10:12 PM, David Fenner <<a href="mailto:d4vidfenner@gmail.com" target="_blank">d4vidfenner@gmail.com</a>> wrote:<br>
> The thing about transparency counted on material override is that, for<br>
> example, you wan't to make a custom light moving around the scene but only<br>
> to be composed later. You could make all a grey shader for the render layer<br>
> to render fast, but if you use leaves or any transparent surface (or in the<br>
> future displacement) you get wrong results and the little planes would start<br>
> to appear in the render, instead of leaves. If displacement is implemented,<br>
> the surfaces would also have wrong shape. So render layer override taking<br>
> into account original shader displacement and transparency (only if its<br>
> full, no need for partial transparency) would be ideal for custom render<br>
> passes, rim lights, animated lights, gunfire lights, you name it. I know<br>
> this maybe isn't about technical/code optimizations, but the ability to do<br>
> this could make render custom passes way faster, so it does optimize the<br>
> lighting workflow.<br>
> Currently, lighting or texturing in any compositor is also impossible<br>
> because normal and uv pass don't take transparency into account, therefore<br>
> in the same leave example you end up lighting planes instead of leaves. So<br>
> it isn't possible with a custom render layer in 3D and it's also impossible<br>
> with fake compositor lights based on normal / z / uv pass.<br>
<br>
</div>Ok, I see what you're getting at, I was thinking too much of partial<br>
transparency, with binary transparency it's easier to do things in<br>
compositing. Making it possible to do lighting and texturing in the<br>
compositor is not something I've tried to optimize. We can do a lot<br>
better here, it's not really a workflow I've considered a priority.<br>
<br>
Making override materials more flexible in what they affect would be<br>
useful. There's also some other possibilities like giving access to<br>
the current render layer in shader nodes, so you could do this kind of<br>
thing in nodes setups, although that's not as convenient always. I'll<br>
think about this more, but don't really consider it as something to<br>
tackle as part of this performance project, just general features that<br>
can be added at some point.<br>
<br>
I did now add an alpha threshold per render layer which should make<br>
render passes work a bit better with fully transparent surfaces. Not<br>
quite what you asked for, but this had been on my To Do for a while.<br>
<a href="https://developer.blender.org/rBa41648c1dc58f" target="_blank">https://developer.blender.org/rBa41648c1dc58f</a><br>
<div><div><br>
Brecht.<br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org" target="_blank">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
<br></blockquote></div><br></div></div></div>