[Bf-committers] Nodes

Branan Riley branan at gmail.com
Thu Jul 20 20:02:33 CEST 2006


My current idea is to add nodetree capabilities to the shader list, just
like materials. Instead of calling the 'lambert' shader, for example, it
could call a custom nodetree. These would be seperate nodetrees from the
current material nodes, perhaps even having two nodetree lists, for diffuse
and specular. (they'd really be the same, of course... just different lists
of nodetrees, so that one can sperate one's diffuse and specular shaders
more easily)

Thread safety shouldn't be an issue, as long as I follow the same sorts of
practices as were use in Material nodes, which I expect are thread safe (?)

Branan

On 7/20/06, Ton Roosendaal <ton at blender.org> wrote:
>
> Hi,
>
> I will really welcome efforts to design a good set of basic primitive
> Nodes to build your own custom shaders, completely outside of the
> current Material system (with the Material of course still being the
> base of a nodetree).
>
> However, this isn't a simple task... there's features you have to keep
> track of, like:
>
> - requirements for pass render, how?
> - how to access lights?
> - how will shadow/raytrace-mirror/AO/etc integrate with it?
> - should the rendercore.c shading loops be reconstructed? and how?
>
> And of course it should be 100% thread safe. :)
>
> Cessen (= Nathan Vegdahl) already did some prelinary work on it. I
> think it would help us too to evaluate other shader trees/networks,
> like in XSI, Maya... or something that's more close to the renderman
> standards.
>
> -Ton-
>
>
> On 20 Jul, 2006, at 19:36, Branan Riley wrote:
>
> > I'm going to write a WIKI article as soon as I figure out exactly my
> > final ideas :)
> >
> >  I think I may do something different than what I originally wrote.
> > I'm thinking of creating another node tree, to allow for custom
> > shaders that could be used in any material, even outside of a node
> > material. The current shaders can stay hard-coded, with an 'add new'
> > option in the list now, that lets you create a custom shader using
> > nodes. The only issue now is figuring out how to tie any custom inputs
> > to the GUI. Unless someone has any major qualms with this idea, I'll
> > start writing a slightly more detailed plan, and try to have it on the
> > WIKI by the weekend.
> >
> >  Branan
> >
> > On 7/18/06, Joe Eagar <joeedh at gmail.com> wrote:
> >> > I've been trying to figure out how to split the current Material
> >> input
> >> > node. Create a "Diffuse" node, "Specular" node, etc. The Material
> >> node
> >> > can still be there, of course. I'd also like to be able to add a
> >> > "lights" node, which gives the vectors to the lights for each pixel
> >> as
> >> > well. Coupled with some easy-to-write vector math nodes, this gives
> >> a
> >> > very powerful low-level shader design system, but also allows for
> >> less
> >> > advanced users to create simpler systems.
> >> >
> >> > My problem is the three main nodes - diffuse, specular, and lights.
> >> > I've been digging through the source, but I can't find any sort of
> >> > easy-to-use hook already in place. I tried looking at the Material
> >> > Node code, but that pretty much is a front-end for the Material code
> >> > itself, which is not very fun to look through at all. Any advice on
> >> > where to get started on any of those nodes would be greatly
> >> appreciated.
> >> >
> >> > Branan
> >> Also, cessen (I don't know his real name -- eh, is it you?) was
> >> working
> >> on this a while back.
> >>
> >> Anyway, you might want to write a document on the wiki detailing what
> >> you intend to do.Really the material node system needs a
> >> comprehensive
> >> usability review, with suggestions on what new nodes are needed, etc.
> >> The current paradigm of using nodes to blend materials together should
> >> be kept, IMHO, but I also think there should be support for writing
> >>  shaders from scratch, too.
> >>
> >> Keep in mind, I don't think a material node network is executed once
> >> for
> >> every light.I believe the network is only executed once per pixel,
> >> when each component material has been fully calculated.If you added
> >> something like a light node, you'd probably have to write code to
> >> detect
> >> it, and if it exists, to execute the node network once for each light,
> >> accumulating the result.It might be complicated.
> >>
> >> joeedh
> >>  _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at projects.blender.org
> >>  http://projects.blender.org/mailman/listinfo/bf-committers
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at projects.blender.org
> > http://projects.blender.org/mailman/listinfo/bf-committers
> >
> ------------------------------------------------------------------------
> --
> Ton Roosendaal  Blender Foundation ton at blender.org
> http://www.blender.org
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.blender.org/pipermail/bf-committers/attachments/20060720/cd88ef80/attachment-0001.html


More information about the Bf-committers mailing list