crafter-blender integration

[wumamor]

now that crafter is open source and GPL, can we look into integration into blender? it would be VERY useful with the yafray integration recently introduced if anyone can add a poll for this please do as apparently i am too stupid to make them work

[Samjh]

That would be a very neat tool for Blender users who prefer Yafray over the internal renderer.

For those who don't know what Crafter is:
Click here for the Crafter website
It's basically a material creator for Yafray and Virtualight.

[Monkeyboi]

A node-based materials system a la Crafter and Softimage XSI is very high on my wishlist for Blender. Preferrably it should work with Blender Internal renderer too.

[spongetti]

Just downloaded and tested crafter. Nice Interface but very..very.. slow on my system (still winXP - soon linux, if possible)

Any Idea? Seems to be a OpenGL - Problem.

[jesterKing]

Polls are disabled on these forums.

/Nathan

[Monkeyboi]

Crafter itself is quite slow, and I don't think it would be easy to integrate, but something along the lines of it would be nice!

[slikdigit]

any idea which version of glut I should be using? ld returns with unresolved references on my system (3.7.1 is the glut version)
but yeah, I agree node based interface similar to crafter or a revamped oops window would be nice for materials, and perhaps in combination with the sequence editor for post processing. maybe as a render/post tree.
I'd like to play with crafter. interface looks very nice from what I've seen.

[bfvietnam]

