what is ##?

[TheUsualAlex]

Heya.

In the layered.vfl, I see something like:

string comp##idx= "over"; \
string map##idx = ""; \

what is ## or ##idx? ANd what does that "\" at the end supposed to do...?

Thanks!

ADD: Why is a vector4 considered "homogenous" coordinate? What is "homogenous coordinate"?

[FrankFirsching]

Hi!

You need to consider the line above the two you have quoted:

#define SHADER_PARMS(idx, uv_coord)	\
     string	comp##idx = "over"; \

The #define statement indicates the preprocessor to create a new macro with variables idx and uv_coord. The "\" at the end of the line tells the preprocessor that the macro continues on the next line. Now to the ##-signs: they are used to create new tokens based on variables. This means, if you invoke the macro like

SHADER_PARMS(_base,"uv")

the line

string comp##idx = "over";

evaluates to

string comp_base = "over";

If you hadn't used the ##, then the preprocessor wouldn't notice, that you are referencing the variable idx, because it only sees a token named compidx, and would have created the following source-line:

string compidx = "over";

But this is not wat you wanted.

Homogenous coordinates are a way to describe projective transformations using matrix-math. You extend a 3-dimensional vector (x,y,z) by a 4-th component (x,y,z,w). w is called the homogenous coordinate. A homogenous vector equals the 3-dimensional point (x/w, y/w, z/w).

Frank

[Wolfwood]

Hey Alex,

If you have the Advanced RenderMan book handy, section 2.1.5 talks about homogeneous coordinates and how they relate to points and vectors. Its a good book even if you don't use RenderMan.

jim.

[TheUsualAlex]

Hey Frank and Jim,

Thank you for your response!

As far as the homogenous coordinate goes, I think I am sort of getting it now. I went to the library and checked out a book on "Fundamentals of Computer Graphics", that seems to explained it.

Anyhow, I guess I still have some more question.

In the VEX language reference, there is a secion on "Operations supported in VEX" ($HH/vex/html/functions.html), there is a list of table about different typs of operations from LHS and RHS. Is this table basically saying that:

vector4 + vector will yield a vector4

vector + vector 4 will yield a vector and etc?

Or is it something else completely different?

Also, in the table, I see that there is vector4 + float, but there is no float + vector. Is the reason for this is that in order to add vector4 to float, the float will have to converted to vector4 before adding? While adding float to vector4 may result in data lost since it'd have to truncate vector4? Or is it something else totally different?

Thanks!

I am just starting to learn VEX now. I am trying to make sure that I understood fully what's going on. Sorry about my really stupid questions...

[FrankFirsching]

Hi!

I never looked at that table. I think Houdini mangles overloaded functions not only on the parameters but also on the return type ($HH/vex/html/compiler.html: section "Type Casting"). C++ for instance doesn't do this. But this now confuses me: why should

float + int => float

but

int + float => int ?

For me that doesn't make any sense. I must check this.

Frank

[FrankFirsching]

I tested this now and I'm very perplexed. I haven't done much with VEX, but I'm wondering, why I didn't run into BIG problems on the things I did.

This piece of code:

	int i1=1;
	int i2=2;
	float f1=3.33;
	float f2=4.44;
	float r1 = i1+f2;
	printf("i1+i2=%g\n", i1+i2);
	printf("f1+f2=%g\n", f1+f2);
	printf("i1+f2=%g\n", i1+f2);
	printf("f1+i2=%g\n", f1+i2);
	printf("r1   =%g\n", r1);

results in the following output:

i1+i2=3

f1+f2=7.77

i1+f2=5

f1+i2=5.33

r1 =5

The 3rd and 5th line aren't the results I exprected. This convention is so error-prone. I like the one of C++ much more, where the datatypes are promoted to the type with the bigger precission.

Frank

[Wolfwood]

Alex, these are little tests I just ran on a shadow shader. If you follow the table its just safer...right?

Adding a float to a vector, increase each element by 1

{0,1,2,3} + 1 == {1,2,3,4)

Adding a vector to a float? It works...but subtracting a vector from a float throws a error.

1 + {0,1,2,3} == {1,2,3,4)

{0,1,2,3} + {0,1,2} == {0,2,4,3}

{0,1,2} + {0,1,2,3} == {0,2,4}

jim.

[TheUsualAlex]

Hmm... I see.

I think my head is exploding...

Hi Frank, the result that you got was pretty much what I was expecting. What was the result that you were expecting concerning line 3 and 5?

Hi Jim, adding a float to vector4 wasn't what I was expecting. But that still explained it.

By the way, is the printf function the way to test and see a result in VEX? I've recently learned PERL. I actually got confused about how to use the printf function...

Thank you!

[Wolfwood]

Printf is your best friend and the best debugger. IMHO.

All printf does is prints a formated string to standard output.

printf("string",...); where ... are the corresponding variables to output.

float foo = 1;

printf("My variable foo is equal to %g\n",foo);

The %g references foo. (and \n is a new line).

Another example.

string Name = "Alex";

float foo = 1;

float bar = 2;

printf("%s, %g+%g=%g\n",Name,foo,bar,foo + bar);

Would output,

Alex, 1+2=3

In this case the first % references Name, but since Name is a string you need to use %s.

%s for strings, %g or %f for numbers. There are some others just check the help.

On a side note I really like how easy the Print VOP is.

jim.

[FrankFirsching]

Comming from a C programming background, the result I exprected would be the same as line 4, since mathematically it is no difference, if you write 1+3.33 or 3.33+1

The sum should be commutative! Using these rules it isn't. (I know that floating point numbers aren't anyway, but these errors are sonewhere in the precision of the smallest representable number. Something like 1e-10 ).

Frank

[TheUsualAlex]

Ahhh. I see.

Thank you both!

I just thought about this earlier, some of the stuff made sense actually -- for example, when you multiply scalar to a vector, you'd get a vector back. I don't know why I wasn't thinking that way earlier.... I guess I need mo Red Bulls.

However, sometimes, there are just number that's being spit out by the computer made me scratch my head wondering... for example, in my RH Linux 8's (KDE) calculator, cos 90 is 6.123e-17 (or 0.00000.....6123).

Cheers,

Alex

[Marc]

There's definitely a difference in the result of the output based on the order of the inputs.

I recall having a big discussion with Jason on this and I concluded that it was silly too. Although I can't for the life of me remember if I asked R&D about it...tired brain don;t work so good no more .

hmm... Jason, do you remember what the outcome was?

Marc

[FrankFirsching]

However, sometimes, there are just number that's being spit out by the computer made me scratch my head wondering... for example, in my RH Linux 8's (KDE) calculator, cos 90 is 6.123e-17 (or 0.00000.....6123).

Numerically this is equal to zero. This result comes from the fact, that you can't represent the numbers of the intermeduate results you calculate with exactly. You can't even store some constants exactly. E.g the cos 90