crafter-blender integration

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

bobthevirus
Posts: 0
Joined: Wed Jun 25, 2003 7:11 am

Post by bobthevirus »

The thing is, the XML only has to be parsed once per matarial - at the point where it's being passed on to the renderer.... or converted into the internal format... My impression of an easier way of doing this is to build up the pathway that variables will take at this stage, with each <shader></shader> being represented as an object (maybe even as the library/sDNA stuff), and having some simplified (and linear) way of getting the variables when another <shader> object asks for them - buffering computed variables (ie - all internal variables are global, and if !NULL then they haven't been computed yet, else that is thier value).

Then, when the renderer gets to the spec part of it's calculations, it looks for the <spec> object, which calls for variables as needed. This might be rather slow - so it would pay for us to think about things at this level than higher up...

Your talk about the sliders has got me thinking - the gui parts don't need to be intgrated into the <shader> at all, but simply be another block type that is called from the <input> of a shader method. In this case however, grouping becomes especially important, as the user wants to see the whole phong shader with all its variables appearing to be controlable internally - a single box, with given inputs, and R,G & B outputs - hmm, maybe at the lower GUI level it should appear as

<variable name="max_spec">1</variable> ----> <slider name="spec" label="specularity" default="0.8"> ----> <phong>...................

where the connections are the splines, and the slider has one input and does an input*fraction_value_of_slider calculation, and one output that goes to the spec input of the phong block - this way, the spec could be controlled by whatever you want, by replacing either the <var> and/or <slider> blocks with whatever you want. To the end user, all this would be hidden, unless one chose to edit the phong block, in which case this would appear. (the end user would only see a slider that the GUI recognises gets its max value from the <var> block, and so treats it as a slider from 0 to that value - if the user copied parts out of this block, it would revert to 0->1, because it is effecting a value that is visable.)

Maybe XML isn't the best language to represent this as - we are letting ourselfs get bogged down by semantics, where we should be trying to figure out "conceptually" how it would work... I think what we need is something that:
a) Takes 0 (or more) named and typed inputs
b) Does some basic maths or calls an existing library to get or manipulate data (including getting from gui's
c) Outputs 1 (or more) named and typed outputs

The casual user can take these basic blocks, group them, and, not realising that they include other blocks that pull in data, string them together to make thier shaders. People with some programming knowledge could make library blocks, and "bobthevirus'_1337_skin_shader"'s, which artists could incorperate into thier design, only seeing the relevent slider inputs and a colour output.

Does anyone know of a (scripting) language that better represents the flowchart style?

I agree about the maths thing - my way is probably too low-level.

More thoughts to follow tomorrow, and when my computer is finally back up in running condition, I'll make some diagrams of the concepts that I have discussed, before realising that It Won't Work.

bobthevirus
Posts: 0
Joined: Wed Jun 25, 2003 7:11 am

Post by bobthevirus »

I've been putting some serious thought into this, and I came up with a few brainstorms - my head hurts now (-;

The main problem we have been running into before now is that we have been combining the internals of the blocks, with the way they are linked... I have a messy example of a way of seperating them - I can't think at the moment if it would fit into xml or not...

Basically say each block is a script with defined inputs and outputs like so:

Code: Select all

in built blocks:

b_slider
	inputs: 
		int max
		(int min = 0)
	outputs:
		int result	//this is max*the gui value

	usage:
		slider pre_phong{
		 inputs {
		  max=1;
		 }
		 //outputs are automagically made
		}

phong

library blocks:		
add_col	//note that this is just a representation - have to see how colours are stored...
	inputs:
		int a	//the first colour
		int b	//the second colour
	outputs:
		int result	//a+b or 255, whichever greater
	prototype:
		block add_col{
		 inputs {
		  int a;
		  int b;
		 }
		 result = max(a + b, 255);
		 outputs {
		  result;
		 }
		}
	usage:	//the usage is basically how it connects up
		add_col reds(a = blah.blah, b = thing.thing)
mul_col
div_col
sub_col
phong

not sure if we need a base type RGBA, but:
add_cols
these are not very tidy examples, but they work sorta.... of course, there are about 50 or so others that i have left out... Now what we have, is the graphical elements to link together in the gui, which creates data stuctures in the form:

Code: Select all


sample script - not finished, but adds the ramp and phong and outputs to spec

out.spec spec(rbg = final_adder.result);
lib.add_cols final_adder(a = ramps.result, b = phong_comb.result);
lib.combiner phong_comb(r = phonger.R, g = phonger.g, r = phonger.r);
lib.phong phonger();
lib.ramp ramps();
basically, this script defines where each block gets its inputs from.... the renderer goes to the spec block and asks for the rgb output (which i have made into a type, to make things easier), the spec block asks the final_adder block for its single rgb output, which is created from a combination of the phong shader and ramp shader...

Obviously it might be easier to just have all internal stuff rgb unless you use a splitter, and the 255 max for it is entirely arbitary, and lots of other things - Is this idea worth following up? the blocks themselves could be defined in xml, while the linking could use a pseudo-scripting language, or whatever... Also in the linking part, groups could easily be defined - they would be ignored by all but the gui, and if you want to export a single part.

The difference in speed between this and the current method would probably be O(1), or O(n), where n is the number of pixals - ie, a 800*600 image that now takes 8 seconds would take 10, and that takes 300 seconds would take 302 (of course, your scripts could be optimised to take less - by ignoring reflection for z > 100 or something.... something that isn't as easy now....)

Note that I haven't looked at renderman yet - I want to keep completely away from being influenced by outside forces, until I am happy we have the best method we can come up with - then I will look at that, and others, and see what we have the closest to...

What I want to be gotten out of this post, is a nudging fairling in the back of our minds that splitting the blocks and the linking is by far the simplest and best idea...

G

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

Post by bfvietnam »

bobthevirus wrote:The thing is, the XML only has to be parsed once per matarial - at the point where it's being passed on to the renderer.... or converted into the internal format... My impression of an easier way of doing this is to build up the pathway that variables will take at this stage, with each <shader></shader> being represented as an object (maybe even as the library/sDNA stuff), and having some simplified (and linear) way of getting the variables when another <shader> object asks for them - buffering computed variables (ie - all internal variables are global, and if !NULL then they haven't been computed yet, else that is thier value).
Well scoping, however its done, is the way to go. It keeps spaghetti code from happening.. I mean it should be obvious where the inputs are coming from and outputs are going to.. But some things will have to be implicit, like stuff that renderer and sccene provides automatically.. Its like if you do math in C you need the math library, but its better just to have it automatically included so you don't have to remember to include it, then you can just come to expect it to be there.. One way to get away with scoping with global variables is to use paths.. Which is what I think you are saying.. Like in Unix, files are not stored in a hiearchical system, they are really in a flat file system (unix sees all files as just a a pile of data), the paths are just long filenames.. And a path translates to a pointer that points to the first block in the file.. When you go into a directory, you are really just partially defining the filename. That's why its so easy for unix to process paths like "/*/tmp/john/*/*.txt" Each variable could be reference using a path like::

Scene/Shader/Object/Variable

or more simply..

Shader/Variable
Then, when the renderer gets to the spec part of it's calculations, it looks for the <spec> object, which calls for variables as needed. This might be rather slow - so it would pay for us to think about things at this level than higher up...

Your talk about the sliders has got me thinking - the gui parts don't need to be intgrated into the <shader> at all, but simply be another block type that is called from the <input> of a shader method.
It can be, But I'd like in a visual interface to reduce clutter, and
having the sliders implicit in the definition of all blocks means you
could reuse it a lot everywhere.. It depends on how youa re coding this.. How I would do this in C++, is to make a super class that has the slider
definition and the control methods.. Then every block that inherits from that class definition, will implement the slider already, without knowing it..
They could override the method and assign something else to the inputs.
Internally for every input there would be a float, that multiplies by the
input.. The slider just adjusts this variable through and accessor function..
There is no such thing as a variable search.. What I mean:

