Hi,

Does anyone know if the Intersect VOP (i.e. raytracing in SOPs) works inside the AttribVOP (as opposed to the standard VOP SOP) in 13.0.xxx?

My testing indicates it does not however I might be doing something wrong. It works fine in the VOP SOP.
Cheers,

Peter B

it does work, but if you are using N from globals in AttribVOP to set raydir (or anything) you actually need to have N attribute present on input geo, it will not compute it as VOP SOP does

Ahhhh that might be it, thanks! Hope that's fixed in H14…

If I remember correctly this is by design. SESI doesn't want magical stuff happening in nodes like VOPSOP did with normals. You only get/set what you explicitly do.

THen they need to remove the input from the “global” or somehow make that obvious… though normals are so basic it seems extremely counter intuitive not to have them available.

There was a time a few months back in the alpha where the general CVEX context in SOPs (Attribute Wrangle SOP and Attribute VOP SOP) did not do the magical pre-computation of surface Normals N if you queried them.

This now works just fine for me in recent builds (Since October???).

Attribute Wrangle now will initialize surface normals if you:

@N = @N;

and inside Attribute VOP SOP, just wire the input N to whatever you want and if there are no input surface point Normals, will initialize them for you.

See the attached example of using the Intersect VOP in an Attribute VOP SOP.

Is this what you are after Peter?

Yup, perfect thanks!

pusat
If I remember correctly this is by design. SESI doesn't want magical stuff happening in nodes like VOPSOP did with normals. You only get/set what you explicitly do.

Implicit normal computation has been added to H14. Otherwise it would be way too cruel to remove VOP SOP!

The implicit normal RE-computation that the VOPSOP did has been moved to a toggle on the Attrib VOP, off by default. This engaged if you changed P, had N, and it not write to N. The old VOP SOP would then re-compute N. The Attrib VOP only does this if the “Update Normals If Displaced” is set. This is off by default as it can be quite costly and surprising. (More than a few bugs were submitted about the old VOP SOP behaviour)

jlait

pusat
If I remember correctly this is by design. SESI doesn't want magical stuff happening in nodes like VOPSOP did with normals. You only get/set what you explicitly do.

Implicit normal computation has been added to H14. Otherwise it would be way too cruel to remove VOP SOP!

The implicit normal RE-computation that the VOPSOP did has been moved to a toggle on the Attrib VOP, off by default. This engaged if you changed P, had N, and it not write to N. The old VOP SOP would then re-compute N. The Attrib VOP only does this if the “Update Normals If Displaced” is set. This is off by default as it can be quite costly and surprising. (More than a few bugs were submitted about the old VOP SOP behaviour)

I agree, having to compute the normals after AttribVOP was annoying But if you just connect N to N, then is it an expensive operation?

I assume the point normals are known to Houdini and this operation just stores them in an attribute, thus is not recomputed?

If there is an N attribute, it is passed directly to VEX, so it has no extra overhead.

If there is no N attribute, then we compute the normals into a temporary array and stream those into the VEX function. This uses the standard normal computation so should be same speed as using a Normal SOP.

jlait
If there is an N attribute, it is passed directly to VEX, so it has no extra overhead.

If there is no N attribute, then we compute the normals into a temporary array and stream those into the VEX function. This uses the standard normal computation so should be same speed as using a Normal SOP.

Thanks that's good news.