VEX and VOP networks can now create geometry in the Attrib Wrangle SOP, Attrib VOP SOP, Volume VOP SOP, and Geometry VOP DOP nodes using the new addpoint, addprim, and addvertex functions.

Does this mean that we cannot call the addpoint() etc functions from a vex operator type at the geometry level? I am noticing that it doesn't throw any errors but it also doesn't do anything.

-S

More than possible but a simple example file showing how to create a single point is most certainly in order.

Just add a Null SOP and append an Attribute Wrangle SOP. The key is to set the RunOver to “Detail Only Once” and then use the addponit() expression like this:

int newpt = addpoint(geoself(), {0,1,0});
or more simply:
addpoint(geoself(), {0,1,0});
See the example file.

This file will be submitted for inclusion as an example for the Attribute Wrangle SOP.

“sop” context VEX functions do not support geometry creation, only the “cvex” context VEX functions. The VOP SOP and Point Wrangle thus do not support geometry creation.

Given that I didn't even know about the Attrib Wrangle until about a week ago, maybe we could get a nice chart or overview of the now fairly numerous VEX/VOP options? Please?

Yes it is a bit counter intuitive to me to use attribwrangles to do geometry creation / deletion. Is there any reasoning behind why sop context vex functions don't support this? Is this planned for the future?

Do we have the ability to add multiple points? When I use a for loop, it only seems to create a single point for each existing point:

for ( int i = 0; i < 100; ++i );
addpoint ( geoself ( ), @P );

I was also hoping to have the ability to insert new points on edges.

I couldn't test multiple point creation but a quick test showed that Point Generate SOP (Per Point option) is infinitely faster than VEX addpoint.

stevegh
Yes it is a bit counter intuitive to me to use attribwrangles to do geometry creation / deletion. Is there any reasoning behind why sop context vex functions don't support this? Is this planned for the future?

The sop vex contexts are a completely different code path from the cvex contexts. Since the cvex contexts are the same across DOPs and SOPs, they are the ones that have got the most attention.

Our plan is to transition away from the sop vex context as soon as the cvex one has equal functionality. Probably this will consist of the pointwrangle becoming pointwrangle::2.0 and embedding an attribwrangle inside of it, for example.

pusat
for ( int i = 0; i < 100; ++i );
addpoint ( geoself ( ), @P );

The semicolon at the end of the for statement causes it to not execute the code underneath. We should probably generate a warning with this code like most compilers.

I was also hoping to have the ability to insert new points on edges.

Technically I think you could do this with the setprimvertex() and addprimvertex() magic, but it wouldn't be fun or easy. This is a good RFE.

I couldn't test multiple point creation but a quick test showed that Point Generate SOP (Per Point option) is infinitely faster than VEX addpoint.

I would hope so, as we did a lot of work trying to get point generate fast :> Generating 50 million points seems 20x slower with VEX than with the Point Generate. Does that match the sort of speed difference you were seeing?

This way works as well:

vector seed = {1.001,10.001,100.001};
for(int i = 0; i < 100; ++i )
{
addpoint(geoself(),set(rand(i+seed.x),rand(i+seed.y),rand(i+seed.z)));
}


Returns a random distribution of 100 points between 0,0,0 and 1,1,1

Thank you guys. I didn't realize I had that extra semicolon. Sorry about that. I just assumed addpoint somehow optimized for same point positions.

newedgepoint or insertpointonedge or some other cool function would be very welcomed

Point Generate shows that it's extremely optimized. I just wasn't sure what else you could have done to make it faster other than creating new points on each thread. It's 10x faster than VEX for 1M points, 13x faster for 10M, and about 17x faster for 50M points.

I was curious if most topology changing operators could be implemented using VEX now that we have add/remove points, i.e. Catmull Clark subdivision, Fractal SOP, Relax, etc. If so, I would be really curious to see the speed differences. Actually this might be a good case for multi-threading existing SOPs

In the help files under the FindShortestPath node are some wrangle nodes in the advanced example file (specifically in the section that creates the grid).

This generates a grid between points on a point cloud within certain parameters.

This is very efficient as generating a grid this way allows you to bypass a lot of nodes. Its this fast because connections are only made if they meet the required criteria. instead of the alternative which involves creating millions of primitives and points only to have to cull it out afterwards. Which can be up to a hundred times more expensive.

And its multi-threaded, making this extremely cheap in both memory and CPU cost.

I've since added some extra features (which where quite simple to set up) such as: maximum angle of slope, direction locking (to avoid overlapping) and forbidden connection lengths.

Ask me for the code snippets if you need them.

jeff
This way works as well:

vector seed = {1.001,10.001,100.001};
for(int i = 0; i < 100; ++i )
{
addpoint(geoself(),set(rand(i+seed.x),rand(i+seed.y),rand(i+seed.z)));
}


Returns a random distribution of 100 points between 0,0,0 and 1,1,1

Thanks for the example Jeff!!!

Something else I've noticed, and this becomes quite frustrating when going through the documentation, is that it appears as though most VEX contexts don't allow a function to return arrays. I know in the docs we have this example:


vector rgb_array()
{
return { {1, 0, 0}, {0, 1, 0}, {0, 0, 1} };
}


But I get a syntax error everytime, in every context I try. What is the dealy-o?

stevegh
Something else I've noticed, and this becomes quite frustrating when going through the documentation, is that it appears as though most VEX contexts don't allow a function to return arrays. I know in the docs we have this example:


vector rgb_array()
{
return { {1, 0, 0}, {0, 1, 0}, {0, 0, 1} };
}


But I get a syntax error everytime, in every context I try. What is the dealy-o?

Try it in CVEX.