Code: Select all

class common_functionality {
   // this class does not implement "set_a" (!?) 
  slider  s;
   function slider()  { 
       _self->s->update(); 
       _self->set_input(_self->s->retrieve_value());   
   }
}
class shader implements common_functionality{
   // this one does.. 
   float a; 
   function set_input(float f) {  
      _self->a;
   } 
}

shader = new shader(); 
shader->slider(); 
A method search should execute the "slider()" and slider()
calls set_a() in the shader implicitly.. If there isn't a "set_a"
implemented there it calls the parent "common_functionality"
before giving up.. This means you could have many objects
inheritting whatever is in common_functionality class and
would obtain that functionality without knowing much about it, but the classes would have to implement some accessor methods..
In this case however, grouping becomes especially important, as the user wants to see the whole phong shader with all its variables appearing to be controlable internally - a single box, with given inputs, and R,G & B outputs - hmm, maybe at the lower GUI level it should appear as

<variable name="max_spec">1</variable> ----> <slider name="spec" label="specularity" default="0.8"> ----> <phong>...................

where the connections are the splines, and the slider has one input and does an input*fraction_value_of_slider calculation, and one output that goes to the spec input of the phong block - this way, the spec could be controlled by whatever you want, by replacing either the <var> and/or <slider> blocks with whatever you want. To the end user, all this would be hidden, unless one chose to edit the phong block, in which case this would appear. (the end user would only see a slider that the GUI recognises gets its max value from the <var> block, and so treats it as a slider from 0 to that value - if the user copied parts out of this block, it would revert to 0->1, because it is effecting a value that is visable.)
Yeah you could do it internally, but it seems like more work.. Have
an internal slider..

If you want more sliders internal to the block, you could use them there, because they are just objects, and if you need them external, you could use them there.. its a matter of taste.. I just figure it would be easier to have a slider for the input and a slider for the output implicitly..

The following is a description this idea, how to do it in XML..

--------------------->8------------------------>8---------------------------

In the XML it could look like this:

Well the beauty of it is it could be implicit in the definition of the
variable inputs that are floats or ints.. With booleans it wouldn't make
sense to have a coefficient ( http://dictionary.reference.com/search? ... cient&r=67 ).. ".5" is maybe? .99 is almost true? Ha! Well the idea is that it would be a gui feature, but really why would someone care about defining a variable as being controllable by a sldier, it would best be something that's just given for free.. Reducing the need to define it.. Then if you really wanted to be
explicit about what had sliders or not, you could add to the slider a toggle switch to the slider and have its methods check for a global preference of
"default to no slider" with option to add a slider to blocks, or default with..
The idea is that you wouldn't put it into every block, it would only exist in one place.. I mean I've talked about it more than it deserves.. Its that simple.. It makes sense to have a coefficient on each input, but the coefficient is betwen 0 and 1.0.. So, in XML it would look like this:

Code: Select all

 
<variable name="max_spec" coefficient=".314">1</variable>
Which would translate to .314 * 1 = .314 . You could allow it to have values outside of 1.0 to serve as a multiplier (13 * 1) or as a negation of the input (input * -1).

Now if you wanted to control the existence of the slider or not, you could do that by maybe adding another attribute like:

Code: Select all

<variable name="max_spec" coefficient=".314" noslider="true">
or

Code: Select all

<variable name="max_spec" coefficient="none">


or simply by not even defining the coefficient attribute..

Code: Select all

<variable name="max_spec">

Now the user of crafter could always just re-establish the slider in the interface, by toggling it back-on which would add it back the next time the shader is exported to xml.. But if you want to force-it on the user (so only things that make sense have sliders), I'd just add another attribute to specify this.. Another thing you could do is define another kind of tag that
can't have a slider.. You could even have several different kinds of input tag types like..

Code: Select all

<noncoeff_input name="max_spec">

<slider_input name="max_spec" range="10.0,-10.0">


Note, if you wanted to have the slider increment in integer values,
you could remove ".0" from the range.. Its a little interface trick..
To flip the order orientation of the slider, just flip the definition of
the range eg. "-10.0,10.0" . This is not so strange, OpenGL defines the direction of a face normal by direction vertices are defined in a face.
Like a face defined 1 2 3, has a normal pointing opposite of a face
that is defined 3 2 1.

Its a way to allow a coder to express what they want without being explicit.. Like "upper=1.0, lower=-1.0" or "upper=-1.0, lower=1.0".
Now we could turn on the explicit, easy to read language version of
the XML, or we could reduce it to something thats easy for a coder
to use on a low level.. But the user or coder still should be able to use the Crafter interface without having to deal with XML.. Its not going to be hard.

Internally a "noncoeff_input" and "slider_input" are kinds of "input",
just elaborations on what an input type is.. So internally they may either be seperate classes, or just methods on the class that handle input..

--------------------------8<-----------------------------8<--------------------
Maybe XML isn't the best language to represent this as - we are letting ourselfs get bogged down by semantics, where we should be trying to figure out "conceptually" how it would work... I think what we need is something that:
XML is fine.. Its almost a syntax free language, which is good, thats why people use it, its easy to read and easy to configure, and easy to parse.. Its hiearchical, and can be used to represent most abstract data types like trees, lists, graphs.
a) Takes 0 (or more) named and typed inputs
b) Does some basic maths or calls an existing library to get or manipulate data (including getting from gui's
c) Outputs 1 (or more) named and typed outputs
---------> 0..* [ block ] 1..* --------->


Yeah, this is okay..
That means if you have a block, it must have an output, but doesn't necessarily mean it has to have inputs, so blocks
can be controllers of some blocks without having to process inputs from other blocks.. You could even have blocks that represent system state like a block that generates the current frame number as an integer output.. , or take input from the GUI, or a library.. Blocks can contain expressions in the form of blocks..


Now there is no reason why the inputs and outptus have to be strongly typed.. I mean, in PHP for instance, there is no reason to have integers
because the language handles the data-typing based upon how the variables are used.. Perl is this way too.. Most interpretted languages are..
But if the crafter shaders are to be compiled (to be made fast) the data types will have to be defined explicitly.. The problem with defining data types is that it makes connectivity of the modules less intuitive for the users.. I mean you will have users trying to stick squares in round holes, and really that should be possible.. If the blocks are designed to assume some amount of hacking of this form, the inputs can be overloaded
such that the inputs and outputs can kind of think for the user about what they really want.. Like hooking a scalar output to a RGB input, which
result in split of the output three ways, into teh R, G and B. But in the XML it could look pretty strange.. Like:

Code: Select all

<input type=rgb name=color><ref to="this" from="checkerboard.value"></input>
Implicitly this gets converted to

Code: Select all

<input type=rgb name=color>
<ref to="r" from="checkerboard.value"/>
<ref to="g" from="checkerboard.value"/>
<ref to="b" from="checkerboard.value"/>
</input>
XML has a tag called a singleton, I think that's what its called,
and its just <tag /> , instead of <tag></tag>
The casual user can take these basic blocks, group them, and, not realising that they include other blocks that pull in data, string them together to make thier shaders. People with some programming knowledge could make library blocks, and "bobthevirus'_1337_skin_shader"'s, which artists could incorperate into thier design, only seeing the relevent slider inputs and a colour output.
yeah, blocks can nest blocks.. But the blocks should only need to be defined once and just instanced thereafter, each instance having its own state.. So three instances of the same block could be nested in
each other. Configured, and stored in that configuration, loaded back..

The complexity of the top-most (zoomed-out) set of blocks
should be simple enough people can understand them, while sub-blocks
are more and more specific to the shaders and less to the general
use.. But if its not too complex, it may be okay to allow blocks at high levels to exist in sub-blocks, to allow some reuse and grouping of
effects. Simplifying the look of a shader at the higher levels.. Like if I
designed a chrome shader and later wanted to apply it to a bump map,
I could as a casual user do something like this:

