<div dir="ltr">Hi again.<div><br></div><div><i><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>The normal and vector passes are already antialiased? For</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>transparency, it indeed only uses the normal/vector from the first</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>surface. Mixing the values based on transparency may be better if the</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>surface is entirely transparent, for partial transparency I'm not sure</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>if it's possible to do much useful here without deep compositing.</span></i><br></div><div><br></div><div>Sorry about the confusion, the normal pass is indeed antialiased. The ones that don't appear anti-aliased to me is the vector pass (sort of does it job anyway) and the object index pass ... </div>
<div><br></div><div><i><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>I don't quite understand what you are suggesting. If you somehow want</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>to preserve the transparency from the shader for override materials</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>then I guess that's possible but I'm not sure what that would achieve</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>exactly. </span></i><br></div><div><br></div><div>The thing about transparency counted on material override is that, for example, you wan't to make a custom light moving around the scene but only to be composed later. You could make all a grey shader for the render layer to render fast, but if you use leaves or any transparent surface (or in the future displacement) you get wrong results and the little planes would start to appear in the render, instead of leaves. If displacement is implemented, the surfaces would also have wrong shape. So render layer override taking into account original shader displacement and transparency (only if its full, no need for partial transparency) would be ideal for custom render passes, rim lights, animated lights, gunfire lights, you name it. I know this maybe isn't about technical/code optimizations, but the ability to do this could make render custom passes way faster, so it does optimize the lighting workflow. </div>
<div>Currently, lighting or texturing in any compositor is also impossible because normal and uv pass don't take transparency into account, therefore in the same leave example you end up lighting planes instead of leaves. So it isn't possible with a custom render layer in 3D and it's also impossible with fake compositor lights based on normal / z / uv pass. </div>
<div><br></div><div><i><span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>With more complex scenes divergence becomes a big problem on the GPU</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>where only part of the cores will actually be working. It's not clear</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>to me though that a separate render pass would be faster overall,</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>maybe, but again depends on what you are trying to do here exactly</span><br style="font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style="font-family:arial,sans-serif;font-size:12.800000190734863px">>which I don't understand.</span></i><br></div><div><i><span style="font-family:arial,sans-serif;font-size:12.800000190734863px"><br></span></i></div>
<div>Sorry if what I proposed was too confusing again. The idea was this: IF, for example, object IDs aren't anti-aliased, or the normal and uv pass don't count transparency in, what if a separate render with less samples could be used for this more advanced render passes (anti-aliased IDs, transparency in normal pass). The only thing needed for this would be to maintain transparency and in the future displacement of the shader, but the surface shader could be a simple diffuse, or even an AO shader, no lights or complex shaders to be computed, so advanced passes are taken away from the main render, which is already too complex for GPU's. You could render AO, normal pass (w/transparency), object IDs (anti-aliased), uv, vector, etc... on a separate pass at the end of the render... maybe using the same BVH? usually these passes need only a bit of samples. Sorry if I'm assuming too much here... maybe all these passes, even if anti-aliased or taking transparency into account, don't sum too much to complexity or performance... it's just an idea, in case it does sum too much or if taking transparency/aliasing into account for the mentioned passes it's too much for a render pass that works next to a complex render. </div>
<div><br></div><div>Thanks, David. </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-02-05 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">Hi David,<br>
<div class="im"><br>
On Wed, Feb 5, 2014 at 7:12 PM, David Fenner <<a href="mailto:d4vidfenner@gmail.com">d4vidfenner@gmail.com</a>> wrote:<br>
> 1) Perfect frame time estimation: Right now time estimation has an error<br>
> margin way too big to the point it is useless. For heavy scene rendering and<br>
> tight deadlines a better prediction is mandatory. A great way to do this<br>
> would be to make, in f12 rendering, a first pass of "progressive refine"<br>
> (let's say 20 samples per tile), then calculate the time based on samples<br>
> left, and then continue on each tile until full sampled, with no more<br>
> "progressive refine". The problem right now is that time estimation is done<br>
> by calculating the tiles being used only, but error comes when some tiles<br>
> take 10 secs on some others take 10 min. If we did a time estimation on all<br>
> the tiles based on 20 samples then there is no margin for error, since the<br>
> next 20 samples will take the same time on each tile, and so on. Having<br>
> perfect prediction (thanks to the nature of path tracing) is a blessing for<br>
> high end production.<br>
<br>
</div>Fair enough, the remaining time that was added was only a quick<br>
feature. It could be made more accurate.<br>
<div class="im"><br>
> 2) The glossy shader could have a button/ticket box to make it "only<br>
> direct". Basically this would make the glossy shader react only to direct<br>
> light and hdri. For many, many types of shaders, this specular-like usage of<br>
> the glossy shader is more than enough, and probably it would save a lot of<br>
> bounces. For example, I wanted to do only specular to the leaves (more than<br>
> enough, no reflection needed), but I couldn't without lowering all the<br>
> glossy samples, therefore killing the reflection in the river (the one<br>
> reflection that I did need).<br>
<br>
</div>Right, this has been on the To Do list, added to the optimization page<br>
as well now.<br>
<div class="im"><br>
> 3) Currently, hair particles seem to be the only way to distribute objects<br>
> through a surface in a procedural manner (like c4d cloner or 3dsmax<br>
> scatter). This is what I used for grass (a few modeled planes distributed,<br>
> was faster than hair and better looking), but it seemed that the more I<br>
> increased the quantity, the more memory was used. Aren't this supposed to be<br>
> instances? As far as I know, when you use and object instead of hair it is<br>
> only position, scale and rotation are considered, so I don't see why they<br>
> couldn't be instances.<br>
<br>
</div>With the particle system each particle/hair is an instances, but<br>
instances use memory too. If you're instancing an object with just a<br>
few polygons that's not going to save any memory. The memory usage of<br>
instances could be reduced, there's a note about this on the<br>
optimization page. However if each grass leaf is its own instance<br>
that's never going to be memory efficient. I don't know if that's what<br>
you're doing.<br>
<br>
It's better to instance patches of grass with each a patch a mesh<br>
containing many grass leaves. That has to be done manually at the<br>
moment, it would be a good if the particle system could do this<br>
automatically somehow. I'm not sure what the typical trick is to<br>
render lots of grass is in other renderers.<br>
<div class="im"><br>
> 4) Dealing with transparency for custom render passes (object ids, custom<br>
> light for compositing, extra character ghost, whatever) is currently very<br>
> very hard. Basically you can't get a grey geometry to make a custom light<br>
> pass without killing transparency settings (and in the future displacement)<br>
> with the material override. Could it be possible that renderlayer material<br>
> override respected the last transparency shader of the original material<br>
> tree? as well as the displacement? This way you could get custom passes but<br>
> keeping the shape/transparency of your render. Currently all sort of tricks<br>
> need to be done, like making a giant shader that has many transparency<br>
> shaders mixed by custom attributes like UV, vertex color, object ID, stuff<br>
> like that. Bad to set up and memory intensive.<br>
<br>
</div>Transparency is indeed a pain, the best solution to that would be deep<br>
compositing but that's not something that can be solved in Cycles,<br>
most of the work for that would be in the compositor.<br>
<br>
I don't quite understand what you are suggesting. If you somehow want<br>
to preserve the transparency from the shader for override materials<br>
then I guess that's possible but I'm not sure what that would achieve<br>
exactly. Probably we'd need to analyze what you're trying to do here<br>
in compositing, it seems a bit of a hack for a problem that may have a<br>
better solution. There's no way really to separate the transparent<br>
surface cleanly without deep compositing, the way the pass is computed<br>
can be tweaked but there's no great solution probably.<br>
<br>
But this is a bit out of scope, it's more about compositing workflow<br>
than performance.<br>
<div class="im"><br>
> 5) With the setting above, maybe it could be easier to do an extra render<br>
> pass for Normal and vector, like a separate, 30 sample render? This way some<br>
> complexity could be taken a way for final (heavy) scene render, by taking<br>
> out AO pass, normal, vector, mist, object id, etc. And make an override for<br>
> another, less complex and less sampled render that respects transparency and<br>
> displacement, that gives antialiased normal and vector, mist, AO, anti<br>
> aliased object id, etc. I know two pass isn't ideal, but is a very descent<br>
> workaround and could be part of the same render (just with a "AOV" stage).<br>
> On the other hand, GPU's really went down to their knees on this jungle<br>
> render... to the point that adding an AO pass was simple impossible. Having<br>
> it separate could ease a little the burden for GPU's that clearly don't do<br>
> as well as in simple scenes. (In fact, TITAN is usually about 3 to 5 times<br>
> faster than our 12 core xeon cpus, but on this jungle scene it was about 1.6<br>
> times faster only).<br>
<br>
</div>With more complex scenes divergence becomes a big problem on the GPU<br>
where only part of the cores will actually be working. It's not clear<br>
to me though that a separate render pass would be faster overall,<br>
maybe, but again depends on what you are trying to do here exactly<br>
which I don't understand.<br>
<div class="im"><br>
> 6) The mist pass has artifacts when transparency limit is hit. If you have<br>
> many leaves and a top of, for example, 7 transparency levels, if the limit<br>
> is hit in one leave this leave will be seen white on the mist pass.<br>
<br>
</div>This sounds like a bug.<br>
<div class="im"><br>
> 7) I think this is quite obvious, but I'll point it out anyway: Normal and<br>
> vector pass are a necessity for compositing but are currently useless (no<br>
> anti-aliasing, doesn't take transparency into account).<br>
<br>
</div>The normal and vector passes are already antialiased? For<br>
transparency, it indeed only uses the normal/vector from the first<br>
surface. Mixing the values based on transparency may be better if the<br>
surface is entirely transparent, for partial transparency I'm not sure<br>
if it's possible to do much useful here without deep compositing.<br>
<div class="HOEnZb"><div class="h5"><br>
Brecht.<br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">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>