A fellow tech artist and I are trying to solve a geometry issue in VEX and we've run into a snag. Essentially what we are doing is removing a quad prim and replacing it with 2 triangles, essentially dividing the quad. By changing the number of primitives we are obviously causing all @primnums above the replaced primitive's number to reorder. It looks fine in the viewport but if we attempt to fetch the points for said prim using primpoints() it returns the points for the prim index 1 less than our current primitive.

Im attaching an image to sort of highlight the problem. I'm guessing the issue is happening because primpoints() is accessing the original mesh and not the mesh after the 2 triangles have been added, thus the primnums havent updated yet. Is there a way to rectify this inside of the detail wrangle or do we need to use a second wrangle after?

Yes, another wrangle that follows would be needed, or….

And your right in your assessment.

Wrangles in detail mode do not execute in ‘logical’ order as assumed if there is any involvement with changing geometry within the ‘scene’ on any specific statement line e.g. adding/deleting - prims, points, vertices etc. Although those operations will be carried out as per the statement; The following statements will not be able to access the scene geometry with the new status. It still will only be able to access the original scene status at the beginning pre-code of the wrangle. With a subtle exception as for example; You could add a point and use the return value of the new point number at any point along your statement lines. So long as any geometry action has no effect relative to the scene, you will be ‘safe’. But any action that makes a direct change to geometry will not give desired results if your trying to reference those new changes…unless,

Alternatives to having additional wrangles is to if possible store algorithm results/function returns to local wrangle variables and act on those values. Once the desired calculations are made, you then can apply it to the scene level with your last lines of code in the wrangle.

Although I do not know what exactly it is your trying to do, you could supply a hip if you want an example of how to do it in a single wrangle(if possible or worth the coding effort).

BabaJ
Yes, another wrangle that follows would be needed, or….

And your right in your assessment.

Wrangles in detail mode do not execute in ‘logical’ order as assumed if there is any involvement with changing geometry within the ‘scene’ on any specific statement line e.g. adding/deleting - prims, points, vertices etc. Although those operations will be carried out as per the statement; The following statements will not be able to access the scene geometry with the new status. It still will only be able to access the original scene status at the beginning pre-code of the wrangle. With a subtle exception as for example; You could add a point and use the return value of the new point number at any point along your statement lines. So long as any geometry action has no effect relative to the scene, you will be ‘safe’. But any action that makes a direct change to geometry will not give desired results if your trying to reference those new changes…unless,

Alternatives to having additional wrangles is to if possible store algorithm results/function returns to local wrangle variables and act on those values. Once the desired calculations are made, you then can apply it to the scene level with your last lines of code in the wrangle.

Although I do not know what exactly it is your trying to do, you could supply a hip if you want an example of how to do it in a single wrangle(if possible or worth the coding effort).

Thanks so much for the suggestions. We somewhat solved the issue by just using setprimattrib() on the modified prims and then fixed them outside of detail wrangle.

Our method is still pretty gross and broken but it was mostly a thought experiment. There's still some issues with winding order on the newly created tri's causing some tearing back to point 0 on some seeds (probably an out of range thing). The idea was to try and fix points that were ‘stars’ (having 6 prims associated with them) that were causing issues on an irregular relaxed quadrilateral grid.

I'll attach the broken hip file anyways for people to play with. There's probably a much more elegant solution to this but we are rather new to VEX.

Here's an example that works for all seed variances.(red colored nodes); At least at the wrangle stage output there are no problems.

However it may still need some extra work to prepare for what your really after downstream with the sub-divide nodes.

So in this version, I've changed it to go with multiparms that select which prim and adjacent prims are selected so to avoid big gaps like in the previous file.

I'm sure an algorithm code be written to avoid the big gaps, but this would take more work than I am willing to invest.

For this one you have to manually add/delete a multiparm for each different seed result.(If I knew Python in Houdini better I think it's possible in a python sop prior to the wrangle node, to set up the number of multiparm instances per points that have the threshold of associated prims). Maybe at some point I will ask in the forum under a new heading on how to do this with a simpler example (I haven't been able to find a search result to explain this).

And just to note when you do add a multiparm to just toggle an existing value to get the vex code to update and take into account the newly added multiparm.

BabaJ
So in this version, I've changed it to go with multiparms that select which prim and adjacent prims are selected so to avoid big gaps like in the previous file.

I'm sure an algorithm code be written to avoid the big gaps, but this would take more work than I am willing to invest.

For this one you have to manually add/delete a multiparm for each different seed result.(If I knew Python in Houdini better I think it's possible in a python sop prior to the wrangle node, to set up the number of multiparm instances per points that have the threshold of associated prims). Maybe at some point I will ask in the forum under a new heading on how to do this with a simpler example (I haven't been able to find a search result to explain this).

And just to note when you do add a multiparm to just toggle an existing value to get the vex code to update and take into account the newly added multiparm.

Thanks so much for your example files and your suggestions. We ended up solving the issues for all ‘seeds’ by breaking up our logic into multiple wrangles and then running the process through a for loop. I think we have it at a pretty good point at the moment without any breaks. There were some logic issues with the way we were generating the triangles but it seems to be functioning well now.

Here's the file if anyone wants to see our VEX.