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

Jordan Halsey jordanhalsey at gmail.com
Wed Jan 9 16:20:25 EST 2013


Thank you for taking the time to respond. I really appreciate it and will
look at this workflow.

Jordan


On Wed, Jan 9, 2013 at 1:00 PM, Szymon Kapeniak
<szymon.kapeniak at gmail.com>wrote:

> 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.
> _______________________________________________
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
> https://lists.sidefx.com:443/mailman/listinfo/sidefx-houdini-list
>



-- 
**
*Jordan Halsey**
*
maya | houdini | nuke | ae
*www.jordanhalsey.com*



More information about the Sidefx-houdini-list mailing list