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
array return types for Attribute Wrangler SOP
11310 17 1- madjestic
- Member
- 325 posts
- Joined: 7月 2005
- Offline
- edward
- Member
- 7865 posts
- Joined: 7月 2005
- Offline
- madjestic
- Member
- 325 posts
- Joined: 7月 2005
- Offline
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.
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.
I liked the Mustang
- hoknamahn
- Member
- 398 posts
- Joined: 7月 2005
- Offline
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;
}
f = conserve . diffuse . advect . add
fx td @ the mill
fx td @ the mill
- edward
- Member
- 7865 posts
- Joined: 7月 2005
- Offline
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.
- hoknamahn
- Member
- 398 posts
- Joined: 7月 2005
- Offline
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
f = conserve . diffuse . advect . add
fx td @ the mill
fx td @ the mill
- edward
- Member
- 7865 posts
- Joined: 7月 2005
- Offline
- madjestic
- Member
- 325 posts
- Joined: 7月 2005
- Offline
- hoknamahn
- Member
- 398 posts
- Joined: 7月 2005
- Offline
edwardhoknamahn
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
f = conserve . diffuse . advect . add
fx td @ the mill
fx td @ the mill
- edward
- Member
- 7865 posts
- Joined: 7月 2005
- Offline
- jlait
- スタッフ
- 6368 posts
- Joined: 7月 2005
- Offline
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.
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.
- animatrix_
- Member
- 4626 posts
- Joined: 2月 2012
- Offline
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
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
Senior FX TD @ Industrial Light & Magic
Get to the NEXT level in Houdini & VEX with Pragmatic VEX! [www.pragmatic-vfx.com]
youtube.com/@pragmaticvfx | patreon.com/animatrix | pragmaticvfx.gumroad.com
Get to the NEXT level in Houdini & VEX with Pragmatic VEX! [www.pragmatic-vfx.com]
youtube.com/@pragmaticvfx | patreon.com/animatrix | pragmaticvfx.gumroad.com
- madjestic
- Member
- 325 posts
- Joined: 7月 2005
- Offline
- jlait
- スタッフ
- 6368 posts
- Joined: 7月 2005
- Offline
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.
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.
- neil_math_comp
- Member
- 1743 posts
- Joined: 3月 2012
- Offline
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?
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?
Writing code for fun and profit since... 2005? Wow, I'm getting old.
https://www.youtube.com/channel/UC_HFmdvpe9U2G3OMNViKMEQ [www.youtube.com]
https://www.youtube.com/channel/UC_HFmdvpe9U2G3OMNViKMEQ [www.youtube.com]
- pavelPeh
- Member
- 30 posts
- Joined: 5月 2012
- Offline
It will accept this:
int findclass(int ptclass; int pt) {
if (ptclass != pt) {
ptclass = findclass(ptclass, pt);
}
return ptclass;
}
but will fail again, because:
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.
- neil_math_comp
- Member
- 1743 posts
- Joined: 3月 2012
- Offline
pavelPehDarn it; I always forget that VEX parameters have a different syntax than other languages. :? Thanks!
It will accept this:
int findclass(int ptclass; int pt) {
docsHmm… 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!
The functions are in-lined automatically by the compiler, so recursion will not work.
Writing code for fun and profit since... 2005? Wow, I'm getting old.
https://www.youtube.com/channel/UC_HFmdvpe9U2G3OMNViKMEQ [www.youtube.com]
https://www.youtube.com/channel/UC_HFmdvpe9U2G3OMNViKMEQ [www.youtube.com]
- sorian
- Member
- 49 posts
- Joined: 9月 2014
- Offline
pusatactually in rewriting the grammar, SESI should do more than just implementing a complete object oriented environment in a JIT format compiler system.
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
jlaitwe 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.
We may have to rebuild the grammar from scratch. *sigh*
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. :?
-
- Quick Links