[Bf-committers] Nodes
Charlie C
snailrose at bresnan.net
Thu Jul 20 23:11:25 CEST 2006
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.blender.org/pipermail/bf-committers/attachments/20060720/734b30a4/attachment-0001.htm
More information about the Bf-committers
mailing list