Blender Shading Language research - opinions wanted

Blender's renderer and external renderer export

Moderators: jesterKing, stiv

Post Reply
Posts: 0
Joined: Tue May 18, 2004 8:11 am

Blender Shading Language research - opinions wanted

Post by simonharvey »

Hi I have submitted the following project in at the blender projects website:
I intend to create a render pipeline who's shader(s) can be selected by a user as being a programmable shader created from source code which is then compiled and then "executed" when a pixel is to be shaded OR one of the current stock shaders from a drop down list box in material settings.

I have still not yet decided wheather the shading language should be a subset of python (at least looking synthatically similar) or like C (similar to RSL) however the many benifits of an RSL clone is that people have experience with it, it is an industry standard and the shaders runtimes and shader compilers from pixie or aqsis can be used.

What I hope to use are:
The mailing lists - so other developers can have an input on the syntax design as well as give help on pipeline integration and coding techniques.
The exposure - so people are aware of it.

This is a blender research project.

There is no agenda of infringing on the foundation's long term plans.

I am doing a masters in electronics, I do not have the 'promptness' and speed that other coders may have because my thesis takes up so much of my time. Therefore if the project is accepted it should be expected that this is a *long term research project*. With no results to be shown for the first 6-12 months after initial acceptance.

My main interest is the shader virtual machine, shader API's and the render pipeline, it will have to be for others to give it a nice GUI if the programmable shader subsystem has the required merit to warrant futher development.

The shader type would be the surface shader in renderman(tm), so there is no intention of providing displacement, transformation, atmospheric, volumetric and light shaders to blender's graphics pipeline.

I would like to know what you think about this, what ideas you have (within the bounds of the above proposal) and what you could think could be done.

any comments are much appreciated

ps. ton has already read this and would like other developers to have a look at it.
Last edited by simonharvey on Sat Jun 05, 2004 12:07 am, edited 1 time in total.

Posts: 0
Joined: Tue Feb 25, 2003 2:37 pm

Post by ideasman »

The more I have used blender the more I have realized that programmable shaders are important.

Having a standardized multiplatform shading language that was the same in each version of blender would be awesome.

Especialy if it could do displacement and effect raytrace parameters......

As for syntax- If its not actually going to use python- Just a python like syntax, then I think using existing implimentations would be better ( C - Like )

If its just a syntax issue it may be possible to have both- Use a python style to C style function, so python users would be happy.

It does seem inconsistant to use C Syntax when everythin else in blender uses Python....

This is just my opinion, I have never actually used a shading language...
Good luck with your work... sounds exciting!

- Cam

Posts: 0
Joined: Thu Jan 15, 2004 6:41 am
Location: Canada - Québec - Sherbrooke

Post by gabio »

For the GUI... I though about a way to integrate a tree shader in blender that could work with the present render pipeline and give much more feature to the user like multi linked texture block, logic, python scripting. Basicaly, it's made of block, i should be calculated from the input to the output. You got "in", "out", "logic", "script", "container". and you just have to plug some "in" block (color, texture, mapping coordinate) to some logic and script block (modif of the input based on variable) and then output, which is unique and containe the render option(like now, the mapping style the ray -on - off, zbuffer.. The container block is just to get some grouping tools, like meta in the sequencer.
Now the way i can see the language you could put behind it, is more and xml than a plain c file. Anyway i'm juts trowing my idea. and it may even not be very clear, it's a bit complex.

Posts: 0
Joined: Fri May 23, 2003 1:53 am

This already exists, to some degree

Post by emack »

You may wish to check out the blender/aqsis integration project at

This is an already-working translator from Blender to Aqsis. The translator is based on the Yafray exporter. It uses specially written Renderman shaders to mimic the light behavior of Blender material shaders. This allows a user to set up lighting inside Blender and have the results from an Aqsis render match it.

There is also Crafter, an open source xml based shader tree construction system that was originally intended to be a part of Blender.

A useful step would be the integration of Crafter into Blender, coupled with rewriting the OpenGL display systems to use the updated OpenGL glslang shading language to display displacement and other properties: ... splacement

This would ideally output to both Yafray and Aqsis/Renderman shading, and would provide a very capable production shading pipeline useful for real time and final renders.



Posts: 0
Joined: Tue May 18, 2004 8:11 am

Re: This already exists, to some degree

Post by simonharvey »

Hi and thanks Eliot for your input.

My idea wasnt about bringing blender to renderman, i.e. making an exporter that renders similar images and explioting the strenghts of the 3rd party renderer, but wrapping a shading language to the blender architecture. so the user has an intimate connection :oops: :wink: to the pipeline.

An equivilent is perhaps maya scripting language that is also used for writing shaders within maya (however I haven't used this so I can't comment any futher).

In this way there is no setup and the user knows that the shading language and the renderer are a unified whole, as opposed to discreet units. also things become more intergrated and easier to use - say for example that the user clicks a button and compiles a shader from within blender that appears in a shader drop down list box in material buttons.

All of your ideas have a mountain size amount of merit, blender would do very well to use all of them but I think that implementing a text based shader system is the right way to go first, accelerate the shader runtime, and then work on the graphical way of doing shaders. I have already started planning the underling architecture and it looks like alot of the code would go into both graphical and text mode shaders.

As for the GLslang I will pay attention to it when I come to designing the language (I still have to piece together how yacc and lex work!!!!!).

Kind regards

Posts: 0
Joined: Mon Jan 27, 2003 11:22 pm

Post by dcuny »

Regarding yacc and lex, while they are both excellent tools, it's not that difficult to write a lexer and parser without them.

If the language is relatively simple, you can often get by with a single character look ahead when lexing tokens, to disambiguate things like + from += and so on. A simple getChar and ungetChar will do the trick.

The same thing goes with designing the grammar. If it's simple enough, you can get away with no lookahead. My parsers typically have the routines:
  • char *theWord(): returns the current word in the stream;
  • boolean isWord( char* target ): returns true if current token matches target;
  • void skipWord(): move ahead to the next token in the stream;
  • void expectWord( char *target ): if the current word matches target, performs a skipWord to move ahead, otherwise generates an error message "Expected target, not currentWord".
Operator precedence is the main bit that's tricky. One advantage of going this route is that you avoid adding more dependancies to Blender. I've always found it a pain to set up YACC under Windows, but I'm an idiot about these things. :roll:

I'd recommend Chapter 8 of The Unix Programming Environment, entitled Program Development. It covers the development of a reasonably representative programming language in C, and covers YACC and Lex.

There's an excellent online paper entitled A Compact Guide to Lex & Yacc by Thomas Niemann which is quite good, showing a how to write a simple interpreter and compiler.

Another option might be to write a VM for the shaders in C, but generate the bytecodes for the VM using Python instead of YACC and Lex.

Post Reply