Isn't the render tree a tool to prototype with phenonmena monolithic shader ?
Harry Bardak
TD / Compositor.
Http://perso.wanadoo.fr/harry.bardak/
+33 6 76 63 35 54
+44 781 661 4147
----------------------------------------
> Subject: Re: Replacing the shadertree? Possible?
> From: jordibares(at)the-mill.com
> To: XSI(at)Softimage.COM
> Date: Mon, 3 Jul 2006 13:45:20 +0100
>
> No question it has been a good tool and we still have plenty of road in
> front but my thinking goes in two directions;
>
> 1 - Make it more easy and readable without forcing us to go so granular
> unless we want. Meaning cleverer and optimised mega-shaders that have a
> much broad design and are called thru less obscure names.
>
> 2 - If we need to go down, then bring the lot. A good example of how far
> we could go is VOPs in Houdini, a graphical node-based interface that
> goes as far as you need and with access to everything in the rest of the
> software.
>
> At the end we use our own monolithic shaders like crazy because simply
> we can't do that with phenomena and these building blocks are not
> optimised so render times skyrocket every now and then.
>
> hope that makes it clearer.
>
> jb
>
> On Wed, 2006-06-28 at 09:44 -0700, Bradley Gabe wrote:
> > After having worked with the Soft|3D style shading system for years, my
> > ability as a shading artist only progressed so far. The only way to get
> > more advanced looks was to hunker down and learn a shader language and
> > compile custom shaders. But then XSI came along with the render tree and
> > removed that necessity almost entirely.
> >
> > The render tree is wonderful in the sense that it provides someone with
> > a visual-based mind like myself an arena for visualizing what the math
> > does. And thus, I have been able to advance my understanding of render
> > math concepts further than I could have if versed only in theory. More
> > importantly, I have been able to advance at a comfortable pace, and get
> > paid during the journey. My ability as a shading artist has progressed
> > exponentially as a result. If that isn't empowering the artist, I don't
> > know what is?
> >
> > I think, a lighting TD, no matter how technical, is still an artist.
> > After all only a very small subset of technical people is actually able
> > to do this kind of work with any proclivity. And the converse, only a
> > small percentage of artists are technical enough to do CG lighting work.
> >
> > Any CG work environment, especially in rendering, is a balancing act
> > between ease of use for artists, and specific control for the technical-
> > minded, and in my opinion, the render tree does a reasonably good job of
> > providing both high level and low level access. Any improvements should
> > make sure to balance these two sides, which means any implementation of
> > new uber shaders should allow input for at least the same kind of low
> > level manipulation provided by the original shader set. No more black
> > boxes please, as it seems like every production situation requires an
> > exception or adjustment to what's inside the box.
> >
> > -Brad
> >
> > > I don't understand why you focus so much on the TD vs the artist in
> > > the Render Tree, I have spent considerable time writing why I think
> > > the Render Tree is an artist tool as much as it is a TD tool. There
> > > seem to be no consensus possible.
> > >
> > >
> > >
> > > Bernard
> > >
> > >
> > >
> > > On 6/28/06, Mike Werckle <stumbly(at)gmail.com> wrote:
> > > > I apologize for splitting hairs Bernard, but I feel this distinction is
> > > > important:
> > > >
> > > > to me there's a difference between "user friendliness" and intuitive
> > > > design-- unless I am misunderstanding what you mean. I agree that the
> > > > render tree is quite user-friendly and elegant if you are a TD, a
> > > > technically oriented person, left-brained, or educated specifically in its
> > > > functionality. My argument has always been that the render tree doesn't
> > > > seem to be designed to be easy to pick up for talented people who are
> > > > perhaps more right-brained, or less technically inclined-- and this was
> > > > affirmed by Luc-Eric's response.
> > > >
> > > > Of course there will always be special (lucky, hardworking or gifted)
> > > > exceptions to this generalization, such as yourself. But my original
> > > > critique was that it doesn't make sense to me to design a graphical
> > > > interface for the technical user, who might not benefit from it as much as
> > > > the typical artist, who by nature is visually oriented.
> > > >
> > > > Putting nodes together with little connectors just SCREAMS right brain
> > > > creativity to me.
> > > >
> > > > As an artist, I don't want phong or blinn or math nodes or photons or an
> > > > "invertrefl" socket-- I don't know what that stuff means or how to connect
> > > > it. I want red, and shiny, furry, glowing, and wet (geez, sounds like
> > > > something a doctor should look at now that I type it). Seriously, that's
> > > > an over-simplification, but it's a valid way for an artist to want to work.
> > > >
> > > > Do you think it would be possible to have a graphical node-based tool for
> > > > artists to do all the things they need to do-- colors, textures, layering,
> > > > transparencies, surface properties, etc.-- while also retaining the level of
> > > > tweak control and functionality that the render tree already has? Do you
> > > > think something like that would be useful? Or should TDs be supplying
> > > > presets to artists to tweak?
> > > >
> > > > Mike
> > > >
> > > >
> > > > On 6/27/06, Bernard Lebel <3dbernard(at)gmail.com> wrote:
> > > > > Don't get me wrong, I have never said the Render Tree is perfect, far
> > > > > from it. The debate evolved around wether or not the Render Tree is a
> > > > > user-friendly tool or not, which I think it is, and is a very elegant
> > > > > solution in its current state.
> > > > >
> > > > > But since you bring these concerns up, I agree with all your points,
> > > > > Jordi. I hoped for a long time that things would be taken care of in
> > > > > those areas, but quite frankly I've lost hope so I stopped bugging
> > > > > Softimage about it.
> > > > >
> > > > >
> > > > > Bernard
> > > > >
> > > > >
> > > > >
> > > > > On 6/27/06, Jordi Bares <jordibares(at)the-mill.com> wrote:
> > > > > > Not that i want to start a war but totally disagree, fair enough we got
> > > > > > used to, fair enough we can do a lot of things with but truly is not
> > > > > > very comfortable nor intuitive.
> > > > > >
> > > > > > The truth is that every single software tool i have come accross is
> > > > > > basically an 80-90s solution instead of a friendlier more closer-to-life
> > > > > > interface (and i talk about design interface not the gui)
> > > > > >
> > > > > > Specially with materials we are (on any software) still in the
> > > > > > paleolithic, cameras, lights... seems like the raw power is just spent
> > > > > > in the software abstraction instead of the concepts because nobody is
> > > > > > really revisiting them.
> > > > > >
> > > > > > The first welcome approach i have seen is Maxwell where you deal with a
> > > > > > fair amount of reality on the material definition and cameras and seems
> > > > > > far more intuitive than anything else.
> > > > > >
> > > > > > On top of that the locality of those tools, meaning they do not exposed
> > > > > > as they should, does not reflect how sophisticated this tools are
> > > > > > internally. Why shouldn't the rendertree be part of the fxtree and
> > > > > > viceversa? Why the fcurve editor is not part of the rendertree?
> > > > > >
> > > > > > The same for the physics, why cloth, RBDs, softbodies and particles are
> > > > > > not integrated fully into one single umbrela, a mega-physics engine?
> > > > > >
> > > > > > Anyway, my 2 cents before Spain kicks some French ass today. ;-)
> > > > > >
> > > > > > jb
> > > > > >
> > > > > > On Tue, 2006-06-27 at 08:11 -0400, Bernard Lebel wrote:
> > > > > > > Despite its current limitations and bugs, I think the Render Tree is
> > > > > > > as elegant as elegant can be. Perhaps it is me who is stubborn, but
> > > > > > > having played with various approach, I think it's the easiest one for
> > > > > > > most situations.
> > > > > > >
> > > > > > >
> > > > > > > Cheers
> > > > > > > Bernard
> > > > > > >
> > > > > > >
> > > > > > > On 6/27/06, Mike Werckle <stumbly(at)gmail.com> wrote:
> > > > > > > > Perhaps I am too idealistic. Do you think that the act of creating
> > > > shaders
> > > > > > > > is so complex that it's simply unrealistic for me to wish for a more
> > > > elegant
> > > > > > > > solution?
> > > > > > > >
> > > > > > > > Mike
> > > > > > > ---
> > > > > > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
> > > > body:
> > > > > > > unsubscribe xsi
> > > > > > --
> > > > > > Jordi Bares <jordibares(at)the-mill.com>
> > > > > > The Mill
> > > > > >
> > > > > > ---
> > > > > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
> > > > body:
> > > > > > unsubscribe xsi
> > > > > >
> > > > > ---
> > > > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> > > > > unsubscribe xsi
> > > > >
> > > >
> > > >
> > > ---
> > > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> > > unsubscribe xsi
> >
> > ---
> > Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> > unsubscribe xsi
> --
> Jordi Bares <jordibares(at)the-mill.com>
> The Mill
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
> unsubscribe xsi
_________________________________________________________________
Be one of the first to try Windows Live Mail.
http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
