Hello guys. The other day I created a "vex-carve" code example, because I was having problems with the carve node. The issue is that it seems to me that the carve node always assumes that the intrinsic uv's on curves are based on an even distribution of points. So, typically what you get if you resample. However, that is not my use case. Actually, I want the carve to be done on curves with an uneven distribution of points. My vex code works fine and is fast, especially if I wrap it in a compile block. But, it is still not as fast as the carve node itself (I guess because that node must be written in C++).

So, my question is then: is there some way to get the carve node to understand converted uv's? Animatrix and others have showed me how to use the primuvconvert function to get correct behaviour when dealing with this issue, and that is what my code uses. But, now I am curious if there is a way to get it to work with the carve node?

Thanks,
Dag

I'm assuming the issue you're having is when using the carve node on a polyline.
Perhaps you could run that line through a convertline node - and then apply your carve node per prim as needed, reforming back together your single polyline after you get the desired shifts.

@BabaJ - yes, I am carving poly lines. You can see from the attached images what the difference is between my custom carve and the carve sop. I am not sure about what you mean when you say to apply the carve node per prim as needed. This just results in a bunch of separate, free floating primitives, which is not what I want. To build something around this in order to mitigate that behaviour would surely negate the slight performance advantage the carve node has, right?

So, can I then assume that getting the desired behaviour, that you can see in the custom vex carve, is not possible with the carve sop?

Thanks,

Dag

What I was showing you is but one step if you wanted to use the carve sop.(I thought you would be able to see the other steps).
Just calculate your total distance for the entire segment, get the ratios of each individual segment per total length, which will let you know what 'uv' distance each segment is. From there you can carve(with the sop)the specific segment in which your target uv is lying.

To build something around this in order to mitigate that behaviour would surely negate the slight performance advantage the carve node has, right?

How do you know the carve sop has better performance when it's not doing what you have with vex?
Did you try comparing a single segment with vex(only two point ends) compared to the carve sop?