[Bf-cycles] A couple of questions...

[Thomas Volkmann]

Inlined answers....
 

> Sergey Sharybin <sergey.vfx at gmail.com> hat am 16. Juni 2016 um 09:57
> geschrieben:
> 
>  Hi,
>   
>  Inlined answers.
>   
>  On Thu, Jun 16, 2016 at 9:09 AM, Thomas Volkmann <lists at thomasvolkmann.com
> mailto:lists at thomasvolkmann.com > wrote:
>    > >    Hi,
> >     
> >    I'm using Blender on a shot for a bigger project right now, and while I'm
> > enjoying it a lot (never had a single crash so far and its not a lightweight
> > scene) there is some stuff that I either don't know how to do, might do
> > wrong or simply can't do because of the programs limitiations.
> >  >   
>  Wow, you sure you use Blender? ;) It crashes so often based on reports in our
> tracker :)
>   
>  It's also always interesting to know what Blender/Cycles is used for. Is your
> projection mentionable/showable?
> 

I'm doing a set-extension for swedens tv-christmas calendar (a 15min episode
every day during december). It's from the guys who did this movie
https://www.youtube.com/watch?v=3lFh-ZqFoS4 , and the show is going to be in a
similar style and setting. So loads of fun actually. I have a set that we
recreated with photogrammetry, and I need to extend it and add snow and ice.
Blenders sculpting functionality comes in quite handy when I try do deform the
dense meshes (to avoid repetition when c&p original set elements).

Actually I'm only doing it in Blender, because of the initial alembic-patch that
came out a couple of weeks ago. Just wanted to give it a try and now I'll stick
with Blender on that shot :)

 

>   
>    > >    So if you could please shed some light on a couple of questions...
> >    Here we go:
> >  >   
>  Here are some answers for you :)
>   
>    > >     
> >    1.:  Custom AOVs (Passes)?
> >    I need to create a couple of RGB masks. At the moment I create a new
> > renderlayer with an override rgb material (Obj-ID decides if R,G,B, or
> > black). Since I have a couple of objects, I end up with a lot of
> > renderlayers, which makes the rendering process longer. In Vray there is the
> > multimatte-element channel that you can use for that and in Arnold you can
> > freely setup your aovs (passes, channels, whatever it is called in different
> > software). Is there something like this in cycles that I haven't noticed
> > yet, or is the workflow I'm using atm the one to go for atm?
> >  >   
>  There is no such a thing in neither Blender in general nor in Cycles in
> particular. So for now your workflow seems as optimal as it could be in
> Blender.
>   
>  Not saying it's impossible to improve it by making passes more flexible :)
>   
>    > >     2.: Custom Attributes 
> >    As I understand it, cycles can already access some predefined attributes
> > on a per vertex level (?). But how about if I give custom attributes to
> > objects? E.g. if I give a customID property to my objects, could I use that
> > in the rendertree instead of ObectInfo->ObjectID?
> >  >   
>  That might be interesting extension of shader trees, but it's not possible at
> this moment either. Currently Cycles know knothing about custom properties and
> can't have any clue what to do with them.
>   
>    > >     3.: Nodes
> >    I really could use some nodes like the "rescale" node that is mentioned
> > in another thread on this list, because I'm running a custom OCIO
> > configuration and run into the fcurve issues that are mentioned here
> > https://github.com/sobotka/bassam-test  (last point in "Help! grading is
> > tricky"). Also a random node with a seed input (e.g. ObjID) would be
> > awesome. Which brings me to the next point....
> >  >   
>  Not sure you need rescale node, sounds more like making it so Cycles uses
> same working color space as rest of color pipeline. Lukas Stockner had a patch
> for that.
>   
> 

I'll check

>  Can see why rescale node can be handy in other occasions. But thing is, it
> can be achieved with 2 or 3 (depending on parameterization) math nodes, which
> is kinda quite too simple to make a dedicated mode for this. I would say: this
> is something what should be solved with node templates. We need those
> templates anyway, with ability to easily share/reuse them across projects.
>   
>  How random node is different from noise? Do you want different values to be
> returned for same shading point at different samples?
> 

