Hey sidefx,

Currently Attribute Wrangler SOP (or Point Wrangler) does not support function definitions with an array as a return type, so it seems.

For instance, the following does not work:


vector rgb_array()
{
return { {1, 0, 0}, {0, 1, 0}, {0, 0, 1} };
};


Are there any plans to support this at some point? At the moment, trivial things, e.g. returning a sorted list, become non-trivial or uglier than they should be. Or am I missing the point?


Regards,
Vlad

void rgb_array(vector colors)
{
colors = { {1, 0, 0}, {0, 1, 0}, {0, 0, 1} };
}

vector c;
rgb_array©;
printf(“%f”, c);

Thanks, edward


void foo(int a)
{
a = 1;
};

void main()
{
int a = 0;
printf(“%d”, a);
foo(a);
printf(“%d”, a);
};

main();


Outputs:

> 01


So it is the variable that is passed as an argument, not the value of a variable, thus allowing changing the state of the variable from another function? Good to know, I expected different.

edward
void rgb_array(vector colors)
{
colors = { {1, 0, 0}, {0, 1, 0}, {0, 0, 1} };
}

vector c;
rgb_array©;
printf(“%f”, c);

Is there any chance that vcc will be able to compile the functions defined inside other functions and that return vectors by value?
Scalars and even strings are fine. Is it some sort of preprocessing issue?

madjestic
So it is the variable that is passed as an argument, not the value of a variable, thus allowing changing the state of the variable from another function? Good to know, I expected different.

I tend to use a const keyword to be safe:


type name(const type var)
{
return result;
}

hoknamahn
Is there any chance that vcc will be able to compile the functions defined inside other functions and that return vectors by value?
Scalars and even strings are fine. Is it some sort of preprocessing issue?

I don't know. Personally, I hate functions within functions from my days of modifying badly written Pascal code.

madjestic
So it is the variable that is passed as an argument, not the value of a variable, thus allowing changing the state of the variable from another function? Good to know, I expected different.

VEX has always had all parameters passed by reference. The code for functions are just inlined to where they are called. This is also why VEX functions cannot call themselves. The const keyword was later added so that one can enforce non-modifiable function parameters.

edward
I don't know. Personally, I hate functions within functions from my days of modifying badly written Pascal code.

I totally agree. But this is the way wranglers work. Plus their behaviour is not consistent nor intuitive (otherwise we would not see such questions).
On a contrary, we have a workaround

hoknamahn
I totally agree. But this is the way wranglers work.

Ok, so I tried this and looked at the VEX code inside an Attribute Wrangler. So if the wranglers work this way, then I guess functions work within functions right now.

I hate functions within functions from my days of modifying badly written Pascal code

One can like recursion, or hate it, but it is legit. Proven by mathematics.

edward

hoknamahn
I totally agree. But this is the way wranglers work.

Ok, so I tried this and looked at the VEX code inside an Attribute Wrangler. So if the wranglers work this way, then I guess functions work within functions right now.

They do. But only if a value we return is not of array type. It's the case in both normal VEX and a wranglified one. So it's not a problem of wrangler's preprocessor as I initially thought. Looks like vcc needs more love

MADjestic

I hate functions within functions from my days of modifying badly written Pascal code

One can like recursion, or hate it, but it is legit. Proven by mathematics.

I meant declaring functions within functions, not functions calling themselves.

When we added arbitrary types to VEX (rather than hardcoding float/vector/bsdf/etc) to allow support for structs, we broke the ability to return arrays from functions inside of functions.

This is because we couldn't disambiguate:

type foo() {}

from

foo;

Because we can't tell if “foo” is a type or an identifier. At the time this wasn't very important. As Edward points out, people rarely use functions inside of functions. However, a few years later, we added Wrangles. To avoid the functions you create in a wrangle from conflicting with functions made in other Snippet VOPs, we wrap everything inside of a function. Which then exposes this long-standing problem.

