How would u sort these prims?
1989 9 0- JonathanPie
- Member
- 14 posts
- Joined: Dec. 2017
- Offline
Hi,
i have this geometry made from a curve, like in the picture. My main goal is to sort the prims, so that the primnumbers are advancing correctly, like 0, 1, 2, 3… and so on. I did this with just points in Vex, but its somehow a lot harder with prims for me.
Best solution i came up with is some serious Vex with Half-Edges or primneighbours, but moving the prims or primpoints seems a bit overly complicated. Is there a way to just swap prim numbers? In the picture prim 2 should have the place of prim 61, so if i swap them, i wouldnt need to handle a lot of point data.
But to be honest, if i look at all the work i had to sort some prims i cant believe this is the best way to go. Sort didnt work for me. Using the starting curve was another idea. i Resampled the curve and copied spheres on it, but couldnt find a way to check, wether the spheres are overlapping the prims from the picture.
Am i overthinking this? Is there a much neater and faster way?
i have this geometry made from a curve, like in the picture. My main goal is to sort the prims, so that the primnumbers are advancing correctly, like 0, 1, 2, 3… and so on. I did this with just points in Vex, but its somehow a lot harder with prims for me.
Best solution i came up with is some serious Vex with Half-Edges or primneighbours, but moving the prims or primpoints seems a bit overly complicated. Is there a way to just swap prim numbers? In the picture prim 2 should have the place of prim 61, so if i swap them, i wouldnt need to handle a lot of point data.
But to be honest, if i look at all the work i had to sort some prims i cant believe this is the best way to go. Sort didnt work for me. Using the starting curve was another idea. i Resampled the curve and copied spheres on it, but couldnt find a way to check, wether the spheres are overlapping the prims from the picture.
Am i overthinking this? Is there a much neater and faster way?
- BabaJ
- Member
- 2039 posts
- Joined: Sept. 2015
- Offline
I find usually with something like this, it's best to revisit how you started off constructing the geometry - from there plan out how you will construct the geometry with the intent to have a corresponding set of ordered primitives(numbering).
Can't suggest what to do in your case as you haven't included a hip file.
Can't suggest what to do in your case as you haven't included a hip file.
- JonathanPie
- Member
- 14 posts
- Joined: Dec. 2017
- Offline
Thx for your help BabaJ. I attached the hip-file. My aim was to create a procedural map-tool. What u see is supposed to be a map with a higher groundlevel formed with the curve. The border prims of that higher landmass should be something like mountains or cliffs. So why do i need them sorted? Because i wanted to be able to change some of the border prims for ramps or different geo. My idea was, it would be easiest to change some values in an array like 06-12, so i would get 6 prims form 6 to 12 with cliffs or leading to higher ground or lower.
- Aizatulin
- Member
- 475 posts
- Joined: July 2005
- Offline
- BabaJ
- Member
- 2039 posts
- Joined: Sept. 2015
- Offline
That's a good example from Aizatulin, better than the one I was going to post.
But it's also a little ‘strange’ to me how it does work. Never used the xyzdist() function.
It seems the x component of the uv represents the normalized portion of the perimeter distance.
And although not used, the actual distance values seem to indicate the function takes a ‘look’ at the wrangle node itself to determine how many prims are being run over and divides that number into the perimeter length - taking into account the angles of the prims sides.
Anyone know if this is sort of what's happening?
But it's also a little ‘strange’ to me how it does work. Never used the xyzdist() function.
It seems the x component of the uv represents the normalized portion of the perimeter distance.
And although not used, the actual distance values seem to indicate the function takes a ‘look’ at the wrangle node itself to determine how many prims are being run over and divides that number into the perimeter length - taking into account the angles of the prims sides.
Anyone know if this is sort of what's happening?
- Aizatulin
- Member
- 475 posts
- Joined: July 2005
- Offline
Hi BabaJ,
If the geometry is a surface, you need two (float)parameters (uv.x and uv.y), to evaluate the position on the surface. xyzdist() works for surfaces as well. If you have more than one primitive, the prim integer will determine the primitive with the closest distance to the point.
BabaJYes this is right (afaik). xyzdist() measures the closest distance from a point to a geometry. The return value of xyzdist() is the distance. If the geometry is a (parametric) curve, the x component (uv.x) is necessary to evaluate the position on the curve, which can be done with the primuv() function with the ‘P’ attribute (since primuv() is an overloaded function, it doesn't even matter, if you put in uv.x or uv).
It seems the x component of the uv represents the normalized portion of the perimeter distance.
If the geometry is a surface, you need two (float)parameters (uv.x and uv.y), to evaluate the position on the surface. xyzdist() works for surfaces as well. If you have more than one primitive, the prim integer will determine the primitive with the closest distance to the point.
- JonathanPie
- Member
- 14 posts
- Joined: Dec. 2017
- Offline
@ Aizatulin
Thx for your method with the help of xyzdist() and primuv(). Im always keen on exploring new functions or nodes, so i will take a closer look at your solution to learn from it. Very much appreciated.
@ BabaJ
BabaJ, i followed your advice and came up with some things. The by far easiest method works best even without vex. just resample the curve fuse it two times with the right plane-size and snap-value in mind and finally copy it to the points.
I basicly wasted a week on this. All i needed was just planning ahead a bit At least i got a lot better in Vex
Thx for your method with the help of xyzdist() and primuv(). Im always keen on exploring new functions or nodes, so i will take a closer look at your solution to learn from it. Very much appreciated.
@ BabaJ
BabaJ
I find usually with something like this, it's best to revisit how you started off constructing the geometry - from there plan out how you will construct the geometry with the intent to have a corresponding set of ordered primitives(numbering).
BabaJ, i followed your advice and came up with some things. The by far easiest method works best even without vex. just resample the curve fuse it two times with the right plane-size and snap-value in mind and finally copy it to the points.
I basicly wasted a week on this. All i needed was just planning ahead a bit At least i got a lot better in Vex
- BabaJ
- Member
- 2039 posts
- Joined: Sept. 2015
- Offline
- Aizatulin
- Member
- 475 posts
- Joined: July 2005
- Offline
- BabaJ
- Member
- 2039 posts
- Joined: Sept. 2015
- Offline
This example Jonathan gave reminded me of how often people would like to just re-order the prim/point numbers on the fly.
So I thought of doing something like this for quit some time now and tried it out.( nodes in red netbox )
It takes the numbers listed in the basegroup parameter of the group node so that one can manually create the list of prims in this case they want to be ordered.
The only downside of this is that in order to work the numbers of the prims selected in the viewport has to be done in a way that the group node lists them out as selected order.
The only way I have found to make this work reliably is by shift + clicking each primitive in succession.
Perhaps an RFE for using saying the brush selection where one can just click and drag their whole selection order would make using what I have more usefull.
So I thought of doing something like this for quit some time now and tried it out.( nodes in red netbox )
It takes the numbers listed in the basegroup parameter of the group node so that one can manually create the list of prims in this case they want to be ordered.
The only downside of this is that in order to work the numbers of the prims selected in the viewport has to be done in a way that the group node lists them out as selected order.
The only way I have found to make this work reliably is by shift + clicking each primitive in succession.
Perhaps an RFE for using saying the brush selection where one can just click and drag their whole selection order would make using what I have more usefull.
-
- Quick Links