Hi;
Is there any way to change the primitive numbers?
Thanks.
Best Regards.
Change the primitive numbers
9689 16 1-
- mmtpour
- Member
- 53 posts
- Joined: May 2006
- Offline
-
- goldfarb
- Staff
- 3455 posts
- Joined: July 2005
- Offline
-
- mmtpour
- Member
- 53 posts
- Joined: May 2006
- Offline
-
- mmtpour
- Member
- 53 posts
- Joined: May 2006
- Offline
-
- edward
- Member
- 7732 posts
- Joined: July 2005
- Offline
-
- mmtpour
- Member
- 53 posts
- Joined: May 2006
- Offline
-
- Simon
- Member
- 2199 posts
- Joined: July 2005
- Online
-
- edward
- Member
- 7732 posts
- Joined: July 2005
- Offline
-
- Simon
- Member
- 2199 posts
- Joined: July 2005
- Online
True, but its bound to work unless you make the curves with the wrong point order in the first place, ie you build one left to right and the others right to left. But in that case your method won't work either….
Or of course if you deliberately mess things up with a reverse sop. :twisted:
For these situations i have a “sort by minimum energy” sop, this is used in this exact situation when you want to create a skin. What it does is compare different configurations and sorts the points based on the configuration with the lowest total edge length in the final created surface. Its quite handy if you aren't in control of the point ordering for your input curves.
Or of course if you deliberately mess things up with a reverse sop. :twisted:
For these situations i have a “sort by minimum energy” sop, this is used in this exact situation when you want to create a skin. What it does is compare different configurations and sorts the points based on the configuration with the lowest total edge length in the final created surface. Its quite handy if you aren't in control of the point ordering for your input curves.
The trick is finding just the right hammer for every screw
-
- mmtpour
- Member
- 53 posts
- Joined: May 2006
- Offline
-
- edward
- Member
- 7732 posts
- Joined: July 2005
- Offline
Simon
True, but its bound to work unless you make the curves with the wrong point order in the first place, ie you build one left to right and the others right to left. But in that case your method won't work either
PolyPatch works with *point* order as opposed to *vertex* order. These can be different. So by inserting a Reverse SOP, it just changes the vertex order, but _not_ the point order. That's why the “sort by vertex” method would produce different results than the “sort by primitive”. See attached.
You're right though, I would probably expect the “sort by vertex” result if I have my curve reversed and not the “sort by primitive” result.
-
- Simon
- Member
- 2199 posts
- Joined: July 2005
- Online
PolyPatch works with *point* order as opposed to *vertex* order. These can be different. So by inserting a Reverse SOP, it just changes the vertex order, but _not_ the point order. That's why the “sort by vertex” method would produce different results than the “sort by primitive”. See attached.
yes i know, i'm just saying that in most cases you won't have the vertices reversed and not the points too. In those cases both methods break.
If someone has maliciously inserted random reverse sops then yes the “primitive sort” is a nice way out of it… :wink:
However wouldn't it be nice if there was a “built-in” method to sort situation where both points and vertices are randomly reversed?
The trick is finding just the right hammer for every screw
-
- edward
- Member
- 7732 posts
- Joined: July 2005
- Offline
Yep, it sounds like your “minimum edge-length result” comes pretty close. I was just noting that we could make our solution insensitive to vertex order, although that may or may not be desired.
Since we have a particular flat and world aligned patch, we could also just fix your random point order result by adding a sort points along vector (1, 0, 0).
Since we have a particular flat and world aligned patch, we could also just fix your random point order result by adding a sort points along vector (1, 0, 0).
-
- edward
- Member
- 7732 posts
- Joined: July 2005
- Offline
-
- Simon
- Member
- 2199 posts
- Joined: July 2005
- Online
edward
Yep, it sounds like your “minimum edge-length result” comes pretty close. I was just noting that we could make our solution insensitive to vertex order, although that may or may not be desired.
Since we have a particular flat and world aligned patch, we could also just fix your random point order result by adding a sort points along vector (1, 0, 0).
It's closed shapes that get tricky…. the minimum edge length works pretty well in those situations. I do it just with a user specified seed point on the first profile and then only check edges that join to that initial point.
Maybe you have a better trick for those situations?
edward
BTW, I think it would probably be better for PolyPatch to first follow primitive order, then followed by vertex order.
I thought that sop was just a hangover from prisms, I never use it myself.
Just skin and convert to Nurbs…. and as far as I know skin uses vertex order….
The trick is finding just the right hammer for every screw
-
- edward
- Member
- 7732 posts
- Joined: July 2005
- Offline
Yes, the PolyPatch is indeed a holdover from PRISMs. For real complicated shapes, I wonder if it isn't better to start using techniques closer to the point cloud reconstruction methods. I think they also use minimum energy approaches.
For more regular shapes, I imagine someone can always come up with a simpler heuristic for specific situations. If it's a tube say, then do something find the average fitting plane across each individual closed curve primitive and then sort according to that plane's normal. Pick a seed point on any one of the curves and propagate it to adjacent primitives, and then finally sort the point numbers based on that. However, that's assuming a lot about the input geometry.
For more regular shapes, I imagine someone can always come up with a simpler heuristic for specific situations. If it's a tube say, then do something find the average fitting plane across each individual closed curve primitive and then sort according to that plane's normal. Pick a seed point on any one of the curves and propagate it to adjacent primitives, and then finally sort the point numbers based on that. However, that's assuming a lot about the input geometry.
-
- Ondrej
- Staff
- 1072 posts
- Joined: July 2005
- Offline
I wouldn't call either PolySpline or PolyPatch holdovers from PRISMS. I can remember both of them being introduced into Houdini (from PRISMS), despite Houdini's existing spline capabilities. That implies there was either demand or a specific reason, though which, and what it might have been, I can no longer recall.
Not that it really matters whether we call them holdovers or not.
Not that it really matters whether we call them holdovers or not.
-
- Quick Links