Code: Select all

[ chrome ]  ------> [ bump ] ----->| surface 
Or as a coder do this:

Code: Select all

------- > [   [ chrome ]---> bump  ] -------| surface   
That is, in the first case, you have a chrome reflection map and bump mapping block with both being connected on the crafter desktop..
Or I could embed the chrome shader in the bump block into a combined
shader ..


Does anyone know of a (scripting) language that better represents the flowchart style?

I agree about the maths thing - my way is probably too low-level.

More thoughts to follow tomorrow, and when my computer is finally back up in running condition, I'll make some diagrams of the concepts that I have discussed, before realising that It Won't Work.
Okay..

I was going to suggest Lisp, but I wouldn't even touch that with a ten foot pole.. http://en.wikipedia.org/wiki/Lisp_programming_language

I think XML will be fine.. It can represent Lisp.. But the checkerboard shader might look like this in LISP..

Code: Select all

 
(defun checkerboard (x y z) (xor (% x 2)(xor (% y 2) (% z 2)))) 
But don't ask me how to apply that.. It might look like this,
considering (x,y,z) = (3,4,5).

Code: Select all

(checkerboard (3 4 5))    
results in

Code: Select all

(xor (% 3 2)(xor (% 4 2)(% 5 2)))) 

which is 

(xor (1)(xor (0)(1)))

which is 

(xor (1)(1))

which is 

(0)
So the result is 0 of (3,4,5)..

But you could also write an application of the
same shader to a whole list of inputs:

Code: Select all

(apply checkerboard (input1 input2 input3  input4))
Given that each input is an (x,y,z) pair..

I know it looks ugly, but the mantra is that it has
not bugs.. Its impossible, because it has no global variables..
Its purely recursive and nested.. A lisp program has only one method of
output (return it as a value).. Meaning you don't use pointers.. Its
also Richard Stallman's
language of choice.. Its what he wrote Emacs in..

Image

And a quality of this is supposedly you can evaluate lisp in emacs,
or you can nest emacs editors in lisp code.. Don't ask me how they do this.. Its just one of those languages that if you haven't tried it, you should, it will turn your brain around..

An easy way out is just to use Python which I believe supports
Lisp primitives.. Lisp can be made easy for users and it can be represented graphically pretty easily.. And you can represent the
structure of LISP in XML very easily, in fact some people think XML is a
LISP ripoff..

http://c2.com/cgi/wiki?LispVsXml

Internally LISP is heavily stack dependent.. But it forces you to reference stuff incrementally.. It also forces you to reuse stuff because its the only way to get stuff done.. Its not an evil language, its just a different way of thinking..

Before I say anymore, its been years since I've used it.. In college
I got tortured with double virtual infinite arrays in sasl ( a lisp variant)..
An infinite array is an array where the last element is a function that creates more elements be evaluating its containing expression and generating more items on the end of the array). You could use Lisp
fairly easy for image processing or processing languages, 3D manipulations, L-systems (tree sculpting tools), etc.. In fact I think Autocad uses a form of LISP for creating modelling tools..

Anyhow, each module in crafter could contain something like LISP,
that could be expanded into a graphical form or into XML.. I mean you can use lisp if you are worrying about how to represent things like for loops ..
If you need help, I can draw up some diagrams of various way to implement the internal language or maybe do some coding myself.. It
would be fun.. I just haven't got a copy of Visual C++ to do this with..

Another language that is graphical is the way IC boards are made, I mean open up your computer and look at your motherboard.. That's a language that is graphical and its nested... It has inputs and outputs.. If you want to learn that one or use it, I know something about circuit design and how computers work..

I don't think it will be that hard.. Just needs some clever engineering
and design.. but its tough for me to describe my ideas with text.. I
think I will work on some diagrams too...

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

Post by bfvietnam »

Well I don't understand shader stuff, I understand conceptually but I've never written them.. I just have books on it like "Texturing and Modelling - A procedural Approach, ISBN 0-12-228760-6, it was co-written by Musgrave, Peachey, Perlin and Worley, the shader greats).

I can say, from what I've seen, Renderman is a C like language, its
just that its designed to do shading..

This is what the book says about it :

"It is a descendant of the shade trees system described by Cook (1984).
The syntaxof the languages is C-like, but the shading language contains built-in data types and operations that are convenient for computer graphics calculations, for example, data types for points and colors, and operators for common vector operations. The shading language lets us program any aspect of the shading calculations performed by the renderman renderer: surface shading, light source description, atmospheric effects, and surface displacement. Shading parameters can be made to vary across the surface to generate procedural texture effects. These could consist of variations in color, transparency, surface position, surface normal, shininess, shading model, or just about anything else you can think of. "

This is how bump mapping is implemented in renderman:

Code: Select all

float f; 
point PP;
F = /* fill in some bump function here */

PP = P + F * normalize(N);
Nf = calculatenormal(PP); 
Nf = normalize(faceforward(Nf,I));
some of that looks like implicitly defined variables.. But this book
covers things like how to make brick textures with renderman..

If you want, I have an old illegal copy of BMRT sitting around..

I guess there was source code with that, but I doubt I have it..
Pixar forced BMRT designers to sell their mindshare to NVidia,
that's where Cg came from..

http://www.renderman.org/RMR/Shaders/BMRTShaders/
http://www.rendermania.com/downloads.shtml

You can get BMRT here:

http://cgg.unibe.ch/resources/3d/
http://cgg.unibe.ch/resources/3d/BMRT2. ... t.zip/view
http://cgg.unibe.ch/resources/3d/BMRT2. ... ar.gz/view

Money_YaY!
Posts: 442
Joined: Wed Oct 23, 2002 2:47 pm

Post by Money_YaY! »

wow this is getting confusing. It neads a wiki or something to better organize it.

bobthevirus
Posts: 0
Joined: Wed Jun 25, 2003 7:11 am

Post by bobthevirus »

My comp works! - If someone starts the wiki, I'll put my ideas, and what I understand of bfvietnams ideas into it... after work (-; else I'll start if of course

There are several divisions we can break it into...

Internal representation to XML to Crafter
My tiny blocks that do bugger-all vs. bfvietnams bigger block with implicit sliders
Access from the renderer - how does the render call the functions defined by the blocks...

Things that should be fairly straightforward:
A list of implicit variables... b_x, b_y, b_z, b_normal, etc etc...
A stucture for inbuilt functions - a naming scheme and what they do
Related to that, the beginings of a library scheme
A comparison of existing yafray/renderman/cg/whatever languages - only as much as is needed
other stuff...

One thing that I really want to push (again) is keeping the blocks and thier connections seperate at the XML and Crafter levels - and possibly at the renderer level also...

I'm convinced about using XML for discription of the blocks now - My funky code could be represented by XML easily... Not so sure about the linking... but we'll see...

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

last tangent..

Post by bfvietnam »