We have strived mightily to fix this. Back in December I thought I had a clever solution. By making a token I could make the foo; statement illegal (which is reasonable as it does nothing) and then give a nice Christmas present of functions returning arrays. This, however, fails because you need to be able to do casting:

result = len(int(point(…)))

Another attempt was made in January to add type-awareness to the lexer. But, as evidenced by the current state of things, it also failed. We may have to rebuild the grammar from scratch. *sigh*

The other workaround is always:

#include “myfuncs.h”

so you can put all your common code in a shared space. The #include is moved outside of the function definition, so you can happily make things that return arrays.

Hi Jeff,

What about defining your functions in the Outer Code section of a Snippet VOP? Last April I was told:

“It also isn't allowed in the attrib vop, in your file what is happening is the outer-code section is being abused to define a function, something that will crash and burn when you cut & paste that node.”

Is this still an issue or has it changed?


Also on the topic of rewriting the grammar, would this also put other features in the plans, such as generics, classes, etc? That would be the ultimate xmas gift of all time

Thank you, Jeff, for a thorough explanation. I hope you will crack that nut one day.

This doesn't happen in wrangles, but wrangles are built on the Snippet VOP. If you use the outercode of the Snippet VOP to define a function, and cut & paste that snippet VOP, you'll get two functions of the same name defined. This will give confusing results. It gets especially bad if you decided to build a new VOP as an OTL wrapping a Snippet VOP - suddenly when you put two copies of this VOP down you'll get strange errors.

I really don't want to add Outer code to the Wrangles because they are supposed to be a fast and simple way to build things. Having many different parameter fields works against that.

Hmmm… it seems that it doesn't accept this either:
int findclass(int ptclass, int pt) {
if (ptclass != pt) {
ptclass = findclass(ptclass, pt);
}
return ptclass;
}
It says that the “pt” after “int” is a “Syntax error, unexpected identifier, expecting ‘)’”. Could that be related, or is it something else I'm just missing? Is there a workaround for this one too?

It will accept this:
int findclass(int ptclass; int pt) {
if (ptclass != pt) {
ptclass = findclass(ptclass, pt);
}
return ptclass;
}
but will fail again, because:

docs
The functions are in-lined automatically by the compiler, so recursion will not work. To write a recursive algorithm, you should use shader calls instead.

pavelPeh
It will accept this:
int findclass(int ptclass; int pt) {

Darn it; I always forget that VEX parameters have a different syntax than other languages. :? Thanks!

docs
The functions are in-lined automatically by the compiler, so recursion will not work.

Hmm… hopefully that always-inline behaviour doesn't result in code that's too gigantic sometimes. Anyway, I “de-recursed” the function by simulating the recursion with another array, and now it works. Yay! Basic maze generator!

pusat
Hi Jeff,
Also on the topic of rewriting the grammar, would this also put other features in the plans, such as generics, classes, etc? That would be the ultimate xmas gift of all time

actually in rewriting the grammar, SESI should do more than just implementing a complete object oriented environment in a JIT format compiler system.

jlait
We may have to rebuild the grammar from scratch. *sigh*

we need a new generation of CVEX that beside mentioned features, it fully does support complete multi threaded parallel computations on both CPU and GPU automatically under the hood.
a big endeavor at re implementing of this built-in language like as what Sidefx done at release 12 for geometry engine.
otherwise cvex with it's all beauties will go under fabric engine's kernel language shadow in near future.

AD discontinued proceduralism in it's products line by retiring softimage.
but fabric engine KL will bring in fully proceduralism in all their porducts.

it is very hard to see that other developers from a collection of H's great ideas which H have some decades, pick one of them, develop and refine it more, absorb final users attention more, and at the end, H's one being second degree citizen, and industry knows H just as a great vfx tool.

may be H nodal compositor system be another example against nuke.
or procedural texture making capabilities of H against substance designer
now CVEX against KL.

what a competitive industry is this industry. :?