what if ... viewport navigation was taken care of for you ? maxscript idea
grand marshal polycounter
Hey all,
So today I decided it would be a good idea to spend a week or so just streamlining my modeling workflow. Basically creating new shortcuts I never took the time to setup.
It got me thinking, we really spend a lot of time controlling viewports. 'Frame selection' is crucial (and is especially good in mudbox for instance, as it frames not only on selection, but also at the cursor location if nothing is selected).
So what if we could reduce the time spent rotating the cam?
What about a small script that simply fetches the normal orientation of whatever is selected (an average in the case of multiple components selected at once...), and orients the camera perpendicular to it after performing a regular frame? Maybe there could be a little bit of zooming out too, to get a clear view of the area to edit. If a 'shell-like' object is selected, it could work too.
This would let us 'jump' from one side of a mesh to another very quickly, and most importantly, would reduce ALOT of mouse/stylus travel, to the benefit of wrist health and! giving us more time to actually edit geometry.
What do you guys think?
I remember the nurbs modeler called Amapi had the keyboard arrow keys set to viewport rotate. It's a similar idea.
It would be awesome if tech artists could see if this is possible!
I feel like it is a very simple chain of events, most likelyvery doable in maxscript, mel, and so on...
So today I decided it would be a good idea to spend a week or so just streamlining my modeling workflow. Basically creating new shortcuts I never took the time to setup.
It got me thinking, we really spend a lot of time controlling viewports. 'Frame selection' is crucial (and is especially good in mudbox for instance, as it frames not only on selection, but also at the cursor location if nothing is selected).
So what if we could reduce the time spent rotating the cam?
What about a small script that simply fetches the normal orientation of whatever is selected (an average in the case of multiple components selected at once...), and orients the camera perpendicular to it after performing a regular frame? Maybe there could be a little bit of zooming out too, to get a clear view of the area to edit. If a 'shell-like' object is selected, it could work too.
This would let us 'jump' from one side of a mesh to another very quickly, and most importantly, would reduce ALOT of mouse/stylus travel, to the benefit of wrist health and! giving us more time to actually edit geometry.
What do you guys think?
I remember the nurbs modeler called Amapi had the keyboard arrow keys set to viewport rotate. It's a similar idea.
It would be awesome if tech artists could see if this is possible!
I feel like it is a very simple chain of events, most likelyvery doable in maxscript, mel, and so on...
Replies
Not saying it would be, just my initial thought. A little bit of ease in/out camera movement might be necessary to eliminate this problem.
Thanks for pointing this out :P
Do you want an action? (MacroScript in 3ds Max) I mean something like a chain of events you can tie to a shortcut or a toolbar button? Or you would like to have something realtime? Like turn it on, it constantly rotates the view according to surface normal under mouse in that moment and turn it off when you're done? (The second one could look really freaky)
Do you want it to snap view to current sub object selection, if not null, and frame it? Or frame the whole object anyway? If sub selection is empty, it would only frame the object but not perform rotations, because averaged normal of a full object could be nonsense, like a sphere which ideally should have averaged normal equal to zero.
Should it work with Editable Poly, Edit Poly Modifier, Editable Mesh, Edit Mesh Modifier, or is there a top priority?
Thank you
Modo does this with the command viewport.fitAlignSelected, I suppose with some selection sets it could be made to work the way you are describing. I've never used this command for this purpose before, you've given me something to think about...
Yep I meant, not something automatic (that would be ... pretty wild heeh), mor elike an action that is triggered whenever the user wants it. Like :
>the user is working on a specific part of a model.
>user needs to jump to another one next
>user Zooms out, select a component part of that new area,
>hits the shortcut or button,
>the camera frames on that new area, aligns itself to the average normals selected, and maybe zooms out a little (i notice that in almost all 3d apps, frame gets too close very often)
The case of whole object is very secondary. But maybe we could detect of the object is likely to be a hull/shell (the averaged normals would differ from zero), and if it fits that condition, the the script could align the view to the average of that shell.
I think that aligning to component selection while framing the object as a whole could cause too much trouble related to having to zoom back in. Maybe .... we could simply keep the camera distance to the object (after the pan and align) the same as it was before the user decided to jump somewhere else. That way it will likely be a comfortable distance for further editing work.
As for priorities ... honestly I would only use it on EditPoly type of objects. Would be cool if it worked from the low level of stack with top midifiers turned either on or off (like, still being able to jump around even if a turbosmooth is applied). But this is less important I guess.
Hope this clarifies things!
This would make sense since in general you only want to be looking at the section of 3d model in the viewport that you're adjusting in the UV window. It would also be handy for quickly "finding" an area of UV that you're not sure what it is.
Not sure how useful it would be for everyday modelling work - it would have to be a "on keypress" thing though since otherwise if you were adding components to a selection, you'd keep getting thrown off. That's why it works better for UV stuff since your UV view doesn't change while the 3d view does.
Basically the idea is a bit like an easy jumpy workbench if the cam is poitionned correctly there is not much need to shift it while working, I think.
An extra would be ... a companion script, that would orient the cam sideways - at a 90 degree angle from the autoalign. To allow for easy shift-extrudes.
Ideas!!
http://www.neilblevins.com/soulburnscripts/soulburnscripts.htm
'alignViewportToFace' is quite close, but I didnt manage to make it work with the current view (it either creates an new cam altogether or, switches to user/orthographic mode)
It also zooms out alot, like a frame object, and I can tell it's already a bit annoying :P
EDIT: Link removed, get latest version down in the thread.
It seems to work great so far. Only feedback I can think of after using it a little is that it tends to zoom a bit too close for my taste. If you could make it somehow remember the last 'work distance' defined by the user and retain that working distance after the camera jump, it would make for a very smooth experience.
It already feels like a very interesting workflow!
I'd like to make this work even without an active sub selection. Something like, wherever the mouse is, over current object, cast a ray and get the relative normal from surface in that exact point and align the camera. But I need to figure out how to set a reasonable zoom amount. Still on this.
Get it here. Evaluate and find it under category "IllusionCatalyst Tools"
It's what I'm currently working on, but it seems to be a little tricky, because: Perspective and Orthographic viewports work in a different way, thus a specific logic is needed; Current active viewport is a sort of hidden camera, but its settings are quite messed up, because you can transform it by current selection center (Orbit SubObject), ignoring its hidden camera target, which is the reference object for important information about the camera itself like focalDistance.
Get it here. Evaluate and find it under category "IllusionCatalyst Tools"
Next step, make it work without a sub selection too, on mouse over only. Next step further, 90 degrees shifts to help extrusion (seems quite easy), as requested by Pior.
- Preserve current zoom factor
- Orient viewport to current subObject Selection average normal
- Orient viewport to surface normal, sampled under mouse cursor on active object, if selection is empty
- Ease out (or is it in? well, who cares) movements (what poopinmymouth said). Easily adjustable, see script text.
Get version 0.4 here. Evaluate and find it under category "IllusionCatalyst Tools"
Please report any issue. Any idea for improvements is very welcome. Enjoy.
p.s. Four posts in a row... Do I win anything? º¿º
don't use max anymore, but maybe i'll give this a look see. cool idea.
Just out of curiosity, what software has replaced Max in your daily practice?
Will sure give the newest ones a try asap and will let you know how it goes. It made me think of a few new ideas ...
Any new idea is very welcome. I'd like to add this instrument to upcoming IC.shape 2.0. You'll be in the credits, of course.
I noticed something, it tends to look to the wrong side when used with mirrored objects.
Also, for me the ease out delay is a bit too long and it's irritating that it can't be interrupted at any point.
A free rotation mode on one axis would be nice too,similar to Modo, where you can "throw" the view in one direction and it keeps spinning around the point of interest.
One more time, awesome script !
Cheers !
Anyway I can make the shift to stop and jump to result by pressing ESC, or by triggering the spin command a second time during animation.
About the continuous spinning, could be an idea for another script!
It throws me a bit when I come to shift the camera when I've been working on something across the other side of the model, and the camera pivot is totally skewed!
Cheers mate, great little tool.
*Edit* this only seems to happen on occasion - possible bug?
I'm not sure to understand the issue either (sorry again). What do you mean by "camera pivot totally skewed"? Could you please post images or a sample model in order to try to reproduce the issue? Rest assured there could be bugs. Thank you!
Managed to replicate this at home however; so hopefully I can stop typing gibberish!
OK.
So, what I have noticed is that when you frame a polygon using your tool, the camera will not pivot around the selection, as with say, zoom-extents. At least, not always.
I would like it to function like zoom extents in that the camera will be 'centred' to the selection. For instance, I have found your script great when doing blending, because I can orientate to an edge quickly, rather than having to maneuver the camera around. However when I come to rotate the camera to see my handy work; the camera is still rotating around another poly or selection (sometimes just a place in space) - which throws me off.
I have knocked up a quick test to show you what I mean.
Hope you understand
The camera never really pivots around a point because it performs a translation between two positions and a rotation around itself. The only case where it gives the effect of orbiting around a fixed point in space is when, after framing a selection, the viewport is rotated in the standard way with Orbit SubObject mode active, then framed again. All this to say I cannot define a center of rotation for the camera, because the zoom factor has to be preserved and the viewport pivot has to be moved away or toward the selection accordingly.
If I understand your picture well, the green X is where the viewport camera seems to be after performing the alignment with the two opposite faces selected. If I got it right, there's an explanation, and I cannot call it a real bug, but a program limitation.
You selected two polygons that have normals facing "perfectly" opposite directions, like those of opposite faces in a Box. So the script tries to get the average normal from two opposite normals, which is [0,0,0], or a null vector. But because of rounding errors in every math calculation on computers, the resulting vector turns out to be very very small. Once it is normalized, or scaled to the unit vector, the outcome is that it is like one of the two starting normals, which one is absolutely random in my opinion.
I guess this special case can be handled to lead to more consistent results. The question is, how do you want the camera oriented after performing a frame action in such conditions? I guess it should be in the middle of selection looking at the object from one side, leaving the selected faces to right and left viewport extremities. Does it make sense? Have I got it right? Thanks!
@ Martin: You're right, it doesn't zoom on selected subobjects anymore, it preserve current zoom factor, whatever it is. I'm not sure about the zoom because you'd end up adjusting it anyway, I mean sometimes it zooms too in, sometimes too out. I think I can make all this as optional.
Your explanation makes sense, however I think (due to my lack of explanation probably again) that you misunderstand slightly.
I do not select both faces, merely one after another.
So lets take a realy small snippet of my workflow currently:
* I zoom extents to the building I am working on and isolate it - by rotating the camera I view all round the object.
* I locate a face or faces that I want to work on and select them - I press Z to zoom extents and then press Space to use your script which spins the camera and aligns it.
* I rotate the camera around the selected faces (alt + MM) to view my handy work
* I then select another face and do the same - however this time when I press Space it will not zoom correctly or when I attempt to rotate the camera around my selection it is like I am orbiting a point far away, rather than the selection.
To summerize: I would like to eliminate the Z key, and have your script frame the selection and be able to orbit around the selection once I am done adjusting.
Sorry for the simplicity of the steps, its harder explaining it by text than it is just showing someone. I may make a video if this post fails
what you describe here would be great i would def use as scipt like this, it would be great for scene where you have lots of overlapping uvs, or many small parts.
In terms of this for editing, it would be best to have it with 2 modes. one is just regular frame, and one is frame and align. and maybe a 3rd that is frame, align and fill view. That way you have regular frame (defualt) then frame and align which will leave the zoom the same as the current position, and a thrid for frame align and zoom to full.
The main reason why i think you need the option to leave the zoom intact from the prev position, is that the manipulators may become hard to interact with if its constantly adjusting the zoom, but overall this sounds like a great idea.
also maybe a toggle option instead of just a hotkey.
you toggle on frame and align so when you select faces it auto frame ans aligns to them or to the averaged orientation information. then you could just toggle it off when you want more control. this could be really useful for doing repetative tasks, or even something odd like putting small objects as camera bookmarks.
Behold! Here come my crappy technical-drawing-with-a-tablet abilities
(I swear I'll remove this as soon as is not needed anymore)
@ hijak: Everything you said can be quite easily accomplished by modifying current script. There's to figure out what's the best interface for usability. I don't like the checkboxes very much as they would require some floating dialog (a big no!no!). I'm thinking to something like repeated activation. If you got an active sub object selection first keypress frames it, second one on the exact same selection orbits the camera, third one zooms to extents. Uhm... just mumbling... needs experimenting.
In my opinion (or more like : in my ideal workflow), the user should be able to define the d distance from cam to component currently looked at, by manually adjusting the point of view (through regular cam manipulation). Lets say he ends up with d=10inches.
In my preferred workflow, after 'teleporting' to another component, the distance from cam to comonent should still be 10inches.
We could have an option in the script to have either this, or a regular 'extents' behaviour. Or maybe two different shortcuts.
Hope this helps!
But yes - I believe I want to keep D!
e.g.
The problem to define a "fixed distance" is that it cannot always be obtained by current view, because there are not always references to get it. I mean: how do I measure the distance between camera and surface if camera axis is pointed somewhere into the void? It can be done only if in the exact center of the viewport (along camera axis) there's some geometry.
I can adjust the script for sure: get distance from object in current view if there's something in the center, and use instead the current method if nothing is found. How does it sound? I guess the best is to write some code and test it.
What do you think about the "double action"? (no, revolvers aren't involved) First keypress orients the viewport preserving distance if possible, while a second one zooms ext if selection is present and hasn't been changed from first press? If there's no sub selection, it could zoom ext the whole object on second keypress, but in this case I guess I need a time limit like for double click in Windows, or check if viewport hasn't changed from first action... Sorry for being a bit messy
Sync, I think most users (at least character/prop modellers) use the cam mode where, whatever is selected, actually IS the center of the camera orbit. It's down there in the little icons on the bottom right. A good way to see wether this is enabled or not, is to simply select a single vert. In that mode, no matter how you rotate or pan the viewport, this vert will remain the orbit center of the viewers camera.
Now I didnt test your latest script itrations, but maybe thats what happened to BHJ. Maybe he was expecting that orbit center to be on whatever is selected, but it somehow got shifted somewhere else?
I know for sure that I cannot model without that function (orbit around selected) and it is infuriating when other apps dont have it :P It really makes for efficient modeling!
- Make a box, like length: 50, width: 10, height: 20.
- Select one of the small faces and zoom ext. It is centered in viewport and zoomed in.
- Orbit your camera around that selection, until you see the opposite "small" face. It looks much bigger than the selected one, because it is actually closer to the camera.
- Now, if you select this big looking face and run FrameIt, it gets centered into viewport, but you still see it big, because zoom factor from before the FrameIt action is preserved.
Correct me if I'm wrong, but what has been requested is to see the second selected face as big as was the first selected face right after the zoom ext command. In other words, to have the same zoom factor for each FrameIt action.
I cannot figure out a way to store that zoom factor, because once a new selection is made, the old one is gone, and keeping it into a variable, doesn't sound too smart either, because between two FrameIt actions, many other selections and deselections, as well as viewport changes, could take place.
The best practical solution I see, is to perform some kind of adaptive zoom ext every time the FrameIt is run. I'm going to give it a shot.
I got a question: right now the script redraws only the viewport where rotations occurs, and refreshes only the node involved, leaving those not so pretty trails until final position is matched. To avoid this and have a very clean animation, the full view can be redrawn at each frame, but it's heavier and slower, especially on big scenes. What do you think about this? Are the current trails so annoying to prefer the slower way? Thank you for your support.
At the moment I feel like the distances are fine as they are ; However I might need to try longer delays between FrameIt calls, to see how it behaves in that regard.
One thing tho - the overall behaviour in version 3 was much better than in 4. I think I see why you added the camera 'motion' effect (smooth feel?) but in practice I believe users want FrameIt to be just as fast as regular frame.
It's true that Maya has 'animate camera transitions', and I admit I quite like it ; but in the case of FrameIt it really feels like a hack, and makes me feel like I have to wait for the script to finish to be back in control of my work.
Also I noticed that in version 4, even with the cam transition options set to the fastest (options 1 and 100), it still feels much slower than version 3 and shows viewport artefacts/glitches.
Hope this helps!
Here is the adjusted redraw for version 0.4, with fEase = 1 to make it instantaneous. Version 0.4c.
EDIT: Fixed a minor glitch. Download updated.
I put the script inside the scripts folder in max folder. Am i doing it right?
form the menu MAXScript select "Run Script..." to evaluate it. Then find it in Customize > Customize User Interface... under Category IllusionCatalyst Tools.
You don't need to put it in script folder, the MacroScript is automatically created after first evaluation.
OH WAIT!
it's the IC Tools!!!!
OK OK
i got it now!
im a n00blet
Right now I'm working on a custom zoom ext feature. It will fill the screen up to about 80% (still need to test it, will be adjustable) and will give a decent zoom even on a single vertex selection avoiding to jump over it, almost sinking into surface, as standard zoom ext does. More to come, stay tuned
* Animation can be turned on and off, and its speed and ease adjusted.
* Zoom Extents can be turned on and off, and can be defined the fill viewport ratio.
Be sure to check the documented SETTINGS section at the beginning of the script to adjust variables to fit your needs.
Get IC.FrameIt version 0.5. Run once, or drop the .ms file over 3ds Max, then find IC.FrameIt under category IllusionCatalyst Tools. A "Reset Viewports" script has been added if too much playing in orthographic views screws the viewport FOV.
Please report any issue. Ideas for further development are very welcome. Enjoy!