Forums Technical Discussion What is the difference between =set() and ={}

What is the difference between =set() and ={}

   897   9   2
User Avatar
metaclay2
Member
48 posts
Joined: Feb. 2013
Offline
 
I'm new to vex. What is the difference when setting the attribute using set() and {} ?
for example :

v@Cd = {0,0,0};

v@Cd = set(0,0,0);

When using {} , why can't I use math expression or function such as :
@Cd = {rand(1) *2 , 0 , 0};

Thanks
 Report
User Avatar
animatrix_
Member
4515 posts
Joined: Feb. 2012
Offline
 
Hi,

{} only works when you use literal values inside. The {} syntax is designed for static, compile-time assignments rather than dynamic, runtime evaluations.

Use set() when you need to initialize vectors with dynamic values, computations, or function calls.
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 | animatrix2k7.gumroad.com
 Report
User Avatar
metaclay2
Member
48 posts
Joined: Feb. 2013
Offline
 
animatrix_
Hi,

{} only works when you use literal values inside. The {} syntax is designed for static, compile-time assignments rather than dynamic, runtime evaluations.

Use set() when you need to initialize vectors with dynamic values, computations, or function calls.

Thanks, my next question is : if set() can also use static value the what is the benefit of using {} ? or If the value is just static then what makes the {} preferable compared to set() ?
Edited by metaclay2 - March 16, 2024 11:45:35
 Report
User Avatar
ObeidaZakzak
Member
93 posts
Joined: Dec. 2019
Offline
 
metaclay2
Thanks, my next question is : if set() can also use static value the what is the benefit of using {} ? or If the value is just static then what makes the {} preferable compared to set() ?

Hello,

Using set() function should result with a run-time evaluation of values provided inside, no matter if they are static or dynamic.

When working with static values, curly braces {} are preferred as they do compile-time evaluation. This means that they will get computed once when the VEX code is compiled, and will not be computed again when the VEX code is running. This can save memory and time for run-time.

If you search "compile-time vs. run-time evaluation" on internet you can find a lot of questions/answers about this topic, as this is a generic programming question.
Houdini Pipeline Supervisor @ TAT Studio
 Report
User Avatar
BabaJ
Member
2040 posts
Joined: Sept. 2015
Offline
 
ObeidaZakzak
When working with static values, curly braces {} are preferred as they do compile-time evaluation.

Which brings up some interesting observations that is likely related to what you said, but not just compile-time, but pre-process compilation stage?, and also the 'added' element of Houdini in which attributes are used and how they are treated; vex being not just dealing with local variables.

In a 'detail' wrangle this is allowed:
vector @up = {2,0,5};

This is not:
vector @up = set(2,0,5);
the 'set' function being a computation.

But this is:
vector up = set(2,0,5);

And this is not:
vector @up = {2,0,5} * 2;
...being a computation
Edited by BabaJ - March 17, 2024 14:23:14
 Report
User Avatar
tamte
Member
8554 posts
Joined: July 2007
Online
 
BabaJ
In a 'detail' wrangle this is allowed:
vector @up = {2,0,5};
This is not:
vector @up = set(2,0,5);
that's not allowed in any wrangle, since that's the default value for the prototype and that has to be constant
it's not necessarily a VEX thing, it is the snippet syntax, but because it translates to the CVEX shader argument, it can't contain anything else than literal constants

just note that defining the prototype with default constant value:
vector @up = {2,0,5};
is a different thing from assigning a value to the attribute:
v@up = {2,0,5};
where you can use variables and any sort of runtime expressions
v@up = set(a,0,5) * 2;
Tomas Slancik
FX Supervisor
Method Studios, NY
 Report
User Avatar
BabaJ
Member
2040 posts
Joined: Sept. 2015
Offline
 
tamte
that's not allowed in any wrangle,
It wasn't meant to imply in only detail set wrangle, it was only meant to inform of the context the points being made are from.

tamte
since that's the default value for the prototype and that has to be constant
Which is what I was saying - the function set() is a computation.