(if this is too long, I can reduce it to a paragraph.., this the problem with trying to funnel ideas, sometimes it requires a bit of understanding, but my motivation in the following is to come up with a method of making shaders, and possibly other stuff with a visual, yet easy to understand, language that does not use code or text, that uses modules like you find in crafter.. But not executed by crafter but in something very close to assembly language, C? Note: Fragment shaders or pixel shaders in OpenGL2 and DirectX's Pixel Shader 2.0 languages are probably represented like assembly, or like micro-code)

Read wikipedia page on pixel shaders.

The least intrusive method would be to have crafter create modules that blender could execute as texture plugins. Then people could generate custom procedural textures for blender. Another idea would be to develop crafter into a visual shader language. Read up about "recursive descent parsers", its
not very hard to make a language. And the thing that's most bizarre is that fundamentally a tree of evaluation is a graphical construct, so why do we write programs in a linear listing of words when fundamentally all programs are interconnecting nodes (in a non-cyclic graph, or tree) that are traversed by the computer and evaluated. For instance, a For-loop is four parameters (or children): initialization, an inequality, an incrementer and a listing of statements. A list of statements contain 1 to N children that are statements. Each statement can be a function call, or even another "for" operator..

So why can't this be represented graphically, and why not make it compileable to a shader language like Renderman, or for a shader engine that works within blender?

BTW, those who work with stack based languages, would realize that fundamentally when parsing a program inline you are generating a tree of evlauation and evaluating it inline. Using the stack to protect function scope when recursing.. You can use an evaluation tree to generate code optimized for a stack. Also you use stacks for pushing parameters to
functions..

This is a nice little link to someone who found an easy way to turn an expression from inorder representation, into a tree of evaluation, into a stack based form of an expression:
http://www.arstdesign.com/articles/expr ... ation.html

(I like how its visual, it shows his process)..

Even the process that uses the arrows of moving things around is a form of a language, its a graphing language, a series of figures that represent steps to a solution. And that process can be represented as a series of actions.. Or steps of a recipe.. Some of those actions are patterns, that can be repreated on other problems.. What determines what pattern is applied, is the conditions of the state of the problem.

Ever mess with a RPN calculator?

A reverse polish notation calculator is a post-order recursive descent of an evaluation tree or expression tree. Post-order the operator is defined in the language after its parameters (1 2 +), pre-order means it comes before (+ 1 2), and in-order means the operator comes between the operands (1 + 2). Most people like in-order traversal calculators.. But if you could see how the tree is constructed ---

Code: Select all

   +
1     2

--- it wouldn't matter what you used.. Given that you understand how the tree is evaluated to produce these different ways of arranging the problem.. Now you could also represent as a parallel operation like this:

Code: Select all

1
      +
2

---->

Where 1 and 2 are put into the + operation (the arrow means read left to right).. And the output goes to the screen..

To build on this more..

The expression 1 + 3 * 4 / 8 in an evaluation tree might look like this (depending on the precedence rules):

Code: Select all

   +
1     *
     3    /
         4   8

The computer can either evaluate this directly, or the computer can turn it into another representation.. This is the distinction between a interpreter and a compiler.. And interpreter generates partial trees and evaluates them, a compile just converts the language into something that is easier for a computer to evaluate.. Anyhow, the above tree can be represented for a "in order" evaluator as this:

Code: Select all

(1 + (3 * (4 / 8))) 

That is, 4 /8 is evaluated, before 3 can be multiplied and 1 can be added.

It could also be written for a evaluator that doesn't use a stack:

Code: Select all

4 / 8 * 3 + 1 

The computer could also arrange the nodes to be computed on a reverse polish notation calculator:

Code: Select all

(1 (3 (4 8 /) *) +) 

(or)

Code: Select all

1 3 4 8 / * +

Try that on you HP calculator..

Or if you are using lisp (a highly recursive computer language):

Code: Select all

(+ 1 ( * 3 (/ 4 8)))

or in parallel (input/output boxes):

Code: Select all

4 
    /   
8       
          *
3             + 

1 

(that is division operator is dependent on the output of 4 and 8,
the multiplication operator is dependent on the output of 3 and the result of the division, the addition operator is dependent on the output of 1 and the result of the multiplication).. This is how Crafter would represent things (no?). Conceptually speaking..

But fundamentally, the pattern of this expression, looks like this:

Code: Select all

  /\
o   o
    / \
   o   o
       / \
      o   o

PROGRAMS ARE JUST LIKE THIS..

Programs are just larger versions of these trees:

Code: Select all

for ($x = 0 ; $x < 10 ; $x++) { 
    if ($x == 5) { 
        $y = 10; print "hello";
    }
}

can be written in something like lisp as

Code: Select all

 
(for (= $x 0) (< $x 10) (++ $x) (if (== $x 5) (expressionlist (= 10 y) (print "hello")))

In some other pre-order language, this might look like

Code: Select all

(($x 0 =) ($x 10 <) ($x ++) (($x 5 ==) ((10 y =) ("hello" print) expressionlist) for)

but humans prefer:

Code: Select all

(for ($x =  0) ($x < 10) ($x++) (if ($x == 5) (($y = 10) (print "hello"))))

Give me any application, and I can write a program that will represent it in these three forms.. And alternately as a graph like this..

Code: Select all

  /\
o   o
    / \
   o   o
       / \
      o   o

Well I'm way off topic.. But the idea I have is, fundamentally shader languages can be represented as graphs.. Why stop at only doing textures, why nto extend this to be a shader language.. A visual one at that.. And then reduce it to machine code or something blender can run faster.. Let the future sort itself out.. But it is possibel to get too involved or to get intimidated in design... I think CRAFTER IS GOOD TECHNOLOGY, its what inspired the change in blender's interface.. But I believe that making it into a visual shader language or make it such that it uses a visual shader language to create its modules, it would make the idea conceptually viral to computer graphics work and would make a lot of people enthusiastic about using blender.. It would expose the reality of what computer languages are, and why we shouldn't ever use text to represent something that is fundamentally visual!!!

[bfvietnam]

Everyone knows what a flowchart is.. This is just like a flowchart.. Its a graphical way to represent execution..

(some references, obtained with google)
http://www.stfx.ca/people/gdoucett/Info ... /loops.htm
http://www.cs.mcgill.ca/~ratzer/lectures/lecture15.html





In assembly language a form loop is really like this:

Code: Select all

label:
statement 
statement
statement
if (not condition) jump next statement 
goto label
statement 
statement

but you could also represent it as

Code: Select all

initial statement
label: 
if (not condition) jump the next statement
goto next_label:
statement 
statement
statement
goto label:
next_label: 
statement
statement

realworld code example:

Code: Select all

    mov cx,80     ; # of stars
    mov ah,2      ; disp char fnctn
    mov dl,'*'    ; char to display
TOP:
    int 21h       ; display a star
    loop TOP      ; repeat 80 times

(obtained from this website:
http://www.shsu.edu/~csc_tjm/spring2001/cs272/ch4a.html )


Note: int 21h is a library of functions..You put your parameters into some registers and you call INT 21H, which calls a function that operates on the registers.. register ah tells INT 21H which function to execute, and dl is the operand of function 2 in library 21H. This is for an 8086 processor in MSDOS.. I had taken a course in this, so I know it.. But fundamentally all assembly is like this.. Interrupts take the current scope (or state of your variables) and pushes it on a stack (think of a spring loaded plate carrier, like you find at some cafeterias, imagine writing an expression on a plater and sticking it on the stack), then the processor changes the program counter (which is really a little arrow that keeps track of the steps in a procedural recipe, the program) to the address found at location 66 in memory (that 2 times the hexidecimal representation of 21 {each 'word' in and 8086 processor is 16 bits long, so its two bytes long, one byte is 8 bits}). Which contains the address of the beginning of the INT21 library.. Then it executes a bootstrap of sorts that determines which function to call. This may be an array with the address of the "print" function.. Which takes the value "*", in dl, and print it to the screen.. Then when the print statement has done that.. The computer returns, to when it called "INT 21H", by popping off the stack the state of the variables before it called INT 21H, and it continues executing.. So even in assembly, you make use of other peoples code to do your dirty work, nobody ever does everything from scratch, unless they made their own computer.. What am I saying? Everyone should take assembly language before being given java? Maybe.. But before this assembly code was made.. A programmer sat down with a piece of paper, and drew out a flow-chart like the one at the top of this message.. She either does this in her mind, or on paper, but the concept is visual or procedural: I do this, then I do this, and then I call this to handle the print up of this, and then I goto that..

And as I describe in the previous message,
can be represented visually.. However a for-loop can't be executed in parallel because it implies a linear process (or interative form) of execution, it would need a top-down evaluation (starting with the parent node and evaluating the children, this like going backwards, from right to left, for crafter, a module would have to control other modules to get a result), which you probably can't do with crafter at this time..

[wavk]

Hi wumamor,

Okay, you got me! I've got the sparks again, I'm coding!

Samjh & Monkeyboi: Yes, when crafter gets integrated, it should definitely work for Blender materials as well as for YafRay materials. And it would be quite easy to add simple pieces of code to export to renderman like renderers, very simple indeed.

spongetti:

Slow?! How can it be slow? I coded it on an old wreck, an 850 Mhz with a geforce 2. Hm... yeah probably an opengl problem. But that will be gone when it's in Blender, it'll use Blender's opengl stuff. Maybe it's because of my transparent, glittery, shadow casting, colour bleeding interface Sorry for that

slikdigit:

I don't recommend running it on linux at the moment. Although the guy that ported it did quite a good job, he ripped out some vital features. Like popups don't work anymore. And he changed my menus with some kind of system dependant glut menu, which I hate! And the redraw code is messed up. It basicly boils down to that he used glut to port it. I used pure opengl. The way you need to code for glut is very specific, and different from my event handling method. So some things were hard to port to glut. But without glut other parts would have been much more difficult to port... But with Blender's ghost library that will hopefully work.

Also, Crafter doesn't seem to work anymore with the new YafRay! So it really needs to be updated.

I'm going to start now not trying to better Crafter, but immediately starting inside Blender. Probably redoing parts, but I think a lot can be copied. This will be a lot of work, and I sure could use a hand! Although I coded Crafter, I'm not a real coder, I'm terrible at compiling and math etc.

So if anyone wants to help, please!

And of course, I'm in for a completely nodal Blender, for the oops, compositor etc. Bye the way there's someone working on a compositor based on the crafter interface, so that might be interesting.

bfvietnam:

There's already a shader language, crafter exports to yafray xml. But I think when it would be included wihtin Blender, there should be no language, it should be all visual. And that's possible, becaus then it will be one program, and even YafRay is connected via a plugin interface now.

And as I describe in the previous message,
can be represented visually.. However a for-loop can't be executed in parallel because it implies a linear process (or interative form) of execution, it would need a top-down evaluation (starting with the parent node and evaluating the children, this like going backwards, from right to left, for crafter, a module would have to control other modules to get a result), which you probably can't do with crafter at this time..

I read your post a couple of times. I have no idea how shader compiling works but I can tell you how it works in Crafter/YafRay at the moment.

There's basicly a hardcoded class derived from a base material block class, that's implemented for each type of material block, in YafRay. A material block does it's math by asking it's children to give their output. These children at their turn ask their children for their output, until the tree ends.

So the shader blocks diagram at render time is converted, well converted, not even that. The shader diagram should be a visual representation of an instance of a class that has the code in it. I don't think it could be any faster.

Anyway, don't think there should be an intermediate shader language, that would only slow things down. And I think everything should be made possible by simple blocks. The math itself will be precompiled inside blender. It's just functions asking other functions their output.

Is that what you mean? Are you suggesting an internal kind of way to handle the maths of a tree based system?

Argh look at what you made me do! This must be my longest post ever! If you want to help, please do! I think it's quite a lot of work.

I think I'll start off with a simple thing... making a new space type in blender!

[Monkeyboi]

Sounds nice that you are going to implement!

But, why not replace the Material buttons?

BTW, for inspiration on node-based material editors, I strongly suggest you download a demo of Softimage XSI, either the 30-day full version or the XSI Experience version. Then follow one or two tutorials and see just how powerful it is! I apreciate Crafter, but I still think XSI might serve for some good inspiration.

This new Material editor will also have to be able to simulate pretty much everything that is possible already, including setting texture mapping, controling ramps and shaders etc.

Lastly, very good luck to you, a node-based material editor would be such a boon for Blender.

[gabio]

Sounds nice that you are going to implement!

But, why not replace the Material buttons?

BTW, for inspiration on node-based material editors, I strongly suggest you download a demo of Softimage XSI, either the 30-day full version or the XSI Experience version. Then follow one or two tutorials and see just how powerful it is! I apreciate Crafter, but I still think XSI might serve for some good inspiration.

This new Material editor will also have to be able to simulate pretty much everything that is possible already, including setting texture mapping, controling ramps and shaders etc.

Lastly, very good luck to you, a nodebased material editor would be such a boon for Blender.

yea, something that good and complet than it could modifie it way of working for the selected render( a limited tree for blender internal and a full compatible renderman for aqsis for ex.)

[Money_YaY!]

I think you should just add it as much as you can and slowly it can replace the old method for others that will take time to let go.

But for others after super power we will be glad to test and use it as soon as possible.

[bfvietnam]

There's basicly a hardcoded class derived from a base material block class, that's implemented for each type of material block, in YafRay. A material block does it's math by asking it's children to give their output. These children at their turn ask their children for their output, until the tree ends.

So when you evaluate a material, you recursively travserse your node tree from the material definition at the root, and work down to all the children until you reach the leaf nodes and formulate a result on the way back up the node tree.

Well yeah this is essentially my idea, but the ndoes are graphically boxes.. Like in a flow-chart and the children are also boxes, and the orientation is ree-like with arrows going from the parent to the child.. No cycles..

Seperate fromt eh idea I've been elaborating on with each message, you could take these visual scripts and encapsulate them into modules like the ones in crafter.. Like I could make a color picker by having a node that represents the color box, and a node that represents one slider, and another.. Then to connect these with nodes that represent conditionals and looping-constructions like fors and whiles.. Then graph expressions that generate the RGB representation of the sliders or picker into something another module in crafter could use.. This another idea that could be addressed after dealing with how a user expresses their ideas in a language for these modules.. A graphical language, not a text-based one.

In the previous messages I give a model for this.. A flow-chart like language.

So the shader blocks diagram at render time is converted, well converted, not even that. The shader diagram should be a visual representation of an instance of a class that has the code in it. I don't think it could be any faster.

Well you know from working in C++, a class is a blueprint, object is the instance of the class blueprint.. In the implementation of a language, you can have a class defined for every command-type (not talking about the working structure but the language but the parts of speech that are used to define how you express ideas in it). The shader is evaluated from the top node to the bottom by calling methods on the child nodes that recusively call their child nodes, with the resulting solution to the shader passed up the tree to the root node. This may be efficient or may not for runtime.

The user can define a shader at design-time.. Then when the user is happy with the shader, she could have that compiled down to something that's more efficient by reducing the tree to inline code, something like a byte-coded language like java JVM bytecode or a assembly-style language, something that is close to the way the machine actually executes stuff, without the overhead of recursive function calls..

You can reduce a tree-graph based script to a byte-coded program (or a fragment shader, in this case ) by having the evaluation of the tree be a program (not an evaluation fo the script).

compilers and cross compielrs are very close to interpreters when it comes to parsing a script and converting it to a intermediate tree form. however, how that tree is evalauted and what results is how the two differ, interpreters process input from the user and generate output based on a script, compilers generate another script to be executed by some other machine. A compiler is like converting a script in one language to another. An interpreter takes a script and evaluates it directly. But both can use an intermediate tree-based structure, and that tree based structure can be made visual. How would you visualize a C program? How do you do that in paper, can that be made into something someone can use without using C. I'm saying yes, make it liek the tree that is the intermediate form between parsing a script and evaluating/compiling it . You evaluate with an interpretter, you convert with a compiler, but they both use the same intermediate form, or they can. and that form is a tree, a graphical representation. A graph.. .


For now, you could have the tree evaluted in the render engine..
And later on you could just send a compiled object, or plugin, that the render engine could use, without using two different languages and without using an interpreter and a compiler.. But start simple (interpreter) and go complex later (compiler).. You wouldn't even have to do it, you could leave it for someone else to do and put down a design blueprint that says "this is how it can be done, and this is how I want it to go".. You are working with a high-level design at this point.. Huh? But in open source it will grow regardless of what you want, but if you lay down a framework of thought, it keeps future develoeprs from thinking "okay what now.."

Anyway, don't think there should be an intermediate shader language, that would only slow things down. And I think everything should be made possible by simple blocks. The math itself will be precompiled inside blender. It's just functions asking other functions their output.

Okay.. Well I something like that.. I mean the intermediate language for most languages is a tree, so why not give the users access to this tree to program with, rather than giving them a text based language (like python). It could be very simple visually.. But I think it could be reduced with the addition of a method of grouping. The idea is to make it visual and easy to diagram.. This way you are avoiding the pitfalls of text-based languages : "syntax errors", which are really when the parser can't figure out hwo to interpret some character symbols that it didn't expect.. In the node-based or graph based language, the errors would be less granualar and more like "missing blocks".. Like "you have a missing incrementer in the for loop". So the user would just add an incrementer block and set it to increment by one.. Rather than having to deal with "expected statement in line 15"). The problem with most computer languages is the interpretation of text into semantics.. So why use the text at all.. That was the idea behind my previous messages.. But it may be simpler to just represent the commands or nodes that are useful in making shaders than creating a whole programming language.

The idea was just to make it accessible to the users.. I would suspect that maybe 10% of the blender users have some form of dyslexia that even makes them shun programming languages, but that doesn't mean they can't program, it just means we haven't a language for them to use that is more suitable to them. By having a node-based language it makes programming shaders more accessible to others who think visually with boxes and strin, for instance..

Is that what you mean? Are you suggesting an internal kind of way to handle the maths of a tree based system?

Make the internal model accessible graphically to the users to program with.. Almost one to one.. If you don't make it one-to-one, you will ahve to deal with the complexities of cross-linked nodes and problems with representation and the actual representation. I think the big problem with object oriented design, the way it was presented to commercial developers is that is allowed for commercial developers to "hide" their implementation, not for the purpose of protecting the users from the implementation, but to protect the commercial developers from competitors, by implementing something that changes the way users think and not about giving them tools of thought that they can reuse anywhere they go.. Microsoft for instance has a tendency to change the language so that users of Microsoft tools can't talk to users of Linux tools, Java tools, etc.. Either they change the spoken language, or the programming languages, or the way the tools connect (protocols, container formats, function libraries, tool sets). Its also the way that patents push program design.. It just results in a mess of protective indirect reasoning that just ends up perpetually leaving users in the dark.

Good for vendors (like Mcirosoft), bad for users.. Why not just give the users to the actual structures.. It would enlighten them on how to think about languages, it would give them the basic tools to do whatever they want, if its in open source (your package) it could well become a general programming language. For now, shaders, maybe next a competitor for PHP or perl, maybe after that something more.. But you shouldn't have to deal with anythign outside the realm of shader languages. I'm just saying that it has that potential!!

Argh look at what you made me do! This must be my longest post ever! If you want to help, please do! I think it's quite a lot of work.

I think I'll start off with a simple thing... making a new space type in blender!

Sorry.. I haven't the greatest way of expressing myself, it just comes out this way because I think as I type.. Some have better ways fo organizing thought, I have an objective model in my head that seems good until I talk about it, and then it kinda changes form.. So if I don't sound consistent, I'm nto making up somethign different everytime.. Its like I'm chipping away at a stone trying to approximate a sculpture but I haven't a verbal way to get at that without talking a lot.. Rome wasn't built in a day..

[wumamor]

wow TY wavek i like crafter but have not been able to use it as yet with the plugin version of yafray but, if its integrated into blender, you can bet ill be one of the first in line to test it i have worked in maya, (poor visual interface imho) 3dsmax, (very well done visually but you cannot really see the nodes and how they interact) and blender which is imo, very constricted and doesnt have the texturing features that a 3d app of its calibur needs. granted, blender users are able to make stunning pictures and animations while using this interface, but think how much MORE stunning they would be if the texture interface did not hinder the creativity.

bfvietnam: to you i put this.....
HELP WAVEK INTEGRATE CRAFTER!! if you can and would be so kind because it seems to me that you have a very good understanding of how visual shaders and the languages associated with them should work.

well anyway ty for the quick responses