Dev:Source/Materials/Nodes
目次
Note:
It appears that to implement this system, the rendering code will require "hooks" to be added for the different parts, and possibly a total rewrite. Having looked furthar into it, I feel that I am not capable of this, so anyone that wants to make the renderer more modular should feel free to go right ahead. Remove this note if you want to take that part over, and once it's done various matarial systems can be experimented with. It might be easiest to start trying to make it possible to put a python script in the place of the part that renders spec, dif, norm, refl, trans, etc etc...
Node Based Materials
This section is to document node based materials, as introduced in this thread. Feel free to correct grammar and typo's, and to add alternative ideas at the end of the page.
The basic idea is to inplement a crafter (link) type system in blender, so that we get node-based matarials. At this stage it appears that an XML format will be used, that will be converted into the blender system on import - However the only absolute decision is that at some stage a language that can implement a flow-chart will be used...
We use the experience of ExistingSystems to help make a working system - it is possible that something will be discovered that fits our needs exactly
Specification
- ImplicitVariables
- ShaderLibrary
- and after some discussion LanguageSpecification
Parts:
There are basically three parts to this, each divided into linking and blocks, with the blocks providing the actual maths and code, and the linking linking them together... They are:
- The blender representation: This has to be taken into account when designing the XML, as it gets created on saving, and possibly also right before the render... Probably, the whole internal stucture would use thins, but the XML pays a big part in the design and linking of its methods...
- The XML: This has to take into account several things, like how easily it can be converted into an efficient internal shader, how easy it is to code, how extendable it is, and how easily it is represented in the GUI...
- The Crafter interface: This should allow both high and low level design of shaders
Random notes
Some random notes, to be moved and tidied up
- How to fit volumetric shaders in? Do they get calculated at the front edge of the mesh, and do they take into account other objects within?
- One idea is having the renderer call the shaders each time it hits a matarial: basically the renderer assembles the data for the render, and each shader calls the one behind it (nex tmesh in z_buffer or the raytraced way) if a more_visable var is greater than 0 - it gets decremented by the transparancy shader as nessecery -- not sure what this would do to the speed, but it should be similer to how it works now? If there are more ideas on this, make a new page.
- Textures can be done simply using the existing system, until someone wants to re-write them in a different way.
- The whole system should be modular and replaceable, and only rely on outside parts if that makes it faster. Existing C code can be stuck into wrapper blocks as needed once a fomat is decided upon.
- We need to make a source tree of blender, and host it somewhere once we get coding.
- Maybe we could make a finalized specs page, where anything completely non-controversial can be documented: including objectives of the renderer, etc.
- One benefit of basing this on XML is that each shader could contain separate code for both the final render system and the viewport system. This way, the real time viewport shaders could be written with a high level shading language to match the output shaders. An additional benefit of this method is that it makes it easier to target multiple external rendering engines.-- EM
Links and images to outline the idea
- Linking method: - The rectangle links are created by the enveloping control structure, the circle ones are implicitly created when saying that an "output" is got from another blocks output.
