Put it in category you see best. There is a difference between mouse-based and stylus-based navigation. I still think “Doesn’t Pix have better things to do” is funnier though . . . :lol:
-T
i have played/worked with a lot of tools and to be honest, i really like the standard zb3 navigation. if you know how it works, its incredible fast and good.
Kerwin, I’d be interested to know how you would define the difference between the needs of stylus based navigation vs mouse based, and how the one has advantages over the other in the context of a Zbrush-like program. Nothing pops to my mind that would call for a different nav system depending on whether you use mouse or stylus. If you can present a more well-defined idea of what you mean I’d be happy to make a new category to reflect it. Meanwhile I’ll put your vote in the category I’ve already mentioned.
n-drew, would you mind sharing with the rest of us exactly why you find the current Zbrush nav system fast and effective?
Re : the stylus issue. one point i would make is concerning the differences between different brands and different models of tablet ( specifically the wacom intuos Vs graphire ) and how the button designs of each can greatly impact the effectiveness of their use in such a busy affair as navigation
the intuos has the single button ’ rocker ’ which is quite soft / responsive and offers good access to both middle and right clicks
the graphire is almost the opposite. buttons are small. fiddly. and require a great deal more pressure to connect a click
the former is really comfortable and pretty near an ideal solution. the latter takes a lot more getting used to. so the plot thickens when we’re discussing navigation since we even have to consider the involvement of / relationship with another design system and its flaws and virtues
of course that last statement is only half true at best when we consider more flexible options and the ability to customize the navigation scheme to suit ourselves. this to me should really be the main point here. whether user x or y has different preferences should not mean that one or the other is left without
.
as far as zb’s nav scheme is now. one other option i would like to see introduced is the ability to customize the gutter of null space that surrounds the canvas. most of my work generally happens in the center of the canvas and i could bring that gutter in a lot more than it currently is to allow the navigation to behave as when the model is scaled out. working on general forms. at that early stage of sculpting i don’t find zb’s nav to be a problem. only when getting into finer details and filling the canvas with a mesh does it really hurt my workflow
True, bringing in the question of hardware design in the user interface does complicate things a bit, but I think that by and large the issues are the same for most users, no matter what there hardware, particularly when considering Zbrush which I’m sure would be almost universally accessed via a stylus.
You Said:
“as far as zb’s nav scheme is now. one other option i would like to see introduced is the ability to customize the gutter of null space that surrounds the canvas. most of my work generally happens in the center of the canvas and i could bring that gutter in a lot more than it currently is to allow the navigation to behave as when the model is scaled out. working on general forms.”
I’m not that familiar with the “null” and “gutter” terminology but I think I know what you’re talking about. In relation to it - one workflow capacity I really miss from other apps is the ability to quickly select a few points, edges or faces and focus the camera on those selections, rather than zoom pan, zoom-pan etc into where you want to work. True, you can mask and then focus, but that’s still a mediocre compromise in my opinion, the compromise being that you lose acces to areas on the periphery of your selection. This is a bit of an aside to the navigation question, it doesn’t exactly address the specific point of this thread but I think there still is merit in bringing it up in this context. Perhaps it would be worth keeping this kind of thing in mind when developing a nav system, there might be a way to integrate it in an optimized way. A reasonable compromise for zbrush might be to create a tool similar to the Zoom Tool found in Photoshop, where you simple create a rectangular selection around the region you want to focus on using the Zoom Tool and voila you’re there.
Well, despite the irrelevancy of my Piano/Violin analogy, I’ll continue it slightly. Using a Stylus is like bowing a violin in that we tend to push down and draw the mouse in a direction–we don’t have a lot of buttons and and an alternate stroke is to flip the stylus over like a pencil eraser.
Using a mouse is more like key ing a piano–they’re lots of convienient buttons but (on my mouse there are six!), maybe even a wheel. There also isn’t a notion of pressure with a mouse.
Another very important differnece (like pianos versus violins) is a stylus can’t “chord” easily, unlike a mouse. So “press-two-buttons-at-once” moves are right-out.
Yes, modern stylus’s have a rocker switch, but ergonomically only the down click is easy–pulling the index finger up and down is actually a harder move for the human anatomy.
So, a stylus is a 1 button device with a “flip to use the eraser” move and a weak second button (an up click.) It does have pressure, but learning pressure moves requires even more subtle than the “drag-and-let-up-the-option-key” you decry in your essay. For a stylus user that move is actually useful, since we don’t have easy other buttons to go to.
So, if I was proposing a Stylus-based navigation, I would probably assign multiple keyboard keys for the orbit, pan, zoom movers, rather than burden the stylus’s lonely switch. (This is sort of the oppoisite of Maya-type which uses as single modifier and the mouse buttons.)’ Maybe something like:
- hotkey 1 + drag == orbit
- hotkey 2 + drag == pan
- hotkey 3 + drag == zoom
- flip (e.g. eraser end) == inverse brush
- hotkey x == std brush
- hotkey y == inflate brush
- hotkey z == flatten brush
- etc. (for brush switches.)
Cheers!
-K
When you’re in tool-edit mode, the area outside the white box (or the empty area surrounding the canvas) is the gutter. Despite showing imagery, it is always “outside” the model so you can rotate/zoom/pan. Another difference I forgot to mention is that tablets are usually used as “absolute devices” (e.g. the same point on the tablet corresponds to the same point on the screen) while mice are “relative devices” (e.g. you move from here to get to there.)
For a tablet user, the gutter is more or less always in the same place, which means jumping-to-the-gutter to navigate is a quicly learned muscle memory move and jumping-back-to-the-model-spot and equally easy move. Because of this, tablet users don’t have as much problem with “loosing focus” by going to the gutter to navigate and jumping right back to their model–it’s almost as easy as working on a piece of paper.
The mouse user on the other hand has to roll themselves over to the gutter and because of the vaguries of mouse interpolation and automatic mouse acceleration, this can be a more subtle, trickier move, requireing you to watch carfully with your eye where the mouse pointer goes. Same for jumping back to the model. It’s annoying at best.
Anyhow, the couple examples above are what I’m getting at about the difference between mouse and stylus systems of navigation. Like playing a piano versus playing a violin, you really got to do both a bit to not only appreciate that they make music, but the subtle of the tones, the envelope of the sound, and ultimately the difference of technique to use them properly.
-K
Kerwin - huh, ok - I didn’t think that using the stylus buttons was an issue for many people. Personally I don’t have a problem with it. I use a graphire at home with Zbrush and XSI, and a Cintique at work with Maya and Body paint, and I have no problems with navigation in any of these programs via a stylus. Personally I find using the buttons is far easier than the “drag-and-let-up-the-option-key” method. I guess it probably comes down a lot to what one is familiar with. I certainly have had to go through a learning curve in learning to use a stylus, but am now pretty cumfy with it. I guess this emphasizes the need to have several options available. It’s interesting that you mention having 3 keyboard toggles for navigating via stylus rather than the 3 mouse buttons. I had the same idea earlier this morning as I was thinking about different methods that might be better suited for a stylus.
Personally I think I’d rather keep the inverse of a brush to a hotkey rather than make it the “eraser” of the stylus, but there’s no reason you couldn’t have it both ways simultaneously.
Totally agree about the hotkeys for the brushes. Actually I have a plugin someone made that assigns hotkeys for most of the brushes using the number keys. I find that handy. Although ideally I’d like to have the numbers assigned to different Zstrengths in the same way that they are assigned to different oppacities in Photoshop, Ie: 1= %10 opacity; 2=%20 opacity …; 0=%100 opacity, and any quick succesion of numbers would equal what you type. Eg: 1+2 = %12 opacity; 4+5 = %45 opacity.
Sometime today I’ll make up a new category for the type of stylus-centric navigation you’ve outlined, and add your vote for it.
Whaat? If this means what I think it does then that changes things a bit. This is news to me. Now I feal stupid. By “the white box” I assume you mean the box outline that appears in the viewport once you enter edit mode? I’ll have to try this when I get home. That would make a big difference.
I’ve wondered what that outline was there for so many times …
If you have “gutter” betweem the edge of the canvas and the panel areas (top, bottom, left, right) that’s also a “navigation spot” which means sometimes the white box gets clipped because you have enough gutter outside the canvas. I agree with you it’s no big thing to use the rocker switch, but after a long day (8 hours +) rocking back up, versus stetching my index finger is little less ergonomic. (I’m old.) Ideally, I’d prefer no stylus button nav at all, altering stylus behavior would done 100% with the keyboard (though I was quite attached to a button, joystick & dial box I had on a CAD system back in the 1980’s that I operated with my left hand while I worked the stylus in my right.)
P.S. The manual calls the area outside the thin white lines “the safe area” and says in part: “To rotate your model press and hold the left mouse button and click and drag outside of the model. If the model fills the entire canvas you can use the safe area designated by the white thin lines.” Don’t feel bad if you missed it. I don’t think I realized i was there until months after it was implemented.
P.P.S When zooming in real close so it fills the screen (what I sometimes call “Hyperzooming”) try switching on “local rotation” (5th button down on the button bar to the right of the canvas). I think you’ll be pleasently suprised how well that works with the safe area/gutter.
-K
Sorry it’s taken me so long to respond Kerwin. So, I went home and tried out the safe-area gutter. Very cool, that really makes a big difference. I also gave the scale nav another chance, spent some time practicing it and am now much more comfortable with it; but I would still prefer something different. The fact that the scale function begins by essentially activating the move function naturally results in little unwanted jumps. Perhaps with practice this goes away, but it still seems like a bit of a sloppy setup.
Overall though I am much happier with the zbrush nav scheme and I think I understand now why it was chosen.
Having said that, I do still think it would be best for several options to be available to the artist, both for the artists sake and for pixologic as keeping your product attractive to your user base makes good business sense.
Thanks for your input and tips Kerwin.
I think a seperate button for scale/zoom rather than alt-then-release would be better myself. My Wacom tablet has not one but two “scroll areas” (think of them as pen equivalent to a wheel on a mouse) that I’d much prefer for zoom. Glad the safe-zone helps, I can’t imagining navigating without it. 
I have to admit, even with all my practice, that a little “jump” at the start of a zoom move seems inevitable. We’ll have to see what pixologic has for us in the way of interface tuning down the pike–it looks like they’ve put some hooks into the ZB3 interface to do it.
-K
Francis. you brought up the question of whether some kind of ’ frame area ’ or similar function were relevant in this conversation. which i think it most definitely is. it’s certainly one aspect of viewport navigation that is missed coming from nearly any other app
given a little thought the setup i would give myself if the options were there to support it is :
>
silo style hybrid navigation ( maya nav ( alt key ) with zb_esque ’ click in null space to rotate ’ ). i’d simply shift the masking functionality over to the space bar where i never use its currently mapped ’ hotbox ’ ( which would still be accessible by right click anyway )
>
photoshop / illustrator et al style zoom / frame area
.
getting even more in depth i’d favour the option to have the view snap to orthographic mode when using the snapping to front. side etc shift key method ( which has always been awesome and full credit to pixologic for that gem. i’d wishlist that inclusion in other 3d apps ). going so far as to check each view individually eg. snap side view to ortho. snap front to perspective
hell. i might even play with it further and set up in parallel some kind of uber context sensitive scheme where :
cursor in null space > left. middle and right clicks rotate. translate and scale respectively
cursor over model > left. middle and right clicks Zadd. Zsub and smooth
.
sketch away
Just get ZB to support 3D Connexions Space Navigator, hotkey problems over… 
Buckie, is that thing precise enough to be practical? I´m thinking seriously on buying one.
Can you share with us the good and the bad about using it.
Thanks!
Sorry, after doing a quick research I realized that 6dof perifericals are still not supported in Zbrush, so my last post has no place…
Anyway, I´m still considering one to work with Maya and my other 3d apps. Sounds very interesting to have the same working worlflow with one of these things…
Hi all,
Let´s get to the bottom line, there are far too many bugs, chrashes and interface oddities in the new versions of ZBrush.
The fact is that they have been a standard in the industry for years, and now Pixologic is tryng to reinvent the wheel.
No serious industry should release a software with so many bugs and instability that one of the most common subjects in the forums are WORKAROUNDS to workflows that are supposed to be default.
It is incredible that some major improvements in ZBrush are made by its users, and hundreds of plugins are necessary to do the most essential things, as assigning keystrokes 1 to 6 to change brushes.
I could list dozens of incomparable great points that made ZBrush my modeling and texturing software, but I also have other dozens of crashes, buggs, disappointments and annoying issues working with ZBrush.
The zoom keyboard combination, using the bizarre UNPRESS ALT AND DRAG, as well as inverted commands in masking and hiding (ctrl shift canvas click unhides polys but ctrl click inverts masking - similar dragging or clicking responses to both could make modeling way much easier).
Why not going standard (ctrl spacebar or alt spacebar) to such a basic usage? Pixologic engineers should consider that ZB is not a software to be used without others like Photoshop and Maya, and assigning awkward keyboard combinations is a hassle when swapping from one software to another.
Modo is a very serious option, and even not having excellent tools like Zapp Link or Subdiv levels, it brings in a user interface that is, to say the least, intelligent, friendly, logical and extremely functional.
How come ZBrush engineers create a red background with orange lettering to rename a subtool?
Why do they release a version that is not capable of doing things they showed on a video tesser 3 years before, like SURFACE RIGGING?
Why does reconstruct subdiv works fine on version 2 and not on 3 and 3.1?
Why does edge loop bugs so bad in 3 and 3.1, and not on ZB2?
Why not having extrude faces?
If event Blender and Silo have it for years, why can´t ZBrush have edge and face editing, only vertex editing?
I could go on and on, but this is pointless, because Pixologic does not care about their users, they are more concerned on having a “sleek interface” than a rock solid piece of software.
I´m seriously considering a change to Mudbox and Modo, and forgetting about WORKAROUNDS, and user made plugins to get the job done.
Bye all,
Montalvo
Well Montalvo, I appreciate your comments and concerns; I share some of them (I too have a bit of a love\hate relationship with ZB), but I must point out that the purpose of this thread, while inherantly involving some form of criticism, is primarly about exploring improvements. So, perhaps you could contribute to the topic by describing the nav system that Modo uses, and explaining why you prefer it.
@ Inverse Catheter:
I don’t know if you are getting notices of these new posts - but I should have mentioned long ago that I thought those were some really good ideas you posted last.
Something to point out: I like the context sensitive idea you had, but I personally prefer to have a toggle key to trigger the nav functions, because otherwise you are illiminating the possibility of non-nav LMB, MMB, RMB functions … actually that’s not true - you could just assign a key trigger to those other functions, but I do still wonder which I would prefer - needing to use a “gutter” region for nav when close up to the model - or being able to nav with your cursor right over the model (not needing to move it), which would require a trigger key. Who knows.