The Point VOP SOP and Point Wrangle nodes are now hidden by default. Use the Attribute VOP SOP and Attribute Wrangle instead. (“Point VOP” and “Point Wrangle” are still available in the UI as aliases to ease the transition.)

Hi All now we have lost the classic and much loved vop sop I feel like a fish out of water. would people care to share any of there tips / tricks and potential pitfalls to help users migrate to the the new workflow ? .

Rob

kind of a good start would be to know how to setup groups in vops with cvex, the set attribute is not working for me,

The following line will add points or prims to a group named after the “@group_”

@group_NAME_OF_GROUP = 1;

Alternatively, use:
setpointgroup / setprimgroup etc functions.

for setting Attribs:
i@foo = value;

where (from left to right):
1: i = attrib Type (in this case an int)
2: @ is used for binding the Attribute to the name fooo
3: foo name of attr
4: value = attr value = Attrib type.

I find these more convenient than using VOPs.
All this is already documented the Help Docs.

As far as Attrib Vops are concerned, setattribute wont work because
it expects the attribute to already exist on Geo.
I would rather use Bind vop to write out attributes, its less hassle.

bhaveshpandey
…
As far as Attrib Vops are concerned, setattribute wont work because
it expects the attribute to already exist on Geo.
I would rather use Bind vop to write out attributes, its less hassle.

if you need to use setattrib() (to set attrib on different point/prim/detail), you can create the attrib within the same VEX by calling addattrib() first
then setattrib() will work
but for creating attrib and setting values for current component you really better use @attribname or Bind VOP for speed reasons

Deniz Sahin
kind of a good start would be to know how to setup groups in vops with cvex, the set attribute is not working for me,

Set Attribute does not work if you write a different type than the attribute is.

Groups are considered integer.

Thus the Set Attribute VOP should have an integer wired to its value.

If I do a Set Attribute
Attribute Class: Point Group
Attribute: test

There will be no group “test” in the resulting geometry. If, however, I take a constant VOP of type integer and wire it to the value, then the test group will be created.

Groups are special in that they are created when written to, unlike other point attributes which need the Add Attribute VOP if they do not already exist.

A note has been added to the docs to reflect the need for integers for groups.

In any case, Bind/Bind Export are much better than Set Attribute for performance and usability. Set Attribute should be reserved when you need to write to a different class than you are currently iterating over, or a different element than you are currently processing.

hi All,

Add attribute has changed and leads to Bind VOp and BindExport VOP.


Bind Vop / bind Export > My understanding can create a new attribute name or using an incoming attribute name to change existing attribute values. AKA similar to using the parameter vop ? . With the Bind export just automatically being set to export the values. ? But in SOPs the there is no variable mapping nor the ability to apply variable mapping.

The new Add Attrribute > not sure whats going on but I can pipe data into it and the attribute values are different from the bind export vop..weird …..

Rob

circusmonkey
Add attribute has changed and leads to Bind VOp and BindExport VOP.

Bind Vop / bind Export > My understanding can create a new attribute name or using an incoming attribute name to change existing attribute values. AKA similar to using the parameter vop ?

Correct. It is exactly the same as the parameter VOP, just less parameters. Bind was added in 12.5 as a workflow improvement to clean up the networks by auto-coloring attribute nodes and reducing the number of settings you faced.

With the Bind export just automatically being set to export the values. ? But in SOPs the there is no variable mapping nor the ability to apply variable mapping.

Correct, just like the parameter VOP the generated attribute has no variable mapping. You can create one with an Attrib Create (yuck), an Add Attribute VOP, or a Snippet VOP to execute
addvariablemap(0, “myattribname”, “MYVARNAME”);

The new Add Attrribute > not sure whats going on but I can pipe data into it and the attribute values are different from the bind export vop..weird …..

Yes, this is a big difference from the VOP SOP. It had both Add Attribute and Set Attribute combined into one. Now they are separate, so you need two nodes to set it up.

As an aside, Add Attribute was never supposed to be the “proper” workflow for writing to your own point's attributes. It was always supposed to be a Parameter VOP, and then in 12.5, the Bind Export VOP. That said, I can see why you would use it and miss it!

