Anyone have any idea about a 64bit version of this shader?
-----Original Message-----
From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of
Thomas Helzle
Sent: Wednesday, June 28, 2006 6:14 PM
To: XSI(at)Softimage.COM
Subject: Re: Replacing the shadertree? Possible?
The solution is in reach:
If anyone missed this amazing new material
http://www.tek2shoot.com/content/view/29/27/
Please have a look.
It combines a lot of what we are talking about here into one shader.
- Instead of separate shaders for each highlight-flavor you have a dropdown
to select the one you need.
- Instead of those cheap archaic highlight solutions (phong, blinn) only, it
has Lafortune built in that really looks like light reflections instead of
painting just dots.
- It combines physical accurate surface simulation with all the older
models.
For me, it will replace about 20 or more of XSIs nodes in my everyday work.
And it is very fast too.
It reflects perfectly what I need everyday: On one hand, I need "Steel,
Gold, Glass, Paint" - I don't want to spend half an hour with basic archaic
nodes to get it right, but just slap a shader on it and be done. There are
many materials like these that are very well defined anyway.
Then I have more special needs where I need to tweak a lot. Again, with this
node I see all the possibilities to mix and connect like I want to.
My first test after playing with the shader for 20 minutes:
www.screendream.de/stuff/T2S_illumination_Glass_v0001.jpg
Wow, this tool is hot.
Now I just have to find out how I can make this the default material :-)
I am deeply impressed by this shader. Thanks a ton for this fantastic plugin
to the people at Tek2Shot!
Thanks, Thanks, Thanks, Thanks....
... ok I'll stop now ;-)
Thomas Helzle
On Wed, 28 Jun 2006 22:36:47 +0200, Andy Jones <andy(at)thefront.com> wrote:
> It sounds like what you're talking about is a sort of "shader wizard"
> that just helps you design a shader. This is something we've talked
> about for quite a while, as a way to get more people shading despite the
> additional complexity of our custom multi-pass shader trees that tend to
> change per job. In lieu of actually doing that, we eventually just
> implemented a system for translating standard shaders into valid shader
> for the current job by creating a library of metadata about how all the
> inputs of shaders should be interpreted, even if they have different
> names. The problem is that artists still do weird things with the base
> shaders that don't really translate into something reasonable and
> organized. And sometimes we get things dialed by eye that are just
> downright wrong.
>
> Ultimately, what has benefited us far more is to find ways to reduce the
> building blocks of the shaders to a smaller set which we can then change
> dynamically and have the changes propagate through the job. By doing
> this, we reduced the amount of work required to do shading for a job and
> were able to leverage more talent and technical prowess per shader than
> we could before. Basically, what I'm saying is that there would be
> tremendous benefit on even just medium scale productions to having some
> sort of macro engine so that the work done by technical types could be
> used in an intuitive way by artists within the context of a particular
> show. Sort of like if there were an easy interface for creating shader
> phenomena (which maybe there will be very soon).
>
> Wizard-like tools would still be very useful for people I'm sure. These
> aren't mutually exclusive concepts at all.
>
> -Andy
>
> Luc-Eric Rousseau wrote:
>
>> 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 r!
ay!
> '!
>> 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
>
---
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