tamte
it's not necessarily a VEX thing, it is the snippet syntax, but because it translates to the CVEX shader argument, it can't contain anything else than literal constants
It's 100% a vex thing in terms of how the compiler/pre-compiler or even some special 'stage' of processing; Which takes into account 'attributes' as defined uniquely in Houdini with the '@'

As my example already showed, simple variables get treated differently; As a result, at whatever stage, they are dealt with differently.


tamte
just note that defining the prototype with default constant value:

vector @up = {2,0,5};

is a different thing from assigning a value to the attribute:

v@up = {2,0,5};

where you can use variables and any sort of runtime expressions

v@up = set(a,0,5) * 2;

Yes, it wasn't about the defining of a prototype per se, but the fact that we have two different elements being dealt with(on the point being made) - local varaibles, and attributes - both at some point in the pre-process/compilation stage/s are treated and looked at differently.
 Report
User Avatar
tamte
Member
8554 posts
Joined: July 2007
Online
 
BabaJ
It's 100% a vex thing in terms of how the compiler/pre-compiler or even some special 'stage' of processing; Which takes into account 'attributes' as defined uniquely in Houdini with the '@'
@ binding is not part of VEX, it's a snippet syntax that gets translated into VEX as an argument of the shader

My post meant just to expand on yours and to clarify more why that's not allowed ans mostly to point out the difference between defining a prototype and actually assigning variable values to attributes as they may look like a similar syntax when written as snippets
In hope to make it sound less like a black magic but that there is a logic behind why that's not allowed
Tomas Slancik
FX Supervisor
Method Studios, NY
 Report
User Avatar
BabaJ
Member
2040 posts
Joined: Sept. 2015
Offline
 
tamte
@ binding is not part of VEX,
It is VEX in terms of the context it was presented. That's why I put 'detail' as I did in quotes, so it would be understood as that.
I was looking at that code box (VEX) and how the various elements that could be used in such a code box, ends up getting treated/processed.

tamte
My post meant just to expand
It most definitely did.

tamte
clarify more why that's not allowed
Yes that certainly was made clear.

However, my leaning was towards looking at where/how that happens in the pre-compiler/compiler process(or some other sequence of processing). The process that takes everything in the code box (In a broader context of the meaning of vex, the starting point of the code written in that 'vex' box)and how it handles the various elements and at what stage/s.

Just to add to the conversation again in reference to other code that's already been posted:

This works
#define Example_A set(5)
#define Example_B {3,5,6}
#define Example_C 10.2 * 5

But you could not add another line of code(to the previous code) doing this
Example_B += 2;

But you can do this
int @Att_Example = 5;

@Att_Example += 2;

But you can not do this
int @Att_Example = set(5);

@Att_Example += 2;

Because of these difference, local 'variable' and 'attribute' - there's going to be different scenarios where one can or cannot be using something like set() or {}
Edited by BabaJ - March 18, 2024 17:06:29
 Report
User Avatar
tamte
Member
8554 posts
Joined: July 2007
Online
 
While we are expanding on the explanation, just want to point out clearer example about the difference between those 2 cases
so when you type this in the snippet code (which as I mentioned is technically not 100% VEX language code):
int @binding_name = 5;
it would roughly translate to following VEX code (assuming that binding_name matches Export pattern, otherwise it would be without export keyword, but that's irrelevant for this particular example)
cvex
my_shader(export int binding_name = 5)
{
}
the value is used as a default value for the shader function argument and that's why it can't be varying
one advantage of this however is that if such shader is bound to geometry then it can define default value of the attribute if not already present

while doing this in a snippet code:
i@binding_name = 5;
would roughly translate to following VEX code:
cvex
my_shader(export int binding_name = 0)
{
    binding_name = 5;
}
in which case the assignment is in the body of the function and can be constant or varying
Edited by tamte - March 18, 2024 19:53:32
Tomas Slancik
FX Supervisor
Method Studios, NY
 Report
  • Quick Links