If the big missing feature is the variable map, that is good news. We did have plans in 14.0 to make variable maps unnecessary (which obviously didn't pan out), but if we succeed in those this will be a non-issue.

My test with addattribute:: vs bind export and 25MPoints suggests at least a 3x faster for the bind export.

(This also is another reason why moving to Attrib VOP is good. If you try to do a Bind Export of Cd in the VOP SOP it errors because Cd is a global; while in Attrib VOP it can properly work)

If you can provide a .hip of that add attribute vop wiring that is confusing you, I would like to see it.

Do note that the value for the add attribute is the default for the attribute, not the per-point value.

jlait
If the big missing feature is the variable map, that is good news. We did have plans in 14.0 to make variable maps unnecessary (which obviously didn't pan out), but if we succeed in those this will be a non-issue.

Is it a secret how the replacement feature will work? Possibly using @attributeName in parameter fields? I always found attrib variables cumbersome and it's not propagated everywhere in the software.

jlait
My test with addattribute:: vs bind export and 25MPoints suggests at least a 3x faster for the bind export.

I am using a hotkey for Bind VOP and other common VOPs. I set the Export parameter to When the Input Is Connected. I use this for both getting and setting attributes. Would this be slower than using Bind and Bind Export separately which sets Export parameter to Never for Bind?

I do this so that I can only use 1 hotkey instead of 2.

jlait
Do note that the value for the add attribute is the default for the attribute, not the per-point value.

What's the best way to set a default attribute value in Attrib VOP and AttribWrangle?

There were 2 issues I always encountered in H13:

1. Having to set up default attribute values using AttribCreate before using an AttribWrangle.

2. Having to create a new attribute using AttribCreate before using an AttribWrangle to set attribute values using setpointattrib, etc (Detail mode).

What are the best practices to do these in H14?

pusat
Is it a secret how the replacement feature will work? Possibly using @attributeName in parameter fields? I always found attrib variables cumbersome and it's not propagated everywhere in the software.

That is an idea that I think may be the solution, but I'm not going to commit to anything until we see what works.

jlait
My test with addattribute:: vs bind export and 25MPoints suggests at least a 3x faster for the bind export.

I am using a hotkey for Bind VOP and other common VOPs. I set the Export parameter to When the Input Is Connected. I use this for both getting and setting attributes. Would this be slower than using Bind and Bind Export separately which sets Export parameter to Never for Bind?

I do this so that I can only use 1 hotkey instead of 2.

Bind Export puts down a Bind VOP and sets that to When Input Connected. So your workflow will create the same set of nodes as doing a Bind Export, so there is no difference in behaviour.

jlait
Do note that the value for the add attribute is the default for the attribute, not the per-point value.

What's the best way to set a default attribute value in Attrib VOP and AttribWrangle?

There were 2 issues I always encountered in H13:

1. Having to set up default attribute values using AttribCreate before using an AttribWrangle.

2. Having to create a new attribute using AttribCreate before using an AttribWrangle to set attribute values using setpointattrib, etc (Detail mode).

What are the best practices to do these in H14?

Did the attribute exist before?

With AttribWrangle, if you don't need to change the default of an existing attribute, but just want to ensure the attribute gets your default if it is created, you can use the prototyping to define your @ binding. This is possible in 13.0 as well.


float @mass = 1;
int @id = -1;


The prototype isn't to be confused with an assignment (which it sadly looks like); this in an attribwrangle will not change the mass value or id of the incoming particles. It will just ensure that if the attribute did not exist, its default will be set to 1 and -1 respectively, and that will then be the default you get.

As an added bonus, if you prototype variables you can just refer to them as @mass and @id without worrying about the f or i prefixes, since you have expressly determined the type.

The AttribWrangle in 14.0 has an option for “Enforce Prototypes”. This requires all @ bindings to have a prototype (even implicit ones!) which is very useful if you are making very long pieces of code and are afraid you'll type @nunpt by accident and not be able to find your typo.

If the attribute already exists and you want to change its prototype, in 14.0 you can use addattrib()

addattrib(0, ‘point’, ‘mass’, 1.0f);
addattrib(0, ‘point’, ‘id’, -1);


Note that the type is inferred by the default value, so you must do 1.0, not 1, or it might decide on making mass an integer attribute.

As for VOPs in 14? The Add Attribute VOP is the way to go and invokes the above addattrib() code. Attached is an example of changing the default and how it affects newly merged points.

jlait
That is an idea that I think may be the solution, but I'm not going to commit to anything until we see what works.

Cool, I did submit this exact RFE back in the day , but wasn't submitted to SESI devs due to groups using the same syntax It could still work without c.o.n.f.l.i.c.t.i.n.g with group fields IMO. (Why is that word marked as spam?)

jlait
Did the attribute exist before?

No they didn't exist. I needed them to have a default and only change what I need. For example all colors are white, except the ones I overwrite in AttribWrangle which could be red, etc.

jlait
With AttribWrangle, if you don't need to change the default of an existing attribute, but just want to ensure the attribute gets your default if it is created, you can use the prototyping to define your @ binding. This is possible in 13.0 as well.


float @mass = 1;
int @id = -1;

I didn't know that. Can you overwrite it afterwards though? Also I feel this won't work if you need the attribute created with a default but also write to them in another mode, i.e. Detail Mode.

For example, you want to create colored geometry in a single AttribWrangle using Detail mode. You want to create a default point color and then change the point colors you want in the same node. AFAIK this can't be done in H13. Because you only have setattib functions and they require the attrib to be created. If I use the @ syntax, then they won't be point attributes, but detail.

Am I missing a key point?