Hi there,
Just grabbed H15! Yay!
I have a question about the tweak tool.
Just wondering, how do I get it to tweak in screen space? At the moment it seems to be locked in world x,z…
Thanks,
Setting the H15 Tweak tool to screen space...
4743 14 3- peteski
- Member
- 518 posts
- Joined: 12月 2013
- Offline
- anon_user_89151269
- Member
- 1755 posts
- Joined: 3月 2014
- Offline
I thnik one needs to simply set the handle align to ‘View’
Also don't forget to un-toggle the viewport grid, cause it will constrain your movement in XZ plane. That is if you click on a point and move it w/o releasing LMB for the gizmo to appear. If you let it appear, the grid will no longer constrain your movement. Houdini's special with these kind of things.
Also don't forget to un-toggle the viewport grid, cause it will constrain your movement in XZ plane. That is if you click on a point and move it w/o releasing LMB for the gizmo to appear. If you let it appear, the grid will no longer constrain your movement. Houdini's special with these kind of things.
- OneBigTree
- Member
- 380 posts
- Joined: 11月 2010
- Offline
- OneBigTree
- Member
- 380 posts
- Joined: 11月 2010
- Offline
McNistor
I thnik one needs to simply set the handle align to ‘View’
Also don't forget to un-toggle the viewport grid, cause it will constrain your movement in XZ plane. That is if you click on a point and move it w/o releasing LMB for the gizmo to appear. If you let it appear, the grid will no longer constrain your movement. Houdini's special with these kind of things.
I have to turn off the grid to unlock movement? Is that a joke? If I want to lock the movement in another plane I have to edit the construction plane?
The tweak tool is meant to make things easier, not more complicated. This is probably the worst implementation of an axis restriction. Ever. Beats maya.
- Ondrej
- スタッフ
- 1081 posts
- Joined: 7月 2005
- Offline
When moving something in a way that is not inherently constrained (say dragging the origin of a translate handle or holding the LMB on a component and immediately dragging) Houdini needs to constrain that movement somehow. Houdini constrains to the construction plane if it is visible, and to the view plane if it is not.
Dragging the origin of a view aligned translate handle is inherently constrained to the view plane and is independent of the construction plane.
Translate handles allow indirect drags with the middle mouse button when the mouse is not over the handle. By default, the drag is mapped to the handle axis most aligned with the drag direction, but this can be changed to translate in the view plane in the preferences dialog.
So, to drag in view space, you can do any of the following:
- use a view aligned handle
- use the MMB indirect drag with the preference set to Drag in View Plane
- turn off the construction plane and LMB drag components directly
Dragging the origin of a view aligned translate handle is inherently constrained to the view plane and is independent of the construction plane.
Translate handles allow indirect drags with the middle mouse button when the mouse is not over the handle. By default, the drag is mapped to the handle axis most aligned with the drag direction, but this can be changed to translate in the view plane in the preferences dialog.
So, to drag in view space, you can do any of the following:
- use a view aligned handle
- use the MMB indirect drag with the preference set to Drag in View Plane
- turn off the construction plane and LMB drag components directly
- kahuna031
- Member
- 897 posts
- Joined: 7月 2018
- Offline
OneBigTrees point stands though, it's quite bad. We need a well tested system for all viewport actions, including animations. Handles, orientations, shortcuts and menus need a redesign.
But we should start with just having a simple screen space transform intuitively accesible. Construction plane is a special case.
But we should start with just having a simple screen space transform intuitively accesible. Construction plane is a special case.
B.Henriksson, DICE
- anon_user_89151269
- Member
- 1755 posts
- Joined: 3月 2014
- Offline
Yeah… welcome to the club kahuna031.
I've been saying this for quite some time now. Not sure about the degree I'm believed on this, certainly some users agreed while others were less accepting, but what I am sure about is that in time, as more and more users will come, most will confirm what I've been saying all along.
Of course Houdini doesn't have to be exactly like other 3d apps, but I'd argue that it shouldn't differentiate by how badly organized it is. And of course defining“ organized” is kinda hard, but I think one can draw a definition by which one can measure it against and that would be: things that are not directly related clustered together under the same menu/category is the opposite of good organization.
Context menu and general preferences are in a dire need of a re-structure. For people that are using Houdini for many yrs this is not obvious. For me, a new comer from a notoriously intuitive and well organized 3d app, this issue is staring me in the face with every second I spend in Houdini.
See attached a RMB menu on a transform tool. There's nothing else there, other that what's trictly related to the move tool. Other things, are in other menus, sensitive to the context they're accessed in.
I can go on with examples for quite some time, but I guess I'll save it for when the next development cycle begins.
I've been saying this for quite some time now. Not sure about the degree I'm believed on this, certainly some users agreed while others were less accepting, but what I am sure about is that in time, as more and more users will come, most will confirm what I've been saying all along.
Of course Houdini doesn't have to be exactly like other 3d apps, but I'd argue that it shouldn't differentiate by how badly organized it is. And of course defining“ organized” is kinda hard, but I think one can draw a definition by which one can measure it against and that would be: things that are not directly related clustered together under the same menu/category is the opposite of good organization.
Context menu and general preferences are in a dire need of a re-structure. For people that are using Houdini for many yrs this is not obvious. For me, a new comer from a notoriously intuitive and well organized 3d app, this issue is staring me in the face with every second I spend in Houdini.
See attached a RMB menu on a transform tool. There's nothing else there, other that what's trictly related to the move tool. Other things, are in other menus, sensitive to the context they're accessed in.
I can go on with examples for quite some time, but I guess I'll save it for when the next development cycle begins.
- kahuna031
- Member
- 897 posts
- Joined: 7月 2018
- Offline
Exactly this. People have also been vocal on this during the Beta phase.
I got a quite similar discussion on our inhouse game engine's GUI where I make the point: “We've been here for a decade now, another bug ticket isn't going to fix it. It's the process. It's engineers making art tools that is the issue.”
I feel this looks like a similar situation. Somewhere SESI needs to get material on this. Maybe do some speed modeling comparisons against other apps or invite experienced 3d artist for honest opinions.
H15 got great features and work put into it but the viewport GUI is a bottleneck for all sorts of artistic tweaking. At least we need recognition that this is the case.
I got a quite similar discussion on our inhouse game engine's GUI where I make the point: “We've been here for a decade now, another bug ticket isn't going to fix it. It's the process. It's engineers making art tools that is the issue.”
I feel this looks like a similar situation. Somewhere SESI needs to get material on this. Maybe do some speed modeling comparisons against other apps or invite experienced 3d artist for honest opinions.
H15 got great features and work put into it but the viewport GUI is a bottleneck for all sorts of artistic tweaking. At least we need recognition that this is the case.
B.Henriksson, DICE
- SreckoM
- Member
- 379 posts
- Joined: 12月 2006
- Offline
Of course that is recognized, but you all need to realize that Houdini was never really viewport oriented app. 95% of stuff in Houdini was done through Network view, totally different concept tan any other app out there. It is changing but slowly. We all realize what are you talking, I am sure devs also, but resources are limited I guess.
And in McNistor case if he invested half time into adapting to Houdini way of doing things and not into making Houdini XSI and letting us know every single difference he encountered
And in McNistor case if he invested half time into adapting to Houdini way of doing things and not into making Houdini XSI and letting us know every single difference he encountered
- anon_user_89151269
- Member
- 1755 posts
- Joined: 3月 2014
- Offline
- kahuna031
- Member
- 897 posts
- Joined: 7月 2018
- Offline
- OneBigTree
- Member
- 380 posts
- Joined: 11月 2010
- Offline
Ondrej
When moving something in a way that is not inherently constrained (say dragging the origin of a translate handle or holding the LMB on a component and immediately dragging) Houdini needs to constrain that movement somehow. Houdini constrains to the construction plane if it is visible, and to the view plane if it is not.
Dragging the origin of a view aligned translate handle is inherently constrained to the view plane and is independent of the construction plane.
Translate handles allow indirect drags with the middle mouse button when the mouse is not over the handle. By default, the drag is mapped to the handle axis most aligned with the drag direction, but this can be changed to translate in the view plane in the preferences dialog.
So, to drag in view space, you can do any of the following:
- use a view aligned handle
- use the MMB indirect drag with the preference set to Drag in View Plane
- turn off the construction plane and LMB drag components directly
See that is exactly the problem. There are tons of good reasons for doing that from the developers view. But you guys really have to start to learn how to see your software from the outside! Because that is what the users do. New users almost always have some experience with other software where tweak tools exist for a long time. From their point of view it is absolutely not in anyway explicable why they have to turn off a visual aid to move points in space freely. And there is none.
The sole problem in this case is the concept of the CP! Where in other applications the perspective grid belongs to the same system as the ortho grids and CPs can be activated and deactivated whenever you like, in houdini the CP is the perspective grid and any functions connected to it are never independent of the most important visual aid in the viewport.
So let's say the CP would be independent of the Perspective grid you could do the following:
Adjust the Viewport grids for all view in one go, ortho and perspective alike. For now you have to edit two properties only to have matching grids.
You could set the CP's default off and thus having the tweak tool by default in viewspace as people are used to use it.
You could define multiple CPs and quickly switch between them.
You could turn the CP off without loosing an important aid for user orientation in the scene.
And again: Nothing of this is new. It all exists somewhere and has been proven to be useful. The same goes for highlighting edges. All the concepts are there already.
This is not about “I want houdini to be like Maya or Max”. This is purely about efficiency and it is hard to invent something more efficient than something that has evolved over 20 years.
Houdini has to catch up in the field of direct user interaction, we all know that. It would be the easiest to use the principles the are there already and adapt them for houdini.
I for example am willing to adapt very much. For all the tools I use I always have configured my hotkeys for navigation to match as closely as possible to be able to switch quickly between apps. For houdini I didn't do that. For the first time. So, again, this is not users not willing to adapt. My goal is to have Houdini one day as my single 3d Software. That only makes sense if I can get freelance jobs for houdini. Sadly, barely someone here uses it. Making houdini more accessible and accepted is the goal. The more of houdinis behaviors people are familiar with when they start using it the better. I am really talking about interaction (viewport being a part of that). Viewport navigation, Display options basic transform tools and so on should never ever raise the need for looking them up in the manual nor should they require a tutorial. That is what its all about. When you have people having to think about those things constantly, they barely find the motivation to go deeper. And when you go deeper it can be all houdini.
- Werner Ziemerink
- Member
- 1267 posts
- Joined: 3月 2014
- Offline
I switched off the Ortho grid and saved that as default.
I very much dislike the Ortho grid constrains, so now it starts up with Ortho grid off and a normal grid active(xy ground plane in Display options under guide tab).
Also, I've changed the Translate handle to ‘Drag in View Plane’ under Houdini Preferences/handles. This allows me to translate in screen space indirectly without having the mouse pointer anywhere near the object…huge time saver when modeling.
I very much dislike the Ortho grid constrains, so now it starts up with Ortho grid off and a normal grid active(xy ground plane in Display options under guide tab).
Also, I've changed the Translate handle to ‘Drag in View Plane’ under Houdini Preferences/handles. This allows me to translate in screen space indirectly without having the mouse pointer anywhere near the object…huge time saver when modeling.
- SreckoM
- Member
- 379 posts
- Joined: 12月 2006
- Offline
- peteski
- Member
- 518 posts
- Joined: 12月 2013
- Offline
-
- Quick Links