When I attempt to adjust the P value in a primitive Attribute VOP, I get no change. Is this how it's supposed to work?

It seems like the viewport surface normals don't redraw when edited in an attribute vop (primitive) either.

As far as P goes, I think in a primitive VEX context the variable is just a “virtual” P and is dynamically generated from the points attached to it. Which must make it read-only (though I don't see why the points couldn't be dynamically adjusted by changing the primitive P).

Cheers,
Jon

It's a little weird having to rely on the primitive sop when there's an attribute vop that allows processing of primitives… meanwhile we're encouraged to use the attribute vop instead of the point sop…

Please submit a bug about the normals not updating.

P is a virtual attribute which is thus read-only. I can see how it would be nice to have a short cut for running over packed primitives to adjust their P values directly, but the effect of writing to P becomes ill-defined when we have primitives with more than one point and/or share points.

If you are working with single-point primitives you can do:


setpointattrib(0, ‘P’, @ptnum, myP);


taking advantage of @ptnum being bound to the first point of your primitive automatically.

To mimic the Primitive SOP's transform options, you should transform all the points of the primitive.


int pts = primpoints(0, @primnum)
foreach (int pt; pts)
{
vector pos = point(0, ‘P’, pt);
// transform pos
setpointattrib(0, ‘P’, pt, pos);
}

This being the first time I've attempted to use the primitive setting on the attribute vop, I was imagining that the P for a primitive would be its centroid, which seems to be the way that the primitive sop handles it. I guess I didn't consider that it would still be representing the point positions since the UI gives the impression that you're processing primitives.

I guess you're still actually processing points, not primitives, but just gain access to primitive attributes?

You are processing primitives. The total number of times your vex function is called is determined by the number of primitives, not the number of points.

But you can't move primitives. You can only move the points that are attached to the primtiives. When you apply a transform in the Primitive SOP, two things happen:
1) The points of the primitive are transformed by that amount
2) The primitives intrinsic transform (a 3x3 matrix, not including the translation/center of the primitive) is rotated/scaled by that amount.

I'm still not sure what sort of primitives you are operating on. But I'd consider using the new Deformation Wrangle which lets you provide an explicit xform to a set of points and implicitly transfer them to the owning primitives. It can also handle things like rotating normals, etc.

I was imagining that the P for a primitive would be its centroid, which seems to be the way that the primitive sop handles it. I guess I didn't consider that it would still be representing the point positions

Your imagination is correct! It does represent the centroid. However, if you want to *write* to P, there is no way to do that without changing the point positions that were used to calculate it.

I think this comes from the misconception that when you use SOPs like Transform or Primitive SOP, etc that they seem to work on the whole geometry without transforming its points one by one. But they indeed transform the points.

So if you want to transform a piece of geometry, there is no other way than transforming its points. Same thing goes for primitive P even if it's done internally.

Thanks for the info!

Found myself in the same position as the OP as I was searching for the same issue. I promote the point attrib to primitive attrib, it still doesn't work. Why is the point attribute for primitive is read only or hidden?



Although I've learnt the lesson the hard way that for manipulating geometry using attrib vop directly , I have to run it over points only.

proceduralist
Why is the point attribute for primitive is read only or hidden?

Both of jlait's posts above in this thread answer your question.

Specifically:

jlait
P (on prims) is a virtual attribute which is thus read-only. I can see how it would be nice to have a short cut for running over packed primitives to adjust their P values directly, but the effect of writing to P becomes ill-defined when we have primitives with more than one point and/or share points.