Hi,
I'm creating a SOP vopnet, that takes in either N or v, and then spits out either N or v (both dependent on user selections). How do set it up so that if the user selects N, that it doesn't spit out v, and vice versa? The way I have it set up now, both N and v outputs have a switch before them that switches to either the input (i.e. output N = input N if menu = use_v, and output v = input v if menu = use_N). However, by having them wired to the outputs, it creates both N and v all the time. I want it to just create N *or* v, but not both. I can do it in code with an if statement, e.g. if (use_N) { v += 1; } else {N -= 1;}. How do I do it using VOPs?

Thanks,

– Antoine

Don't use the Output VOP. Use a AddAttribute VOP instead.

Also when dealing with Global Variables like N and v its best to use Import Attribute and AddAttribute if you want explicit control over their creation. Otherwise you can get odd stuff.

The following is from a bug report I sent in a few weeks ago.

I'm not sure this is a true bug or not, maybe more of a side effect due
to the VEX optimizer. I do have a workaround but thought you would be
interested.

The issue involves the following statement,

If the VEX SOP's second input has this attribute available for import
AND the user has turned on a toggle, then set the value of the attribute
be that of the second input.

In VEX:
if (import(“Cd”,tmp_v,1) && do_Cd) {
Cd = tmp_v;
}

The problem with the above VEX snippet is that it adds the Cd attribute
to the geo detail regardless if the second input has the Cd attribute
AND if do_Cd, (the user toggle), is set to on.



My next attempt:
if (do_Cd) {
if (import(“Cd”,tmp_v,1)) {
Cd = tmp_v;
}
}

In this case the Cd attribute is added to the detail if the user toggle
is turned on regardless if the second input actually has the Cd attribute.


Yet another attempt, this one behaves as expected:
if (import(“Cd”,tmp_v,1) && do_Cd) {
addattribute(“Cd”,tmp_v);
}

Wolfwood
Don't use the Output VOP. Use a AddAttribute VOP instead.

Also when dealing with Global Variables like N and v its best to use Import Attribute and AddAttribute if you want explicit control over their creation. Otherwise you can get odd stuff.

Cool, thanks for the tip. How does VOPs know that it should put the addAttribute node into the code, since its output doesn't go anywhere?

Antoine Durr
Cool, thanks for the tip. How does VOPs know that it should put the addAttribute node into the code, since its output doesn't go anywhere?

Right Click on the AddAttribute VOP and bring up the Operator Type Properties.

On the Input/Output Tab there is a toggle at the bottom called “Force Code Generation”.

Antoine Durr

Wolfwood
Don't use the Output VOP. Use a AddAttribute VOP instead.

Also when dealing with Global Variables like N and v its best to use Import Attribute and AddAttribute if you want explicit control over their creation. Otherwise you can get odd stuff.

Cool, thanks for the tip. How does VOPs know that it should put the addAttribute node into the code, since its output doesn't go anywhere?

It's like newgroup(), addgroup() and a couple of other select VOPs. There's a keyword in the dialog script “forcecode”.

It took me a while to find how to display the dialog script, but if you bring up the Operator Type Manager for the addattrib VOP, then choose “Edit Contents…”, you should see the defining dialog script. And in there somewhere, you'll find “forcecode”.

mark
It's like newgroup(), addgroup() and a couple of other select VOPs. There's a keyword in the dialog script “forcecode”.

It took me a while to find how to display the dialog script, but if you bring up the Operator Type Manager for the addattrib VOP, then choose “Edit Contents…”, you should see the defining dialog script. And in there somewhere, you'll find “forcecode”.

Now *that's* a hack!

That “forcecode” directive in the dialog script is put there by turning on the “Force Code Generation” toggle Wolfwood referred to. Really no need for the whole Edit Contents thing…

Mark

mtucker
That “forcecode” directive in the dialog script is put there by turning on the “Force Code Generation” toggle Wolfwood referred to. Really no need for the whole Edit Contents thing…

Mark

On that topic, I used a inline-code VOP to add a #pragma, though the pragma ended up near the end, inside the shader. It didn't work while I was editing the VOPnet, but when I wrote out the code and vcc'ed it, it took effect as expected. Is there a way to have that pragma inserted near the top, ideally by all the other pragmas that are put there via parameter dialog options?

– Antoine

Currently the only way to accomplish what you want is to define your own VOP type (File->New Operator Type->VEX Builder Type) and put the pragma or pragmas in the Outer Code section of that VOP type. If you make it an Embedded VOP type then the VOP will stay with the hip file and you won't need to worry about where to store the OTL. The only other solution I can think of is to put the pragmas into a file on disk, and use the Inline Code VOP to include that external file.

In case you were wondering, the reason the pragma is ignored when editing the VOPNET is that the dialog scripts for the SHOP is not generated by vcc. It is pulled directly from the Parameter VOP options. There are a number of things you can't do using pragmas, and we wanted to let you do those things with VOPNETs, so we had to bypass the pragma mechanism when defining a SHOP using a VOPNET. But we preserve as much of the UI as we can through the use of pragmas just in case you want to write out the .vfl file and compile it with vcc. But there is no guarantee you'll get the same UI that way as you got while editing the VOPNET.

Mark