[Sidefx-houdini-list] render different volumes with takes or nodes ?

Szymon Kapeniak szymon.kapeniak at gmail.com
Wed Jan 9 16:00:41 EST 2013


2013/1/9 Jordan Halsey <jordanhalsey at gmail.com>

> On Wed, Jan 9, 2013 at 10:59 AM, Szymon Kapeniak
> <szymon.kapeniak at gmail.com>wrote:
>
> > > I am curious as to what is the benefit to the multiple mantra nodes
> > > here...
> >
> >
> > Because, quite along Houdini's paradigm, by doing this you're creating a
> > chain (collection in this case) of your decisions as an nodes, that can
> be
> > seen, supervised/debugged or copy/pasted by others, including non-humans,
> > i.e. scripts.
>
>
>
> Szymon,
>
> Please understand I am not doubting you, just wishing to understand if
> there is a better way...
>
> If I have a scene with 10 takes where all the settings are basically the
> same with the exception of the file path and of course whatever exists in
> that unique take(individual items - masks, etc) it would be better to have
> ten render nodes nine of which are referenced copies that are tied to a
> unique take? Is there something that I am not able to script when I use
> takes and one render node? I admit I rarely do any scripting to my render
> nodes. In my mind the Houdini paradigm is use the fewest nodes possible to
> accomplish the task but maybe in this case I am limiting myself
> somewhere...
>
>

Lots of this is a matter of personal preference. Problem with takes might
be when you use them also for different purposes like lighting/shading.
Varying render settings per take mixed with several recorded parameters
from shaders/light quickly might bring you a nightmare and isn't
that intuitive. Also, keeping render settings and scene settings in a
single take makes it hard to copy between shots (because you would have to
separate them first).

Normally it looks something like this:

Your scene consists with 50 shots, all with 10 passes + some preliminary
steps, like render shadow maps, or baking point clouds.
Your senior artist makes a single since with whole setup, chaining all
renders into a dependency node's tree and connect it to your favorite
render manager rop node (which hopefully supports dependencies).

Your vm_picture references $OS variable as a part of an image name, which
means that images will have baked-in rops they were created with.
(optionally your candidates objects parm references $OS too, so by naming
rops, you pick objects, or bundles to render.)

Now you ask a junior artist to recreate a setup in another 49 shots. He/She
opens two Houdini sessions, and without scripting or any advance setup
copies nodes between scenes. (or even better save them into HDA and spread
it around). So far so good.

Then something went wrong, some renders are black or something, so you
simply look on the image's name and you pickup a node which *independently*
from a scene or take, holds all render settings which are valid for a
current pass. The same can do render management software, or another junior
artists who next day makes a copy of issued node to start to fix a scene.
At the same time another artist adjust a light's colors, and saves the take
to be applied into a scene. They join nicely.

You can do similar thing with takes, but it won't be that simple and hmm..
visual. Again, it can be totally subjective, but most people I know tend to
use takes to record objects' settings  (that is parameters that are hard to
control proceduraly like shader assignment etc), controlling render process
with many, many mantra nodes. Separating scene settings and render settings
makes sense to them.


hth,
skk.





>
>
>
>
>
> **
> *Jordan Halsey**
> *
> maya | houdini | nuke | ae
> *www.jordanhalsey.com*
> _______________________________________________
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>



-- 
skk.



More information about the Sidefx-houdini-list mailing list