Hi,
I've some quick Softimage oriented workflow questions …
I'm trying to work with some point scattered..

- How to query on another geometry, like getting the closest normal of a point (in softimage Get closest point)

- Can we scatter (in softimage generate sample set) in a VOPSOP other than using a scatter SOP.

- Is there an equivalent of the copy SOP on a VOPSOP ?

Noël

for the first question see attached hip file. (hat tip by sanostol)
it is a bit different but does the same.
xyz distance and primitive attribute

NNois
- Can we scatter (in softimage generate sample set) in a VOPSOP other than using a scatter SOP.

addpoint(int geo, vector pos);

From that scattering is possible, but tedious* compared to ScatterSOP.

- Is there an equivalent of the copy SOP on a VOPSOP ?

There isn't. Generally speaking you shouldn't be trying to match ICE to VOP concepts, but rather ICE to entire SOP context. So in terms of CopySOP usual workflow is to make all math in VEX (VOPSOP, attribWranger, PointWrangler whatever), and send it to CopySOP for execution.

* - something like:

for (int x = 0; x < primcount; x++) // primcount to be provided
{
for(int y = 0; y < density; y++) // user's parm density
{
vector pos = 0;
float seed = random(y)*1000;
vector uv = random(x*seed);
// alternatively unified distributed randoms:
// vector uv = random_sobol(x, y);
pos = primuv(1, “P”, x, uv); // sample P of second VOP input at random uv
addpoint(geoself(), pos);
}
}

Yes. I totally understand Noel questions, but seeing how a VOPSOP accepts several entries, the only true reason for doing all that inside the same place is that ICE was the only node-based network in SI.
Not using SOPs at all in Houdini would be severely limiting for most tools and unnecessary.

It is also important to.understand that VOPs are based on the vertex expression (vex) language of houdini . These run on a SOME architecture which.is why they are in many cases as fast as c++ nodes (very highly multithreaded) however , you do reach a point if you are doing things such as mimicking copy sop in VOPs where you lose advantage of such speed since you are bogging your simd with multi data processing per element (obviously, nodes such as point cloud open are REALLY good ad this but slow down when.you are trying to.parse too.much data per point)

In those cases, you can.leverage python, c++, and the inlinecpp python module. However, I tend to reuse as Mich existing functionality as possible

Also important to note is that splitting your process into multiple nodes (i.e. Multiple slow, multiple VOPs, etc.) is smart because houdini will only cook nodes that HAVE to be.cooked depending on what parameter changes, whereas a vopsop node is considered a single cook

That clarification in using vop sops is very helpful. Thanks for detailing the advantages/disadvantages in using them in the context of a larger sop network.

For SI users:

It has helped me to visualize the usage of a vop sop node by thinking of it in SI terms as the execution of a single ICE execution port within a larger ICE tree (I know this isn't exactly the same thing technically…but still). With that analogy, then sop nodes like the scatter SOP or the Copy SOP are each like a compound, evaluated on individual ICE ports within the larger ICE tree.

Because of Houdini's very capable management of attributes and contexts, you can really think of the entire sop network as an ICE tree.

Np and btw they run on a SIMD architecture (single instruction, multiple data), not a SOME architecture that was a typo