[Bf-committers] Nodes

Branan Riley branan at gmail.com
Thu Jul 20 21:46:15 CEST 2006


I just had another idea on the implementation of these... This bit will
definately require majore work to the rendering system, though.

Hardware-accelerated GLSL shaders would be awesome beyond awesome. Rather
than coding software shaders, what if a Node-based, graphical GLSL editor
were used, that could be tied into the game engine, or into
hardware-accelerated shaders. That kills three birds with one stone: Easier
shader editing for the GE, custom low-level shaders for rendering, and
hardware-accelerated shaders. I could probably write a parser to turn a node
tree into GLSL code, complete with groups being treated as functions... The
hard part would be integrating GLSL shaders into the rendering pipeline, and
having a software fallback if the system doesn't support GLSL.

It's probably a good idea to get software shaders running first, anyway.
They'd be needed as a fallback for GLSL; besides that, integrating GLSL is
definately going to be a royal pain in the a**.  This was just one of those
things I wanted to get opinions on. Please treat this not so much as a "I
want to code this now", but more as "This would be neat, does it sound like
a good idea?"

Branan

On 7/20/06, Branan Riley <branan at gmail.com> wrote:
>
> 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/5940a3be/attachment.htm


More information about the Bf-committers mailing list