Computing Light In Vex \

[aracid]

Hey all

i was wondering if anyone could tell me why

ie int the VEX 3D Texture Fog

theres #define COMPUTE_LIGHT \

{ lclr = 0; \

etc

theres always a "\" at the end of the sentance

could someone explain why this is ?

thanks in advance

aracid

[Wolfwood]

could someone explain why this is ?

Because its an evil macro....

When Houdini compiles your vex code the first thing that happens is it gets run through a pre-processor where it removes any code comments, includes header files, and expands #defines.

When the preprocessor sees a #define FOO 42 it will replace any FOO with 42 in your code.

so float myVal = FOO; becomes

float myVal = 42;

The trick with #defines is that they can only be one line long, but having a define like this is hard to read....

#define DO42TIMES(EXPR,COUNTER) for(COUNTER=0;COUNTER<42;COUNTER=COUNTER+1) { EXPR; }

surface foo() {
    
    float poo = .1;
    float i;

    DO42TIMES(poo = poo + .1,i)

}

so you can use "\" to tell the preprocessor that the #define continues on the next line.

#define DO42TIMES(EXPR,COUNTER) \
for(COUNTER=0;COUNTER<42;COUNTER=COUNTER+1) {\
EXPR; \
}


surface foo() {
    
    float poo = .1;
    float i;

    DO42TIMES(poo = poo + .1,i)

}

You can always check to see how a macro is being expanded by using vcc -E.

For example

#define DO_N_TIMES(EXPR,COUNTER,N) \
  for(COUNTER=0;COUNTER<N;COUNTER=COUNTER+1) {\
    EXPR; \
  }

surface foo() {
    
    float i;
    vector sumA = 0;
    vector sumB = 0;

    DO_N_TIMES(sumA=sumA+reflectlight(P,nrandom(),0.01,1),i,32);
    sumA = sumA/32;


    DO_N_TIMES(sumB=sumB+reflectlight(P,nrandom(),0.1,5),i,128);
    sumB = sumB/128;
}

Then run vcc -E

# 1 "foo.txt"






surface foo() {

    float i;
    vector sumA = 0;
    vector sumB = 0;

       for(i=0;i<32;i=i+1) {    sumA=sumA+reflectlight(P,nrandom(),0.01,1);   };
    sumA = sumA/32;


       for(i=0;i<128;i=i+1) {    sumB=sumB+reflectlight(P,nrandom(),0.1,5);   };
    sumB = sumB/128;
}

Long story short, using #defines as programming short cuts is really yucky, since it can make trying to debug a problem very hard. The only time when using a #define is kinda ok is faking global variables like the #define FOO 42 example

[Jason]

Hey all

i was wondering if anyone could tell me why

ie int the VEX 3D Texture Fog

theres  #define COMPUTE_LIGHT \

{ lclr = 0; \

etc

theres always a "\" at the end of the sentance

could someone explain why this is ?

thanks in advance

aracid 

22460[/snapback]

It's to show line continuation. That entire block of code is substituted for each match of the macro. Before source code is compiled its sent through a pre-processor which expands macros and so on. Notice that #define statements don't need semicolons to tell it about where the end of the line is? The preprocessor looks for a newline to tell it that and if you escape the newline it will ignore the newline and continue on the line line building the macro.

Just FYI, C compilers and C-like compilers like vcc (the VEX compiler) do not care about whitespace. The entire program can be one run-on line. That is why you need semicolons to inform it of the end of a statement. This is why C pre-processors can and do produce results which do not respect whitespace. If you ever want to take advantage of a preprocessor that does care about it, you can use some other preprocessors like "m4" (search for it).

Cheers,

Jason

[aracid]

hey Wolfwood & Jason,

thanks for the great replies :-)

aracid

[sibarrick]

This type of thing is very useful if you have lots of repeating parameters in a shader - look at the code for VEX Layered it totally relies on them and makes coding it very simple.

[lisux]

This type of thing is very useful if you have lots of repeating parameters in a shader - look at the code for VEX Layered it totally relies on them and makes coding it very simple.

22499[/snapback]

Yes simon, macros can simplifies a lot programming, but i am agree with wolfwood, they are very very dangerous.

the problem is that with languages like VEX, that have the lack of inline functions like c++, macros is the only way to simplify the programming.

I use macros a lot, but one must be careful about them.

[Wolfwood]

This type of thing is very useful if you have lots of repeating parameters in a shader - look at the code for VEX Layered it totally relies on them and makes coding it very simple.

22499[/snapback]

Very true, it cases of shading parameters they are a necessary evil. They are very helpful but sometimes you can fall into a trap where you start off with a simple parameter macro, then wrap another macro around that, then another, add a bit to the first...the next thing you know you have a huge macro workflow held together by cheap generic walmart duct tape.

The parameter marco setup that we got here at work is actually pretty straight forward, much better than the disaster I created back when BMRT was still cool

[FrankFirsching]

the problem is that with languages like VEX, that have the lack of inline functions like c++, macros is the only way to simplify the programming.

22503[/snapback]

Actually all functions in vex are inlined (which btw. is the reason, why recursion isn't possible). So macros should not be the way to go, if a function can do the same. With macros on the other side you are able to build function-calls or variable names based on input arguments. This can lead to some clever constructs, like in the vex layered surface shader.