Re: Replacing the shadertree? Possible?

["Tim Leydecker" <BauerOink(at)gmx.de>]

Hey Luc,

I really like getting to know other peoples opinions on
how to achieve a robust but also extendable system.
Also really value your input as it (to a certain extend)
shows what could come up in the next couple of versions.

I really don´t want to argue pro or contra a specific
solution, as Brad put it, the first step would be to
collect sample workflows (he mentioned prousers,I´m none,
as I only have roughly 1200 hrs/9months working in XSI).

Anyway, I like your ideas. So I´ll take them apart:

*Positioning a gradient in the viewport.

Is something I asked for a while back, to be able to
create a custom depthpass easily, as this allows to
customize the gradient/fallof to be used for DOF later.
Depending on the lens, characteristics vary greatly
but pretty much never hit linear fallof at least. More
importantly, nobody cares if it´s a realistic lensmodel
but the main character isn´t crisp focused...

Current way I do it, constrain texturesupport to camera,
shift it down it´s axis to have the full gradient, as the support
obviously aligns himself mid to camcenter (no bitching here),
assign constantmaterial to partition/group, plug gradient into color,
maybe pick support, done. Took me a couple of try&error
sessions until I got the idea.

*paint (the shadows) and highlights in 3D

3DSMax had/has a tool to place a highlight (pointlight I guess)
by picking a point on a surface. Nice one for stills/beautyshots.

*paint the shadows (and highlights in 3D)

I´ve played with the ctrl.geolight pack today, in short, the
possibility to paint multiple attributes (color/intensity/shadow/...)
directly onto the lightemitting mesh via vertexmaps is gorgeous.

*Some of these functions may be complex and a single conceptual
*connection between two could mean dozens of connections at the
*low implementation level.

I´m not sure wether or not you ever played with Maya, you may
have noticed that there is a difference between creating connections
via the Attribute Editor, like connecting a filetexture to diffuse and
doing the same via the Hypershade. Bascially, the AE does all the
connections automatically, in Hypershade you have to plug things
by hand. Pretty much similar to what you had lined out conceptwise
when pointing beginners to the PPG/menues and advanced users to
the rendertree.

When I refered to grouping nodes as preset/capsule I meant something
different, similar to Mike Werkle´s idea, having ways to expose a set
of parameters to the animator, a custom PPG page collecting attributes
mostly likely needed to tweak, all others stuffed away to unclutter the GUI.

Important to stress still, something as easy as a doubleclick should expand
that group in the rendertree, to have ways to see what´s going on or simply
swap out/add an extra node - that may have better functionality or may
simply have been forgotten, broken, gone haywire or has a parameter
to be added/removed to the custom PPG for ease of use.

*as the mundane stuff begins to work out-of-the-box

It doesn´t yet. The last couple of years where dominated by
patching, hacking and workarounds, black boxes and loads
of tape to keep things together. This shows there´s something wrong...


*the material is described by combining elemental, artistic properties

I like the idea of combining elemental properties and must admit
I have problems reading the meaning for some of the mathnodes
from their namimg but in general wouldn´t expect a change in
naming conventions to "a bit more dark", "some oily thing" or
"more than before" a real helper. Instead, I´d like to see more
nodes that are so simple to grasp it becomes a snap for artists.

Example, when I´m not sure what a node does, I plug it in a
constant material color slot after having a glance at it. Mostly get it.

*artist might use tools like paint

I had stated I don´t use mixing of textures much, I was wrong.
I´m just not yet at the texturing stage, so I simply forgot about it.
I do indeed often use various blendmodes to get an idea, tinting
things down, adding, whatever. Then I refine the original map
to save on memory and complexity, e.g. try to boil the results down.

*I don't know the plans in XSI

You had me worried for a second...

*I argued for new tools

Wishlist:

-fallof node to be able to scale reflections based on distance
to surface. blureable reflections. sampling optimizeable.

-incidence with a silhouette switch, e.g. for rimlights that
only show up in the right places, not just everywhere inside
the threshhold.

-surface depth (>backlight from SSS) to be able to
select areas that are thin or thick or all but those,
basically to have more masking options.

-functional imageprojection through every light,
with actual support for volumic/fast_light effects.
Currently, the sib_slide_proj_light interferes with
everyone else...

In general, consolidate all hacks that have been
squeezed in over the years into something that
fits the concept and guidelines of the rendertree,
nothing less (that´s hard work, I know).

Cheers

tim









----- Original Message ----- 
From: "Luc-Eric Rousseau" <lucer(at)Softimage.COM>
To: <XSI(at)Softimage.COM>
Sent: Wednesday, June 28, 2006 9:48 PM
Subject: RE: Replacing the shadertree? Possible?


> I did not argue for a layer-based approach instead of a tree-based approach, I 
> argued for new tools where the material is described by combining elemental, 
> artistic properties together instead of programming functions.  Some of these 
> functions may be complex and a single conceptual connection between two could mean 
> dozens of connections at the low implementation level.  For fudging the results, 
> artist might use tools like paint the shadows and highlights in 3D, or position a 
> gradient with a manipulator in the 3D viewport. It just means that the problems are 
> addressed in different ways, not so much based on how it has to be implemented. 
> The tech people always get a sense of panic that power will be taken from them any 
> time these discussions occur, but they generally end up benifiting from additionnal 
> tools to play with, and more time to as the mundane stuff begins to work 
> out-of-the-box.  btw I don't know the plans in XSI, but it should be interesting to 
> see how mental ray'!
> s metaSL will impact the more technical needs.
>
> > -----Original Message-----
> > From: Tim Leydecker
> >
> > Hi Luc,
> >
> > it´s true, everything that can be laid out flat and painted easily
> > across meshborders without any seams is an artists dream.
> >
> > But nodes for condition state of an object/selection are as well,
> > the angle two objects have, the distance in a relation to something
> > else, the lightintensity at a certain point, the viewingangle
> > all those
> > bits also help in getting the best out of that perfect pink nailgloss
> > painted on previously. It´s also great if you don´t have to repeatedly
> > refresh it whenever you add a layer, e.g. you share a common
> > texture support or UV set, picked one, new color done.
> >
> > I´d therefor really wouldn´t want to limit things to a layer approach.
> > Actually, I hardly ever layer textures in Maya on a specific channel
> > but do often layer entire materials, or misuse a material to get the
> > illuminated areas (including the parts partly occluded by shadow)
> > as a way to select areas and do another operation on those.
> [...]
>
> ---
> 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