project "Houdini, a great modeler"
280429 609 9- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
polysplit - much better than what it used to be. In fact, much better than XSI's cut tool overall: the MMB scrolling up and down to increase/decrease the number of snap points on the edge is a brilliant idea. It also crosses an unlimited # of polygons, unlike the XSI's cut. This is what I call different for the sake of being better, rather than for the sake of being different.
There are a few things where it could be better though.
Here's how I can keep, or not, the start of a cut line by MMB instead of LMB in Soft:
Another thing, which is more general, not just for polysplit, is the Enter to complete thing. It's really disruptive, for any viewport creation process, not just for modeling.
Related to finishing the active cutting session, is the fact that once you finish it, it's really finished. What I mean by that, is that if you want to continue cutting but starting from somewhere else, you have to call another polysplit op. This is not a huge deal, although it would be cool to be able to commit w/o exiting the tool, by MMB, which currently toggles “edge snap” the same thing being achieved with the scroll wheel once you reach 1 divisions; nobody will go to 100 divisions to make this a necessity to have a hotkey for and besides, you can toggle manually should you ever increase the division # that much.
The “keep starting point” feature shown in the .gifs above, could be activated by ctrl+LMB.
In the lower viewport area where the tool tips are, it says “hold ctrl to disable edge snapping” and nothing changes.
At first I thought it's an actual edge snapping disable feature, in case you want to place a point very close to an edge, but apparently it refers to snapping to the divisions when they're active. Which you can already disable with MMB. Or maybe that was the intention - actual edge snapping disable - and it's not working due to a bug.
Either way, I don't think such a feature is needed - one can just zoom in a lot if you want to place a point very close to an edge, 99.99% of the time you want the edge snapping active. Disabling the edge snap (again, not snapping to the edge divisions) should be achieved with that toggle “Edge Snap” currently made with MMB and also with the scroll-wheel down. Very confusing due to redundancy, a possible bug and unclear naming.
Should anyone feel like I'm talking in riddles here, let me know and I'll try to clarify this with pictures.
Now, again, apart from the problems described in the paragraph above, this tool is actually very well implemented and thought out and should the said problems be sorted out, it will probably become the best poly-cut tool in the industry.
p.s. Just an FYI: the “edge divisions” input box accepts negative numbers and even goes there with the scroll wheel once you manually input a value <=1.
There are a few things where it could be better though.
Here's how I can keep, or not, the start of a cut line by MMB instead of LMB in Soft:
Another thing, which is more general, not just for polysplit, is the Enter to complete thing. It's really disruptive, for any viewport creation process, not just for modeling.
Related to finishing the active cutting session, is the fact that once you finish it, it's really finished. What I mean by that, is that if you want to continue cutting but starting from somewhere else, you have to call another polysplit op. This is not a huge deal, although it would be cool to be able to commit w/o exiting the tool, by MMB, which currently toggles “edge snap” the same thing being achieved with the scroll wheel once you reach 1 divisions; nobody will go to 100 divisions to make this a necessity to have a hotkey for and besides, you can toggle manually should you ever increase the division # that much.
The “keep starting point” feature shown in the .gifs above, could be activated by ctrl+LMB.
In the lower viewport area where the tool tips are, it says “hold ctrl to disable edge snapping” and nothing changes.
At first I thought it's an actual edge snapping disable feature, in case you want to place a point very close to an edge, but apparently it refers to snapping to the divisions when they're active. Which you can already disable with MMB. Or maybe that was the intention - actual edge snapping disable - and it's not working due to a bug.
Either way, I don't think such a feature is needed - one can just zoom in a lot if you want to place a point very close to an edge, 99.99% of the time you want the edge snapping active. Disabling the edge snap (again, not snapping to the edge divisions) should be achieved with that toggle “Edge Snap” currently made with MMB and also with the scroll-wheel down. Very confusing due to redundancy, a possible bug and unclear naming.
Should anyone feel like I'm talking in riddles here, let me know and I'll try to clarify this with pictures.
Now, again, apart from the problems described in the paragraph above, this tool is actually very well implemented and thought out and should the said problems be sorted out, it will probably become the best poly-cut tool in the industry.
p.s. Just an FYI: the “edge divisions” input box accepts negative numbers and even goes there with the scroll wheel once you manually input a value <=1.
Edited by anon_user_89151269 - Nov. 28, 2017 12:52:59
- Siavash Tehrani
- Member
- 729 posts
- Joined: July 2005
- Offline
You can Shift+RMB to complete the PolySplit operation. I'm not sure if that's documented somewhere. Should work anywhere else it asks you to hit Enter. I agree with your suggested improvements to splitting in general.
Going back to the snapping issue for a second - it would be a huge improvement to have transient keys for handle detachment/snapping, preferably right next to each other. I don't know how others have fared with the radial menu snapping. I like them for modeling in general but I simply can't get comfortable with it for snapping. It's clunky IMO. I rarely do anything in Maya, but the transient shortcuts for moving handles and snapping quickly became second nature.
Going back to the snapping issue for a second - it would be a huge improvement to have transient keys for handle detachment/snapping, preferably right next to each other. I don't know how others have fared with the radial menu snapping. I like them for modeling in general but I simply can't get comfortable with it for snapping. It's clunky IMO. I rarely do anything in Maya, but the transient shortcuts for moving handles and snapping quickly became second nature.
Edited by Siavash Tehrani - Nov. 29, 2017 01:05:31
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
DaJuice
You can Shift+RMB to complete the PolySplit operation. I'm not sure if that's documented somewhere. Should work anywhere else it asks you to hit Enter. I agree with your suggested improvements to splitting in general.
DaJuice, thanks for the “shift+RMB to complete” tip.
It's not however what I had in mind here, because in order to continue splitting on the same mesh but in some place else, you need to call another polysplit. In Soft for example I MMB and the “polysplit” allows me to continue cutting starting in another place.
Like I said, having to call another operation is not such a big deal, but it would be a nice improvement IMO. Maybe you understood my proposal and just wanted to give me a tip for the general “enter to finish”? Either way, I have to make sure I'm well understood.
Edited by anon_user_89151269 - Nov. 29, 2017 01:45:25
- Richardas
- Member
- 1 posts
- Joined: Feb. 2017
- Offline
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
That's a “repeat last command” type of feature, which is nice. It works for every node and as such, it creates a new one every time you press it. It's exactly the same thing as calling the operation again with the hotkey of your choice.
Anyway, that's the least important “issue” of the polysplit IMO.
Anyway, that's the least important “issue” of the polysplit IMO.
Edited by anon_user_89151269 - Nov. 29, 2017 08:25:02
- julca
- Member
- 219 posts
- Joined: Oct. 2015
- Offline
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
That could prove useful, but currently in XSI that's a relatively easy problem to overcome: cut your line at a random angle, snap the handle on the one point of the new line and pick the edge you've cut into as a reference space to have an axis aligned with it and snap-scale to zero.
It's actually easier done than said.
It's actually easier done than said.
- julca
- Member
- 219 posts
- Joined: Oct. 2015
- Offline
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
- julca
- Member
- 219 posts
- Joined: Oct. 2015
- Offline
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
Just to be clear on what I meant about “reference space” and “Houdini limited transformations”
Even though you can orient the handle after an edge say (after you press ‘ to detach, ; to orient, ’ again to reattach the handle to the geometry, lots of work), you don't see any numerical value change to reflect the new reference system.
I'm starting to think this is an inherent limitation of the current Houdini philosophy, of having the edit node deal with component transformations. There's no “scene global” transformation channels window/tab like in XSI or Max/Maya where you see the values for anything, objects, components, etc.
In Houdini transformations are somehow disconnected, at least on the user interaction dimension, as you have the Object properties tab with transformations and whatnot and for components you have to have an edit node in order too see their local (and local only) coord. You can't have a point just selected and see its global position like in XSI for example, because there are no “scene transformation channels”. In XSI for example you can change a point position from 2 to -2 (global space) just by entering in the transformation values, no need to activate the translate gizmo, or in Houdini's jargon, to call down an edit node.
I wish there was a “global transformation window” in which you can see and change values for anything, objects and components alike, in every space that Houdini currently has and will have at some point. The edit nodes for components could be created at the time of a transformation value change via a numerical input in that window.
This window could pave the way for multiple object editing, which is not possible currently and is a huge deal for modeling.
Even though you can orient the handle after an edge say (after you press ‘ to detach, ; to orient, ’ again to reattach the handle to the geometry, lots of work), you don't see any numerical value change to reflect the new reference system.
I'm starting to think this is an inherent limitation of the current Houdini philosophy, of having the edit node deal with component transformations. There's no “scene global” transformation channels window/tab like in XSI or Max/Maya where you see the values for anything, objects, components, etc.
In Houdini transformations are somehow disconnected, at least on the user interaction dimension, as you have the Object properties tab with transformations and whatnot and for components you have to have an edit node in order too see their local (and local only) coord. You can't have a point just selected and see its global position like in XSI for example, because there are no “scene transformation channels”. In XSI for example you can change a point position from 2 to -2 (global space) just by entering in the transformation values, no need to activate the translate gizmo, or in Houdini's jargon, to call down an edit node.
I wish there was a “global transformation window” in which you can see and change values for anything, objects and components alike, in every space that Houdini currently has and will have at some point. The edit nodes for components could be created at the time of a transformation value change via a numerical input in that window.
This window could pave the way for multiple object editing, which is not possible currently and is a huge deal for modeling.
Edited by anon_user_89151269 - Nov. 30, 2017 13:54:48
- Siavash Tehrani
- Member
- 729 posts
- Joined: July 2005
- Offline
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
I think I've realized why I thought all along that RMB>Align Handle>Start Orientation Picking was buggy is because I used to execute the command without pressing ‘ aka detaching the handle first.
In XSI the change is not just a handle reorientation but an actual reference system change which is also reflected in the transforms values displayed. The picking of the desired reference system of another component is made without “detaching” the handle, you just press MMB when in tweak mode. I thought this feature in Houdini works similarly and the point/edge snapping that occurs when you’re picking without having the handle detached first, is a bug. I even filed a RFE about two yrs ago and I also showed a gif here on forums IIRC. Live and learn.
So here's what this discovery prompted me to reflect upon: why does this command (hotkey ; ) has to have the handle detached first? Why not just press ; and have the handle oriented without the selected component being rotated? Also, why does the handle moves to the picked component? Wouldn't be better if it stayed with the component to be transformed?
I intend to file a RFE for these, but if someone thinks any of these are not a good idea as there are good reasons for why it's like this, let's discuss that.
In XSI the change is not just a handle reorientation but an actual reference system change which is also reflected in the transforms values displayed. The picking of the desired reference system of another component is made without “detaching” the handle, you just press MMB when in tweak mode. I thought this feature in Houdini works similarly and the point/edge snapping that occurs when you’re picking without having the handle detached first, is a bug. I even filed a RFE about two yrs ago and I also showed a gif here on forums IIRC. Live and learn.
So here's what this discovery prompted me to reflect upon: why does this command (hotkey ; ) has to have the handle detached first? Why not just press ; and have the handle oriented without the selected component being rotated? Also, why does the handle moves to the picked component? Wouldn't be better if it stayed with the component to be transformed?
I intend to file a RFE for these, but if someone thinks any of these are not a good idea as there are good reasons for why it's like this, let's discuss that.
- julca
- Member
- 219 posts
- Joined: Oct. 2015
- Offline
- Siavash Tehrani
- Member
- 729 posts
- Joined: July 2005
- Offline
For sure
Select 1 edge or 2 points, handle stays.
Select 2 edges or 3 points, handle moves.
McNistorI think the intended use is to align your selection to another edge/primitive. Personally I've never once used it for that purpose, and you'd still have to detach/move/re-attach your handle to line everything up nicely after orientation-picking. As it is, it's another extra step, and I'd prefer if orientation picking automatically put the handle into a detached state.
So here's what this discovery prompted me to reflect upon: why does this command (hotkey ; ) has to have the handle detached first? Why not just press ; and have the handle oriented without the selected component being rotated?
McNistorI suppose it makes sense if the intent is to directly orient a selection to some other geo, but it definitely shouldn't move the handle when it's detached. Seems like the behavior is:
Also, why does the handle moves to the picked component? Wouldn't be better if it stayed with the component to be transformed?
Select 1 edge or 2 points, handle stays.
Select 2 edges or 3 points, handle moves.
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
DaJuice
Seems like the behavior is:
Select 1 edge or 2 points, handle stays.
Select 2 edges or 3 points, handle moves.
That's not at all what I'm experiencing. The handle moves to the picked component in every case. Maybe I'm not getting what you're trying to say.
I guess the current “snap” of the selected geometry to the picked as reference geometry could prove itself useful (when not detaching the handle) or just the handle snap (when detaching), but it doesn't have to be the default since it's more situational and certainly shouldn't be the only behavior. Most likely it should be a separate command.
For keeping the handle in the original location, Houdini's GC (global control) should be available at SOP level also, as is currently available only at the scene level for some reason. And it's buggy - after you select two objects (with different positions in global space) and activate GC, the handle moves (not by the “right” amount IMO, but that's a matter for a different RFE) as it should, but if you disable it doesn't return.
For the XSI people, GC is a similar option to XSI's CoG (center of geometry).
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
McNistor
And it's buggy - after you select two objects (with different positions in global space) and activate GC, the handle moves (not by the “right” amount IMO, but that's a matter for a different RFE) as it should, but if you disable it doesn't return.
Bug confirmed and logged by Support.
edit: the issue with the “right” amount, I think was living only in my head; now it's dead, I've killed it
Edited by anon_user_89151269 - Dec. 3, 2017 08:30:45
- anon_user_89151269
- Member
- 1755 posts
- Joined: March 2014
- Offline
For anyone interested, I've submitted a RFE regarding symmetry (mirror).
The current one produces bad results because the tool welds points based on the “consolidate seam” value ignoring the geometry borders, which results in a non-manifold geometry - the weld should be done on borders only.
Also, there's no “average” option for welding the points, the implicit rule seems to be “least/greatest point number” - we need an “average” option too, set as default.
And there should also be a “bridge” option, in case the user wants to preserve the position of the border points and have a polygon bridge between the two halves.
The current one produces bad results because the tool welds points based on the “consolidate seam” value ignoring the geometry borders, which results in a non-manifold geometry - the weld should be done on borders only.
Also, there's no “average” option for welding the points, the implicit rule seems to be “least/greatest point number” - we need an “average” option too, set as default.
And there should also be a “bridge” option, in case the user wants to preserve the position of the border points and have a polygon bridge between the two halves.
Edited by anon_user_89151269 - Dec. 8, 2017 05:15:41
-
- Quick Links