Money_YaY! wrote:wow this is getting confusing. It neads a wiki or something to better organize it.
(as the subject says , this is hte last I say on this tangent I got off on.. I don't know how to tie this in to the future implementation of crafter, but
I know there is a pattern here somewhere, but I have confidence in this stuff because I took courses in it, but I haven't touched this stuff in a long time.. )..

Well it doesn't have to be lisp.. It can be python..
But the main reason why I thought of lisp is its the
simplest language syntactically, it has no bugs by definition,
the worse that can happen is your computer runs indefinitely in a recursive loop, but you can guarad against that.. But your computer shouldn't crash unless the version of lisp you are using actually does recurse (recursion uses stack space). And from what I recall of
computer graphics courses, a lot of computer graphics algorithms
are describeable as recursive functions.. Also lisp seems to
encourage reuse.. Lisp is kinda like the nanobot of computer
languages. And to represent it graphically, it would look like one of
those russian dolls (doll contains a doll contains a doll, etc..).

http://www.braznet.com/david/raytracing/dctrace.lisp
http://www.cs.caltech.edu/~boris/hw1/html/.index.html
http://freshmeat.net/projects/grt/
http://www.braznet.com/david/raytracing/

Now it Crafters modular language doesn't have to be like this, I just thought it would be worthwhile to consider since its a fairly
simple language, even though its hard to program in.. It like XML
has a very simple syntax and is extremely easy to parse. It could
also be easily represented graphically, without the use of lines,
just boxes within boxes..

However, I believe flowcharts can be represented for any language..

Even digital electronics is sort of language.. But its heavily parallel,
and you don't find very many programmers who know how to
make them.. But Crafter reminds me a lot of a circuit diagram..

In digital electronics how you control the pacing of things is to
use a clock.. Every component on the circuitboard performs operations
according to a clock. If Crafter was to implement something like a circuitboard, you could pass your inputs in at one end of the
diagram, and retrieve the outputs on the other side.. In fact you could even probably simulate actual graphics routines as they are
on the graphics cards, in a parallel nature..

Here is a web page describing a way (it seems) to simulate digital circuits with lisp:

http://mitpress.mit.edu/sicp/full-text/ ... ode64.html

Image

A and B are inputs, S and C are outputs.. The logic here is written in
code like this:

C = (A & B);
E = !(A & B);
D = (A | B);
S = (E & D);

But to get this correct you have to run it in this order..

This circuit is run in parallel, so if you put high and low
voltages on the A and B.. The results of this logic is:

A = 1, B = 0;

C = 0;
E = 1;
D = 1;
S = 1;

So C = 0 and S = 1;

(Note: C stands for carry, and S stands for sum, this is the logic for
adding two bits together.. If you have 32 of these you can make a 32-bit adder.. Which adds numbers like 4753485 and 340539 in parallel, the
length of time it takes electricity to go from the inputs to the outputs.)

In binary adding is like this..

Code: Select all

0 + 0 = 0 
0 + 1  = 1 
1 + 0  = 1
1 + 1  = 10 
So the logic gate above should look like this..

Code: Select all

A B S C
0 0  0 0
0 1  1 0
1 0  1 0
1 1  0 1

This may look complex, but your computer has millions
of these components.. But most are just replicated..

Now these gates need not only be boolean operations.. They
could be something much more complex, but it gives you
some idea how to design this shader language..

The only reason I am able to read these charts is I aced
digital electronics.. But I see in digital electronics schematics
and lisp, similar capabilties to what Crafter could do with shaders..

Both Lisp and Digital Circuit design create components that
are heavily parallel and reuseable.. If you can define a shader
as in a schematic like this, you could thread the shader easily and
even parallelize it across clusters..

I just feel there is a pattern to this that could be applied to shader
design.. And the beginnings of a completely visual language..


I did a search on google for "circuit shader" and found a number of interesting results, including the Pixel V3 language for directx 9:
http://www.google.com/search?hl=en&lr=& ... tnG=Search

But its justa coincidence, it doesn't seem like anyone has
gone this direction with shader programming..

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

Post by bfvietnam »

I'm not completely familiar with shader languages, I just understand the
concepts.. So you can easily lose me in the math of it.. I've always been pretty good at managing structural concepts.. I mentioned in the last
message I aced digtial electronics, few programmers do.. But I failed
analog circuits and physics terribly, and flunked calc 2 several times.

bobthevirus wrote:My comp works! - If someone starts the wiki, I'll put my ideas, and what I understand of bfvietnams ideas into it... after work (-; else I'll start if of course

There are several divisions we can break it into...

Internal representation to XML to Crafter
My tiny blocks that do bugger-all vs. bfvietnams bigger block with implicit sliders Access from the renderer - how does the render call the functions defined by the blocks...

Things that should be fairly straightforward:
A list of implicit variables... b_x, b_y, b_z, b_normal, etc etc...
A stucture for inbuilt functions - a naming scheme and what they do
Related to that, the beginings of a library scheme
A comparison of existing yafray/renderman/cg/whatever languages - only as much as is needed
other stuff...

One thing that I really want to push (again) is keeping the blocks and thier connections seperate at the XML and Crafter levels - and possibly at the renderer level also...

I'm convinced about using XML for discription of the blocks now - My funky code could be represented by XML easily... Not so sure about the linking... but we'll see...
Well you can have the sliders seperate from the blocks or internal,
it doesn't matter, I just thought it would be nice if they were builtin to the
definition of how the inputs and outputs work.. It would reduce the
number of blocks on the screen.

As for the shaders, I think it would be good to get some idea fro the concepts of how different shader languages structure shaders..
Then to steal the concepts and formulate them into modules that
can be connected together.. There is no need to code each module, the idea is to have some building blocks from which other shaders can
be made.. Like a "Step Function" clock, and a noise function block,
marble block, musgrave block, matrix multiply block, etc..

And then there needs to be a way to create complex functional
blocks that can contain those smaller more basic functional blocks..

Give me every shader concept you know, and I can make a block with inputs and outputs.. I bet I could derive from that a method of synchronizing the inputs/outputs.. POossibly in a way that is non-recursive and parallel..

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

BTW

Post by bfvietnam »

By the way, you might want to look at this word document,
it describes how to make a bumped map shader using
logic gates..

http://cis.k.hosei.ac.jp/eng/facl_d/project/BUMP.DOC

I guess this is for people that make shader logic on graphics cards..

bobthevirus
Posts: 0
Joined: Wed Jun 25, 2003 7:11 am

Post by bobthevirus »

http://wiki.blender.org/bin/view.pl/Ble ... dMaterials

Started the wiki page, everything needs to be filled out more... The comparison to eletrical circuits is very apt...

Anyway, I had a look at lisp, and it is very must like what I was looking for, except now that I have seen it, it doesn't seem to be quite as good as it could have been /-: So, is it worth continuing the discusion at this stage, or would it be better to say "we'll stick with XML, unless renderman or something else turns out to fit into the blender paridigm"?

Anyway, my next port of call is to apt-get install gcc, all the blender libs, kdevelop, etc, and have a look at the code... At the stage where I give up in disgust, It would be great to get some help to give advantages and disadvantages of all the existing sytems on the appropriate page on the wiki...

wavk
Posts: 126
Joined: Wed Oct 16, 2002 9:58 am
Location: The Netherlands
Contact:

Post by wavk »

Okay, so I had this weird moment in which I actually thought I'd pick up coding again. I'm sorry to disappoint you guys, but in the past couple of weeks I remembered why I wasn't coding in the first place. I just have too many other things to do. I only (tried to) code two times and just couldn't get into it anymore, it's too daunting. This project started when I was freelancing/doing very little ;) And it's just too much work for me to finish it.

But I see a lot of great discussion going on here, I hope you guys or someone else will implement this some time, or at least keep the ball rolling.

So don't expect anything big on this project from me, sorry if I raised false hope.

Wybren

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

Post by bfvietnam »

bobthevirus wrote:http://wiki.blender.org/bin/view.pl/Ble ... dMaterials
Started the wiki page, everything needs to be filled out more... The comparison to eletrical circuits is very apt...
Yeah the wiki looks pretty good.. As for the circuit and lisp stuff,
it was really just there to give some context for how visual languages
can be used to describe things like logic, and languages that work like
how XML does without being structured in a C like language.

Lisp is very recursive, and recursive languages tend to make
most coders cringe, because you can spend all day looking at a
recursive function and not know how its going to perform..
Unless you try it out, and tweak it until it works..

Lisp tends to reuse stuff before and the lisp language probably can be changed to be easier to use.. Like, for instance, nobody ever codes in Pure Lisp, its to limiting to not have access to global variables. So, there might be an offshoot in crafter or some derivative project, like (god forbid, anyone in the lisp community should consider this considering the "tabooness" of this subject) Object oriented lisp..

Where you have lisp classes, and a semi-global scope which the lisp code works on.. And the simple list handling approach would still be accessible, or offer a method for the lisp code to access variables in the class scope.. So I've essentially broken the rules of lisp which is not to have access to global variables, which supposedly makes code really buggy and not define structures outside of lists like class structures and methods of referencing other stuff with scope, use of imperative coding practices.. And if you look at "common lisp", you find its impossible to refuse imperative coding practices even in the confines of the structurally perfect programming language, as lisp is.. So Crafter need not use any
of this, but to say that we don't need C syntax not a C structure, we can reuse lisp methods of code structuring and still be successful because LISP did it without hardly any syntax..

Anyhow.. This provides a context for how the low-level specification and structing of code will look.. It has to be object oriented, it has to be reuseable, it has to be easy to get stuff in and out, without having to mess with really strange methods of flow control like GOTO's and dependencies on global variables.. The purpose for the object scope is to allow many different kinds of globals for each module in the Crafter interface..

If you desire a global scope for all your modules, you could probably put all modules into a single shader (shader nesting?) and that module would act as a Union set of all the modules, and all would have access to the same scope.. Or you could have the modules subscribe to a class for its variables (via scoping methods I will elaborate on later) direct access to the variables by using scoping operators.. However its done, there needs to be a way to control the flow and the variable access in such a way the coders are forced to make something that is readible and useful..

For instance in python, the only way to control scope (like in the case of loops) is to use an indented list of statements.. So rather than using curly brackets you can stick anywhere, python forces coders to make readible code via the use of a mechanism that forces indentation.. Clever idea!!!

Whereas a hacker oriented coder might have made it really flexible, and python would have been awful to code in..

It may be the case that the actuall language that the shaders is written in is python (note later I mention how to do this in XML).. And Crafter just generates python code.. The problem though is python is a general programming language, and crafter will need a specific language, because you don't want a shader to compile to a virus, which you could conceivably write in Python (??)..

So the language must (IMHO) be designed specifically for making shaders.. Offshoots that use the crafter interface, will have languages specifically for them, like a modelling language.. And such.. These languages shouldn't have seperate and specific syntax, like you shoulding use curly brackes in one language and the other use square brackets.. The only reason other languages do that is partially due to stupdifity, enforcing the design of the language, and as a ploy to get people to purchase into commercial languages that have no right even existing outside the realm of open source (e.g. capitalistically bent languages like C#, Delphi, Mel, Visual J++ etc.).

To allow access to python scripts, there could be a predefined module type in Crafter that allows the addition of other programming languages to shaders, socket access or some form of loose binding to something external (that is practical, it doesn't have to be beautiful, just easy to do for someone who would want to do it { example, say making http calls with XML formatted messages, web guys might respond SOAP? yeah I guess, get that a web controlled shader, ha! :P } )..

THE WIKI PAGE LOOKS GRAND!!!, I think it will be quite influential in how people interpret messy discussions (like mine), and where the discussion goes, preferably not completely my way , ha! :) although I can sound pretty convincing, I'm not the "be and know all" of this stuff, just have a lot of ideas.. Which is not the root of evil, its the non-implementation of something before designing anything that is.. And the root of evil is the love of money, but this is neither here nor there.. This is why we are in open source, its all good, yeah..

Okay I will admit I'm getting wierd today, but its just because its saturday, and I saw all these ideas on an official blender wiki page .. Its best not to over think, or take all this stuff and get into analysis paralysis (see www.antipatterns.com).. As an art teacher once told me, when trying to throw about 9 approaches at doing paintings, like diptics, collages, symbolic, and cubism, he'd say "just put this in the back of your mind, don't assign whether one is right or wrong, just keep in mind this stuff exists and there are all these forms of expressing ideas, just pick whatever seems right for you.."
Anyway, I had a look at lisp, and it is very must like what I was looking for, except now that I have seen it, it doesn't seem to be quite as good as it could have been /-: So, is it worth continuing the discusion at this stage, or would it be better to say "we'll stick with XML, unless renderman or something else turns out to fit into the blender paridigm"?
To skip the following runon, yes.. Its worth sticking to XML..
Lisp was more a mind tool than a suggestion for a language..
XML is even more simple than XML, and just as potentially flexible..

Here lies an interesting discussion on why to stick with XML..
Read or skip to next dotted line..
--------------------------->8------------------------------>8--------------
Okay good (about the lisp).. Well as I mention above in my unending unformatted ramble, it doesn't have to be lisp, it can be a derivative.. What I described in previous messages is really Pure Lisp, which nobody codes in because its too limiting, but this low-level shader language can be whatever you want it to be.. Its just that lisp is the easiest to parse, next to XML.. Its very simple, you don't have to worry about it being an ambiguous syntax, like Perl is ambiguous a bit, mathematica is very ambiguous, ambiguity of a language is determined when the structure of the language (say at a function) changes based upon syntax further in a statement.. Like if I have the following code:

Code: Select all

for ($x = 0 ; $x < 100 ;  $x++) { 
    print $x;
}

of I add in that the last statement if it contains "__END__" ,
the function is to be undefined.. That's a problem of ambiguity,
or semi-ambiguity, because then you have to unparse the whole function and undefine.. It doesn't serve to be very well parseable unless you state ahead of time what your going to do.. Because that determines what the language parser can expect to parse.. In lisp, if the next character you see is "(" , you have to expectations, its probably first a function..
So you can expect to next see a word.. If you don't see a word, its not correct, and so you list "syntax error, this is not a lisp program"...
And then if it is a word, the next thing you can expect to find, is either a ")" (or its a function without any attributes), or another word (called and atom, and atom's have a single-quote, so if its not "''" then it must be
another "(" which can have either a word following it defines a function, or
it is another atom which defines a piece of data, and so on..
This is how parsers are written, by knowing what to expect next.. Adn the syntax tree,as I described in previous messages, is the way a coder can determine how to parse languages like C and operate upon them as well as a way to determine what C will let you get away with, like declaration of scope blocks without function headers.. Did you know you can do this in C?:

Code: Select all

main () { 
   int a,d; 
    a = 1;
    printf("%d", a);
    d = a;  
    { 
      int a;   /* these variables, int a, only exists here even 
                     though this looks like it would yield a syntax 
                     error, if you look at the lexical syntax tree for C, 
                      it allows this in any C parser..  Now a C compiler may 
                      not allow this, but the c language syntax will.. */ 
      a = 2; 
      printf("%d %d",a, d);
    } 
    printf("%d %d",a, d);
}
So what I'm saying here is Lisp and C have something in common,
they are both easy to parse because they have a defined structure,
that's easy to parse.. So does XML.. XML's syntax is that stuff is nested
in tags.. But you can't have a start and end tag overlapping on another
start and end tag:

Code: Select all

<start><end></start></end>
Also the whole thing has to be encapsulated in a grand tag.. Like "<code>"..

Code: Select all

<code><start></start><end></end></code>
This is well I guess all XML's syntax.. It may have others (as I'm not too familiar with XML, but this is about it, so its yet simpler than Lisp, because
nothing is assumed to be a function in XML.. The responsibility is placed on teh coder of the XML parser.. So we have to create out of that what these tags means, and how they are oriented in the language.. The attributes in teh tags act as a pseudo syntax.. Like if you don't define a attribute for a
tag.. like this:

Code: Select all

<shader>
</shader>
This should create an error, because its not specified what the name of the shader is. Which allows us to reference it.. If we instead used a nested tag
in this.. It would make parsing harder because we would have to wait until the XML parser got to the attribute tag before we respond "error in ... " .
If its put in as an attribute, this forces several things on the coder of the shader:
1. attributes should be readible (simple names, and not runons.. )
2. attributes are within the context of the tag they refer to..
3. the attributes are encapsulated in double quotes, and look wierder
if the the attribute value is spread across multiple lines..
4. force coder to use another method of specifying things like data, by use of a symbolic reference (see below)..

Code: Select all

<class name=symbolicreference>
<data name="somedata">
rjgoiejroigjeorjgoieroijgeoirgjoejrgijeoirgojerojigjeoirjgijoejogier
gergioejrogjeoirjgoejogoejrojgojeroigjoeiroigjeorijgoiejoirgjeorijgoie
eroigejrogjejigoieroigjeojrigjeoijgoijeroijgjioeiojgeoijgoiejojirjgoije
</data>
</class>
<shader name="symbolicreference::somedata">
</shader>


Just to enforce readible and parsible code.. We could consider
carraige returns in names to be "illegal syntax".. Or this could be allowed..
But at least give them some amount of indirection to do:

Code: Select all

Which foot should I aim for, and what calliber of bullet do you want?
Note in C we can write gunk like this :

Code: Select all

main(){char *crap=null;char string[]={"thisisgunky","thisisreallygunky"};
*crap=string;printf("%s",crap++);
*crap=&string;printf("%s",crap);}
C doesn't enforce good style of coding.. That's why its the hackers choice of languages (job insurance).. Its a fast language but it doesn't have to be crappy to be fast.. No C was a language, next to assembly that came at a time when memory was expensive (and a ten kilobytes could have easily gone for about a three hundred dollars or more), we haven't those constraints so why is the syntax still like this? Convention.. But good coders don't use it unless they need the speed, and even when they do,
they should make it nice so others can read it.. But when you don't have to use C, why make a language that looks like it.. Well its nice since people understand it, and its got flexible syntax... And well now we have XML which is all that without the problem of parsing.. And since there is no computing resource problems, and no problems with memory, we should be able to just enforce a style of xml, that is still parsible with any XML
parser, and is enforces a defined convention, is easy to read, and is easy to check syntax on (less problems for you).. So I think XML is
the right method to structure it, but there should be conventions within
that to make it easy to use crafter at that level, and eliminate most oscure
absues of the syntax loopholes like carriage returns where
they should be and run-ons like this message of mine.. Argh!! Look what I made myself do.. self->slap .

Note, just to keep on topic here.. Renderman's syntax was derived from C.. Why? I don't know I guess it was what they had on hand at that time and its been the usual thing to make all languages look like C.. The suggestion for lisp was not for lisp, but a inspirational talk on how you can make a successful language that doesn't look like C or use its syntax.. There is also no reason (as I said before) that the language has to be text based.. It can be graphical.. I will draw up some charts to exemplify this new language, which will probably look more hacked at first but as we discuss it it will look useable (I hope).. Code has structure,
compilers (at least recusrive descent parsers) use structured patterns that are recursive in definition, so all patterns in a script with C like syntax follow a pattern, that recursively repeats.. Lisp's patterns are simple..
CC's are complex.. XML's is even simpler than Lisp but is more readible than lisp and C combined.. We can go further with this by enforcing
guidelines like know carriage returns in attribute strings on the XML that
may enforce some readibility of the XML.. Such that these conventions don't make the XML format that crafter uses unparseable by other parsers of xml (would be bad).. The strong advantage Crafter has with using XML is its parseable by any XML parser within 0 time.. Whereas with a C like language, people will get disgusted and leave before even attempting to code up something in lex and yacc that parses C like syntax, unless it is C, which may make coding such a thing a bit easier, but not like XML..

Summarize:
So XML syntax, some enforcement of style on the syntax that
doesn't make it evil to look at or use.

Oh and with XML over time we can add more commands to the language and structures to it, that don't limit the compatibility of previous
scripts.. Or this is a way that could go right, whereas with a defined syntax like C, we couldn't all of a sudden define a Pascal block and use pascal syntax there.. Its possible even in XML (though how idiotic it would look) to encapsulate C programs in XML..

Code: Select all

<code type="c">
main () { 
   printf("preferably there is no tags in here, otehrwise we might have to put something like LESS_THANbrGREATER_THAN in the c code, but this is a #define, not illegal syntax in C, just a harmless preprocessor directive, but XML will choke on the existence of tags.. but there is probably ways around this that I don't know about.. ");
}
</code>
<code type="lisp">
(print "no need to look like XML or C.. ") 
</code> 
--------------------------------------->8-------------------------------->8------------------

Okay XML it is..
Anyway, my next port of call is to apt-get install gcc, all the blender libs, kdevelop, etc, and have a look at the code... At the stage where I give up in disgust, It would be great to get some help to give advantages and disadvantages of all the existing sytems on the appropriate page on the wiki...
What does apt-get mean? Oh: http://www.apt-get.org/ .

Well I'm just a disgruntled coder that used to be a disgruntled artist that became a coder as a result of poor interface design.. So I may not be able to help with the design of the shader languages.. But
I might be able to help with the design of the language and
the interface to the language, and suggestions on things like
user interface desiign..

I have my own ideas about what should be
accessible in a shader, and like everyone else these things are
dependent on use.. So it may be better just to let the implementation
specifics hang a little bit, for things like having renderman support..
I think the structure of the XML format should be open to discussion by other.. But my personal taste is as I said.. to have mandatory attributes for tags that have mandatory attributes, like "name", and "type"..
Nothing outlandish like "spec_max_super_duper_killer_attribute"
attributes that are short, like under 12 characters, and are assigned strings with no carriage returns in them, like:

Code: Select all

<this tag="su.. 
xxxxx 
aaaa
lot
">Well at least its beautiful, I wonder if I could make a crafter XML file that looks like ASCII art.. 
</this>
Also no nesting of similar named tags, like

Code: Select all

<shader>
     <shader>
      </shader>
</shader>
instead use something like

Code: Select all

<shader class="two">
</shader>
<shader class="one">
<reference type="shader" name="two">
</shader>
And anything else that makes the xml code
look good, and makes it easy to to add to the
language in the future.. And for inspiration on
how a language can be easy and still be hacked
look at php, its fantastic to code in and its
not complicated with pointers, pointer math
nor data types.. And still its kicking java's butt
for web-centric languages Ha!!! But unlike python, PHP
is impossible to read, especially HTML, Javascript
with embedded PHP with embedded calls to JSP with calls to servlets, calling PHP, etc.. A way to get away with the syntax
you like without pushing it on everyone else is to
allow for embedding other languages withing the
syntax of a language that encourages good style.. At least
make it easy to recognize where the crap begins and ends..

Code: Select all

<shader name="Ilovemessy">
<code type="my_little_obscure_language">
oiwejfoiwjerogfw egwg eghw rhewr hwr hwrh wrh wrf hws rh wrh
s yhhr hs rh srh rh srh rsr h tgrs t s rt srt sr ts rg srg 
</code>
</shader>
Anyhow..

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

Post by bfvietnam »

wavk wrote:Okay, so I had this weird moment in which I actually thought I'd pick up coding again. I'm sorry to disappoint you guys, but in the past couple of weeks I remembered why I wasn't coding in the first place. I just have too many other things to do. I only (tried to) code two times and just couldn't get into it anymore, it's too daunting. This project started when I was freelancing/doing very little ;) And it's just too much work for me to finish it.

But I see a lot of great discussion going on here, I hope you guys or someone else will implement this some time, or at least keep the ball rolling.

So don't expect anything big on this project from me, sorry if I raised false hope.

Wybren
This looks pretty good!!

http://www.elysiun.com/forum/viewtopic. ... ght=yafray


And I found it to be about 5 topics in google after doing a search.. A good sign of poplarity is how far up the list your search results are on google.. So it seems like people are interested in this idea.. But since I started my long discussion, not much as moved on the board.. So I'm going to settle out my discussion.. If I'm making things look to hard.. I apologize.. Just think that there is a great potential here.. But it doesn't have to be a language at the beginning.. You can put anything into a module.. But I think if I could get a setup to do some development, preferably something where I don't have to do much library wrangling.. I might be able to help with the coding..

One of the ideas I had for a brief moment that looks really good and could help blender, considering I use a cable modem, for instance, and linux especially knoppix works really well with cable modems, I thought, this might be a way to do development of blender regardless of operating system as Knoppix runs from a CDROM.. Now imagine if blender.org published a distribution of Knoppix with blender and the complete blender development environment? Such that everything was ready and configured for the developers to use , without needing to configure anything.. This would encourage me to get involved with the development, particularly involved with using Linux for a development platform.. And could lead to other things as well..

Anyhow, I think it was Crafter that originally spawned an interest in changing blender's interface, but I don't think it should stop there.. Nor do I think the shader system in blender will stay long, as there is already a need for a more flexible shader system, and I'm hopeing the model utilizes crafter's development, as well as puts into motion a design that makes shader coding more accessible to blender users without programming experience. Sure it sounds like my computer graphics instructor is turning in his seat (he's not dead yet, so I can't say he's turning in his grave), but the CG industry is past its prime, and really what needs to happen is what NewTek and Alias/Wavefront are trying to still savour the slowness in coming of age, a design for a people accessible 3D graphics program.. And blender is it.. But why should people have to buy a $4K copy of 3DsMax to do game development or to make animations, or a $500+ copy of renderman.. Shouldn't this technology already be accessible.. It is.. Just that the industry is still melancholy for the good old days when you could only do 3D graphics right if you had an SGI or a Cray.. Those days are gone and the technology is not inaccessible anymore.. Some of my best friends use and prefer blender.. I guess I plotted out that right about here, considering everyone was so big on Virtual Reality in the 90s, people would have head tracking displays, hapic feedback devices and cruising the 3D spaces, sharing Internet design environments, collaborating in 3D, and creating large complex universes.. What's holding this back?

And I think the key thing, is money.. Either for the want of it or for the lack of it.. And companies like Autodesk, don't get where they are by giving back to the community... 3DsMax is just a sibsiderary of Kinetix, which is a subsiderary of Autodesk.. So you can see the 3D animation industry is not a industry but a niche market (commercially).. Why, probably because none of this VR stuff that people had hoped would come about, was ever realized.. Its still experimental and inaccessible to everyone.. Even though its not without its value..

Blender is proof that productive VR is still well and alive among regular people, and is motivation for people to become more involved with 3D applications, not afraid to do stuff on their own, and not intimidated by the seemingly complexness of doing it.. Even a friend of mine is really digging into it now, and is doing very well for someone who just picked up learning blender four weeks ago.. He learns it for an hour a day at work, where he does database development professionally.. And on teh weekends he makes his own super-hero with computer graphics from blender.. This is the people I speak of when I talk about the users of blender.. And how making stuff accessible to them is important.. Money is only a visible and welcome indicator of success but it can't be used to motivate a change like this, as with the saying money changes everything, it also stalls a lot of things as well.. And I think the concern with "whether one will be famous or successful commercially" just gets in the way of what needs to happen.

Blender and Crafter is the result of great intentions.. I hope that one year at SIGGRAPH Ton does get recognized for blender, but I don't think its going to be the way those who attend SIGGRAPH recognize success, like commercial endeavours, but it will be deserved as making CG popular and accessible to everyone.. Now note Ton is still the most frequent contributor to the sources, so I think this is justified..

Its serving as a standard for how applications should be developed.. And I'd say anyone who devotes their time to the development of Crafter in blender is marching further forward the future than any researchers are berkley or pixar.. The press looks for visible signs of life where they expect to see celebrities and scholars.. But Blender and Crafter will certainly have the true popularity without the press, which tends to value tasty details that nobody really cares about, like John Lassetter's car collection, or the next big movie SKG is making to compete with Pixar.. This is more for people who purchase stock, in supposedly proprietary technology like Renderman, or icons of stability like Spielberg and his vision, but blender, who can invest in that?

So keep in mind, this virtual popluarity that exist that is not visible in the press.. It exists but its in the form of someone doing something they never thought themselves capable, like playing a piano without experience.. Using blender is like doing those actions that before never seemed possible, that would have required a lot of money to get a hold of.. And as it surfaces more, people will realize it and it will become common.. Because an open source movement like this can't fail.. Its just too useful..

Anyhow I thank god for people like you and Ton..

I think it will still be the case, that things will be wanted as we as humans are always wanting something else.. And there is something to be said about thankfullness.. I thank you for Blender and Crafter!! And so if its wanting to much, to talk about this now, considering the recent release of blender 2.34 (still fresh), and was a grand one.. I can add onto the sans serif font a small serif, "but what about Crafter?"

So I'm hoping this will feed into the design.. Not to overtake Renderman in the future which it might do.. But to make it even easier for anyone to take images in their head and make them real for others to see.. a Tool like a paintbrush, that one can always depend upon being there when they need it.. And having that tool, to me is the true embodiment of success, and I'm sure God will bless you richly for creating such tools..


:)

PS- But this is not the end..
Last edited by bfvietnam on Mon Sep 13, 2004 1:10 am, edited 2 times in total.

bobthevirus
Posts: 0
Joined: Wed Jun 25, 2003 7:11 am

Post by bobthevirus »

Here's a wee something that I was wondering if I could add to the wiki - it's basically here to show how we can implement grouping and keeping the linking seperate from the actual workings - ie. the lionking parts are what is in my mind the best method at the moment, and the rest is just there to show stuff... It should be self-explanatory... Basically it defines methods of grouping and linking, with only "spec" being visable at the top level, then "a" and "s_a"(maybe?) , then s_a, _b, and s_c, along with "spec" and possbily "a" (actually, probably not "a" becuase that is just a wrapper to connect "spec" and "s_a"). I make dia diagrams when I get home from work...

The reason that it is like it is, is that it is an XML representation of a graphical language, and is also taking into account its use by the renderer. Note that infinate loops _are_ possible as it is, however the parser shoul detect if it goes through the same output value of a block twice - ie. as it goes up the tree from spec.spec, it remembers which outputs it has been through, and if a block reley's on one of it's own outputs, it prints an error. That error can the be picked up by the interface, and say "Hey you, can't link there (probably should be checked after every linkage - will be quick enough to not be noticable), That output rely's on what you're trying to link it to.."

Code: Select all

/* This is a top-level control block - it is what the graphical interface 
 * creates when you start the linkages - not the syntax is screwy, but it 
 * is an interesting starting point... This block only has to contain one 
 * line, however it can contain as many calls to blocks, and to control 
 * blocks, as neccersery(I hate that word).
 */
<control name="spec">
	<link source="s_b.value1" dest="a.input1" />
	<link source="s_c.value1" dest="a.input2" />
	<output name="spec" type="RGB" source="a.one" />
</control>

/* This block is a simple linking block, with defined inputs and outputs. 
 * It links together everything it needs to get the output, and then 
 * supplies it.
 */

<control name="a">
	<input type="RGB" name="input1" />
	<input type="RGB" name="input2" />
	<link source="input1" dest="s_a.input1" />
	<link source="input2" dest="s_a.input2" />
	<output name="one" type="RGB" source="s_a.out"/>
</control>

/* this is a basic worker block, that takes some inputs andd multiplies 
 * them together
 */
<block name="s_a">
	<input name="input1" type="RGB">
	<input name="input2" type="RGB">
	<var name="out1" type="RGB">
	<code type="maths">
		out1 = (input1 * input2^3);
	</code>
	<output source="out1" name="out" />
</block>

/* Here are another couple of blocks, without inputs defined.. they simply 
 * get values from the renderer. Format is even worse, but it should give 
 * an indication of the type of thing that is expected in a shader block - 
 * most notable is the lack of calls to other shader blocks - if someone 
 * wants to share a group, they should provide an appropriate control 
 * script.
 */
<block name="s_b">
	<call type="blender_function" name="getStuff" output="thing">
		<parm name="parm1">22</parm>
	</call>
	<output source="thing" name="value1">
</block>

<block name="s_c">
	<var name="a">23</var>
	<var name="b">1</var>
	<code type="maths">
		temp = (a - b);
		a = temp;
	</code>
	<call type="blender_function" name="getStuff" output="thing">
		<parm name="parm1">
			<equals var="a" />
		</parm>
	</call>
	<output source="thing" name="value1">
</block>
About the XML syntax - I'll add some of that stuff to the wiki - basically saying that "Every time a value for an XML node is mandatory, it should be defined in an attribute, while if it is only required sometimes, it should be defined in a nested tag, prefferably in a way so that it is mandatory in the cases that it is used (by making it an attribute in the nested tag that means it's required)"

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

Post by bfvietnam »

I dozed off a few times while writing this, so if it looks
illogical in some parts, call me on it.. I looked at your XML format bob,
and I created something like it.. But changed the wording, and came up with a implicit reference to the encapsulating block.. Well have a look..

There is not commenting style for XML that is standard, I used HTML syntax for commenting, and it seems in VIM, that CTAGS supports <!-- --> comment tags in XML.. But W3C says that there is not standard for how to define comments in XML, that the parser must do whatever is most appropriate in filtering out whatever commenting style is used:

http://www.w3.org/TR/REC-xml/#sec-comments

Code: Select all


<!-- 
Note: in the following class and module are used interchangeably.. they are the same, 
but often the module, the way I talk about it, is an instance of a class.. 
I don't know how to handle the population of a module with predefined values, other 
that creation a new class or having some module that populates other modules with 
their initial states.. Like you could have a module whose sole purpose is to 
populate other modules in a block configuration, with stored states.. Say you had a module that 
obtains the configuration state of some modules, and another class that restores the 
state of the modules.. The storage and retrieval of these state for these modules can be 
of a different format , like a binary file or even another XML file..  Or we might have a seperate 
tag hiearchy to handle the sdtorage of states for block configurations.. 
-->

<class name="multiply">
	<!-- input/output declarations -->
	<input name="operand1" handler=".set_operand"/>
	<input name="operand2" handler=".set_operand"/>
	<output name="result" handler=".get_result"/>

	<!-- local variable declarations -->
	<var name="op1">
	<var name="op2">

	<!-- Constructor -->
	<method name="multiply">
		<code type="crafterlisp">
			# this is the constructor, interpretive languages have no need for destructors.
		</code>
	</method>

	<!-- allows users of this modules output to retrieve the result of inputs.. 
			Note: for the cases where the module is still waiting on input, this 
			could register a callback function for the caller, so that when the 
			output is produced the ones requesting input would all receive the 
			result of this module.. 
	-->
	<method name="get_result">
		<code type="crafterlisp">
			(include "math.lsp")
			(overloaded_mult operand1 operand2)	
			# note that the types of the operands are not enforced, this is handled internally 
		 	# by with a call to "math.lsp".. 
		</code>
	</method>

	<!-- 
			method that handles all forms of input for this module.. 
			Note: how I use a code tag.. This is how we might offer an interface 
			into another language.. Internally though, crafter would have to offer up a C-like 
			API for the language, and the language would have to define its own objects 
			and functions for accessing attributes in crafter.. Crafter's language 
			will be made up of such modules as this.. There may as well be a scripting code 
			for crafter, and for it the code type does not have to be specified.. 
	-->
	<method name="set_operand">
		<code type="crafterlisp">
			(get caller _self)
			(if (== caller operand1) (set .op1 (obtain_input "operand1"))
			(if (== caller operand2) (set (obtain_input "operand2"))(0)))
		</code>
	</method>
</class>
	
<!-- a block is like a control in "bobthevirus' example", changed the name to block because 
     I felt that "a control" may not be applicable, say if the control had no controls externally 
	  but was a generator of events, its not really a control.. 
	  
	  But you can connect blocks together..
	  a block encapsulates a set of modules that define a shader, when put together..  The block 
	  itself could be used within other blocks, by allowing classes to contain blocks.. But a block can't 
	  contain a class, it can only contain instances of classes.. This forces a separation of implementation 
	  of the modules and the configuration of modules (within a block).. While still allowing for the resuse of 
	  existing blocks or shaders within the confines of a class.. Also prevents abuses of nesting, 
	  like classes within classes, and blocks within blocks, and blocks within classes within blocks, etc.. 
	  It also forces the coder to define distinct classes that perform task, thaan to define modules 
	  as needed which could make shader definitions bulky and hard to read. If special classes are needed, its best 
	  just to build the class with the special purpose in mind, or to inherit from a 
	  class and elaborate for the special purpose (future), or add methods to a class that allow it to 
	  change its functionality with a call.. Like one input to a module may use a selector (technically called a multiplexer) 
		that selects the desired input for the block.. 
-->
<block name="spec">
	<input name="intensity" type="Float">
	<var name="color" type="RGB">#FFFFFF</var> <!-- this variable acts as a produce of a single value as input.. -->

	<link source=".intensity" dest=".mult.operand1"/> <!-- link handles the plumbing between modules, internal to the block -->
	<link source=".color" dest=".mult.operand2"/> 

	<instance of="multiply" name="mult">

	<link source=".mult.result" dest=".spec_color"/> 

	<output name="spec_color" type="RGB"/>
</block>

 <!--
 tag descriptions: 
 block  - is a grouping of modules, lower level groupings are placed in classes.. 
 				but there is no third level grouping, unless by instancing of classes with blocks in them.. 
 				So its possible to have object instances within instances of objects, but its not possible to define a configuration 
 				where this connectivity is defined.. Its not needed.. Rather one would have to construct such a hiearchy 
 				by describing the configuration and encapsulation of the objects in sequence,, This is by use of 
 				the aggregation pattern in UML: http://www.holub.com/goodies/uml/index.html .
 input - a specification of an input for the block - internally represented by either a accessor method or a variable ). 
 link  - a way of routing content from one module to another.
 output - same as what input tag is, but either produces a value for output, but if the result is not ready this 
           offers the capability of either returning a value, or in tha case that the caller supports a method of callback, 
			  that events are routed to the caller when output is available..  
 instance - activates a previously defined class or system class (like crafter's predefined module types) 
            with the attributes specified. Performs similarly to a BLOCK, but has more capabilities, like being able to 
				evaluate expressions and handle mixed combinations of input data.. Use of the instance tag is the only 
				way to use a class within a block.. So the block tag is a configuration of instances, not of 
				classes.. But you can have a block configuration that defines instances of classes 
				internal to a class.. 
 
 note ".value" is an implicit name for "self.value".. Easy to check for 
 and makes syntax easy.. ".mult.input" means "self.mult.input", which 
 means the input for a containing module named "mult", mult has a 
 input called "input". 

 Now.. when a input or output is declared, the "." is remvoed because the 
 "." is a short form reference to the current object, its like a short form of "self.", 
 but you don't declare a variable to be on "self" that's implicit as the variables 
 can't be declared outside of the  object.. So output ".spec_color" would be redundant 
 as that would translate to "..spec_color", and would result in an error.. 

 Other classes would be predefined, not as classes in XML, but as part of the crafter 
 library of local tools.. So some classes already exist and can be used, 
 like for instance, since "mult" will be such a commonly used module,  it need not 
 be defined by casual users of the language.. Regular users would arrange instances of 
 blocks in a material configuration.. 

 If any of this sounds illogical, tell me what and I can rework it... 
-->

Last edited by bfvietnam on Mon Sep 13, 2004 5:32 am, edited 1 time in total.

Post Reply