[Bf-committers] Nodes

Fri Jul 21 00:38:59 CEST 2006

I've added a page to the WIKI:
http://mediawiki.blender.org/index.php/BlenderDev/NodeShaders

Hopefully that clears up any ambiguity left from my messages so far. I'm
going to get started on the easy bit right now (any coder should be able to
figure out the easy bit =) ). Once that's done, I'll start work on actual
coding of the system. This could prove to be very interesting.

Branan

On 7/20/06, Charlie C <snailrose at bresnan.net> wrote:
>
>  Hey Branan
>
> I think Its a good idea. Personally I would like to be able to have more
> node based work oriented toward GE plugins.
> Right now its cfg files all the way, but GLSL/CG/GameLogic nodes would be
> great!
>
> Thanks,
> Charlie
>
>
>
> On Thu, 2006-07-20 at 12:46 -0700, Branan Riley wrote:
>
> 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
>
>
>
>
> _______________________________________________
>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.blender.org/pipermail/bf-committers/attachments/20060720/1f827118/attachment-0001.html