It should be on object level... so if some objects share the same material, each
would get a different random number that could be used for color variations or
whatever.

 

>   
>    > >     4.: Beginners Guide to write cycles shaders/nodes
> >    Is there some guide on writing and compiling cycles shaders (not osl) and
> > custom nodes (maybe I could write the nodes in 4. myself?). Could compiled
> > shaders and nodes be shared, or has a custom blender build to be used for
> > that?
> >  >   
>  There are some video tutorials form various folks around blender community,
> AFAIR there was also some DVD training material from BI.
>   
>  Not sure what you mean by compiled shaders. You can't share SVM bytecode,
> that would even be quite useless. But you can share node setups in .blend
> file. The idea here is to have a "library" .blend file from which you link or
> append a material tree or a node group. This is as much easy as it could be in
> default blender (there are addons for online material collections and such,
> which sounds more friendly but i didn't try them yet).
>   
> 

wouldn't be a shader written in c++ be faster that a node group? 

 

>  But making it easier to share assets is definitely a direction we want to
> move, hopefully it'll happen sooner than later :)
>   
>    > >     5.: Logging
> >    I think I already asked that a while ago, but is it possible to reduce
> > cycles logging output? The log files on the renderfarm are huge, and I
> > porbably just would need some summary info.
> >  >   
>  It's not possible to reduce logging and in fact, i'm tempting to think
> verbosity should be increased (for example, --debug-cycles used). Here are
> reasoning:
>   
>  - You don't really want any logging while everything works fine.
>  - This means, renderfarm software can just delete full log file after
> job/task successfully rendered
>  - Different render farms might want different summary, so it kind of more
> flexible if farm itself worries about summary info it want to manage (CPU
> temperature, phase of Moon, whatever).
>  - Some really commonly requested summary (such as render time, memory usage
> which was added recently AFAIR, camera , file, scene..) are saved to render
> result's metadata. Advantage of that is that it then readable by Blender, so
> you can drop rendered sequence to VSE, enable SHow Metadata, scrub timeline
> and see timing info. Neato :)
>  - But unfortunately, render farms might and does go crazy time to time: black
> frames, missing textures, wrong animation, etc.. In order to troubleshoot such
> issues current verbosity is not really enough (for Caminandes VR we were using
> --debug-cycles command line argument to increase verbosity even more ;). If
> you'll drop idea of having full render log it'll be much more impossible to
> troubleshoot such issues.
>   
>  So not really convinced Blender should worry about renderfarm logs,
> renderfarm software itself should worry about that. For example, as mentioned
> above, wipe logs once job/task is finished successfully.
>   
> 

It's mostly the path tracing per tile that is annoying:

...

R628| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:08:54.75 |
Remaining:01:34.47 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 446/510

R629| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:05.49 |
Remaining:01:32.49 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 447/510

R630| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:27.26 |
Remaining:01:28.33 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 448/510

R631| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:35.25 |
Remaining:01:26.70 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 449/510

R632| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:37.36 |
Remaining:01:26.26 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 450/510

R633| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:38.92 |
Remaining:01:25.94 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 451/510

R634| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:40.05 |
Remaining:01:25.69 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 452/510

R635| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:44.75 |
Remaining:01:24.53 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 453/510

R636| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:45.55 |
Remaining:01:24.33 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 454/510

R637| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:48.45 |
Remaining:01:23.58 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 455/510

R638| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:49.01 |
Remaining:01:23.43 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 456/510

R639| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:51.82 |
Remaining:01:22.69 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 457/510

R640| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:54.78 |
Remaining:01:21.93 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 458/510

R641| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:58.38 |
Remaining:01:20.97 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 459/510

R642| Fra:106 Mem:6984.62M (0.00M, Peak 6984.86M) | Time:09:58.41 |
Remaining:01:20.97 | Mem:4534.81M, Peak:4534.81M | Scene, Main | Path Tracing
Tile 460/510

....

This for a lot of passes with even more samples is total overkill as a
default....

 

>  --
>  With best regards, Sergey Sharybin
> 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160616/4b5dcb3c/attachment.htm