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

[Sergey Sharybin]

Hi,

Inlined answers.

On Thu, Jun 16, 2016 at 9:09 AM, Thomas Volkmann <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?


> 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.

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?


>  *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).

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.

-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160616/b115cd6a/attachment.htm