NVil Forum
General Category => NVILL Discussion => Topic started by: Vaquero on September 16, 2012, 11:56:29 pm
-
Hi there!
Originally I wanted to make a list of all the things I like about NVIL and all the stuff I'd rather have another way. But I couldn't manage to get started on the writing so I decided to make a topic where I can put all those things, once they come to mind.
You are more than welcome to comment and join the conversation. A plus (+) means I like it and a minus (-) means I don't.
So in no particular order I will begin:
+ customizable window layout
+ "slide in"-windows
+ radial menus
+ tool search, SmartTips
+ when the central position of my selection is outside the view, the manipulator moves somewhere I can see it! NEAT!
+ snap to orthographic views via shift when rotating the camera
+ using mousewheel to alter the number of inbetweens when extruding/beveling etc.
+ round bevel/chamfer (MMB)
+ Objects keep rotation. The lack of that was a big disappointment in Silo for me, because it made non-organic modelling hard. I need the possibility to "zero things out". In NVIL this is done real quick by RMB/MMB on any axis (the letter) in the manipulation/object list window.
+ numeric inuput for move works with (some) arithmetic expressions
- multiplication doesn't work
- division and multiplication don't work with rotation and scale/size
- addition/substraction don't work with rotation
+ visualizing snap handle
There sure is much more about this software that I like, but I can't remember right now. I also barely scratched the surface. And a lot of things I didn't mention are a no-brainer to me (soft-selection, symmetry etc.). But as my new notebook is up and running and don't have to live in agonizing pain and fear of the next bluescreen anymore, I'm ready to put NVIL to some practical uses and get to know the pros and cons.
-
+ the possobility to shade backfaces in a different way. This makes it possible to instantly see flipped faces. In some other applications you can't tell if it's a backface or a hole at first glance.
+ Did I mention the huge set of functionality?!
- With great functionality comes great responsibility. ^^ Seriously: the disadvantage of this is that it's hard to overview the software. It feels a bit cluttered, overwhelming, often redundant.
I know there are other topics that deal with similar issues. I feel the same, that is: there are things that need trimming, streamlining and polishing.
I already find NVIL better than Silo (functionality-wise) and I spent something like 90 €uros for that many years ago. It would be a shame if too complex and sometimes confusing functionality would turn people away and keep them from throwing money at their screens when the time is right. All the hard work and implementation of user wishes should be rewarded someday, right?
Now here's my point: It is still time for big changes. Let's be honest: the user base doesn't seem to be that huge yet. There are 134 forum members, a few of them posting. I can remember someone on the forum didn't wish for a particular change, because he and maybe others would have already set up their version. I feel more like we are all beta-testers and change is part of the process. At some point you probably need to redo your settings. You've got to break some eggs if you want to make an omelet.
But now to the task. Let's start simple and look at how you are able to manipulate stuff by typing in numbers.
There's the manipulation window, the manipulation input, and the object list in the scene explorer. That's redundant and I would suggest trimming it down. I would either put it all into one window or a maximum of 2 windows where one contains tranformation and pivot tools and the other the stepping-settings and direct input fields. For my personal taste I wouldn't recommend taking direct input and stepping settings apart.
The direct input fields that feel the best for me personally are the ones in the object list inside the scene explorer. You have the following: Position, Orientation, Scale and Size. I like the distinction between scale and size. Scale is a relative value, size an absolute. Note that in the manipulation window and manipulation input window scale is mistaken for size! I also like to be able to click&drag on one of the axis letters to manipulate it and RMB/MMB click it to set it to 0. And what's more about this part of the view: No Offset-fields! That's right. You wouldn't need them, if you'd be able to use arithmetic expressions (+ - / *) in all of the input fields.
To sum it up what I think: The manipulation input window should be replaced entirely ( I know, I know, it's not that old and I supported it, before I knew about the object list). The Input fields should be removed from the manipulation window and the stepping-settings should be moved to the 'new' manipulation input window. The input fields of the object list should be moved to the same manipulation input window with all it's existing functionality plus the ability to use arithmetic expressions. Now you've got all your inputs in one and only one place. One addition: I think the "local move" checkbox beneath the position fields should have an effect on the input. The input should switch to 0.00(object space), so I could input 1.0 to move it exactly 1 unit along a local axis. At the moment the steppings (shift/ctrl) don't work when local move is active and you click&drag on the axis letter.
I hope my suggestions with the subsequent discussions will help improve the usability for everyone, especially people that are new to this fine piece of software. I think the developer (IStonia) has made quite an impressive job so far and is on the home stretch. Of course, I didn't even get started on the streamline tools, that also seem to need some polishing. ;)
-
I´m a bit pessimistic at your topic. I totally agree that a cleanup is more than necessary. Functionality is just half of the show. UI is even more important. But we most probably won`t see big changings at the UI anymore.
I can even undestand why. Some changings would simply make too much work. Some changings are a thing of personal preference and taste, and so not really necessary. And some changings would break the current UI concept. Which is made to please professionals with an addiction to hotkeys at the speed end. Not really the masses. (I see a small market problem here. Pros buys big boys like Max, Maya, Cinema ...)
One last important point: Nvil is already highly customizable. One of the things i love at Nvil. But that`s a two sided sword because Users wants to use a software, not build their software first. And with customizations we have the problem that folks cannot longer talk with each other when the tools are at different locations or even have another name. Which easily happens with the self made streamline tools or customized radial menus.
Anyways. I am back at my hot loved dinosaur called trueSpace to do my work. It has much less functionality, and is really limited compared to Nvil. But it`s much easier and faster to use for me. And this not only because i am used to.
I don`t need to remember and use this much hotkeys for the same workflow speed. The tool names makes sense in case i have to dig for a long time unused tool. The UI is clean and uncluttered. I don`t need to dig in sub menus to find my tools. And everything important is in reach and not hidden. Without blocking each other like it would do in Nvil, with its lots of big and space eating panels. I don`t need to customize or even create my tools first to allow a comfortable workflow. And i get my work done. Which can`t be said from NVil in all cases yet. You named the arithmetic expressions for example, which would really be a nice addition. I can`t preview normalmaps to judge the final result, and so on.
I will nevertheless keep an eye at NVil, and keep toying around with it. It`s already a great modeler, featurewise :)
-
Thanks for your reply on the topic.
I see a small market problem here. Pros buys big boys like Max, Maya, Cinema ...
I don't agree on this one. I worked at a professional game studio for 5 years and I didn't need to buy maya, because the compny bought the licences. As I didn't felt much like spending 2000 bucks on a software, I needed something to work with at home. Silo is incredibly streamlined and didn't cost much. But it has its annoying disadvantages (numeric transform input resets, tools behave strangely at higher distances from the center, undo errors... to name a few). But at the time it still had more modelling capabilities (including UVs) than any of the major applications! Maya didn't even have bridge or slide loop, selection highlighting and tweaking, retopo tools etc. You had to install the bonus tools to get the basic stuff. Today some of this is still true. Just last week I saw a plugin on the web that enables Maya 2013 to mimic the behaviour Silo and Nvil have in common. And boy, maya crashed all the time (as did Silo...). If I recall correctly, at a time when we were like 10 artists or less, 3 of us used Silo, and we even HAD access to maya. And some more 'prominent' people of the modelling scene like Glen Southern praised Silo as well.
So concerning the target audience, NVIL should do things better than comparable products like Silo. My guess is, many modellers already have a Silo licence and aren't willing to pay for the same piece of software again. If it costs triple the amount, they won't pay. I'm fairly new to NVIL and I don't know how the project got started, but it's good to have in mind what modellers are complaining about in other software to improve upon that. If there's no 64Bit version, NVIL will only be smiled upon. 'Utilizing modern GPU-Power' is always a good catchphrase. For a SubD modeller, you can count on, that people would want to display millions of faces and still be able to work fluently.
One aspect that got annoying with Silo was the supported file formats. Model in Silo-> export to Obj -> import to maya -> adjust scale in maya :( -> reset texture paths -> save in maya binary format. The OBJ was only good for transfering. I probably wouldn't mind working in FBX format all the time. But I think application links are the way to go! You 'just' need to support all the majors. Second file format concerns textures: a lot of them should be supported. Best case scenario: even PSDs because you probably got your textures in that format anyway. To save memory the programm could temporarily bake the PSD down internally to a lighter format.
Enough mumbling aready. :)
-
+ Hey, I also like the "sticky help window" of the streamline tools that pops up when you activate a tool! Help and tool information really feels like the nuts and bolts in a software with that many, but still similar tools.
-
... And what's more about this part of the view: No Offset-fields! That's right. You wouldn't need them, if you'd be able to use arithmetic expressions (+ - / *) in all of the input fields...
How can I tell -200 is absolute value or offset value without the offset field?
-
By starting with the absolute value for the calculation. In trueSpace i have just the absolute value. I have for example the X value of 12. Now i add in the same edit box a simple /2 behind the 12, hit enter, the calculation starts: 12/2, and the value changes to 6. And my mesh jumps to this new position.
-
I see. But for rotation input it is different. eg. I have (45, 45, 45) rotation and the absolute input (45, 45 + 45, 45) is not the same as offset input (0, 45, 0).
-
But should. What`s the difference?
-
You can try that out. Absolute (45, 45 + 45, 45) is value predictable. Offset (0, 45, 0) is visually predictable.
-
I don`t see a difference. Thus my question. When i type in four times 30 into the offset box then i am at 120. When i add 30 four times to the absolute value, then i am also at 120.
The only difference is that i need to do that in an extra edit box. And that i don`t need to add a mathematical sign like a plus or a minus. But in case of a multiplication it`s already better to be able to calculate instead of working with an offset box.
-
I think I'm beginning to understand what you mean. Or maybe not. In a way it is related to world/object space manipulation. The expressions always worked in Maya, I never had a problem with just one input field. But Maya handles rotation differently than NVIL. Because I can't remember the details I will do some research on the web, maybe ask a few colleagues about that. What I can remember is, that in some space the rotational axes weren't forced to be perpendicular to one another. You could tell Maya in which order the rotation axes should be handled. But to be honest: that was a pain in the ... Perpendicular axes work better for me.
As I said, the "local" checkbox should have an impact on the input fields. Or even better: Forget about the local checkbox, remove it and control it via the manipulation setting as you would normally do. So these two don't work against each other and you always know where to set your space. Translation/Position would turn to 0.0.0 in the input fields when in local, scale would stay the same as it is local already (in some windows it is confused with size), and rotation... well, let me think about that while I play around with it in NVIl. :)
-
The way I see it the absolute values for rotation work with world space axes and the offset works in object space. I can't quite concentrate right now, but when operating in object space, the inputs for the rotation axes should do their magic on the local axes, and when operating in world space they should concern with world orientation axes. Or am I missing something?
-
I'm still trying to understand how things work and what the implication of my suggestions are. I feel the concept of the input fields in Nvil is not quite intuitive, maybe I even found a bug.
Translation/Move/Position: When I am in object space and enter a value on one axis into absolute, it translates/rotates by world axes. But when I click&drag the axis letter in front of absolute, it translates by local object axis? The numeric input should also work on local axes, just like click&drag. Remember, that when changing to object space the input fields should all be set to 0 (at origin/pivot of the object) and everything I enter in this mode would be an offset along the local axis. The world space holds the absolute position of the object.
Rotation/Orientation: This time the behaviour should be the other way around. Object space holds the rotation in relation to world space axes. Nvil already does that, but there's a small bug, that got me confused. The absolute input of the x-axis rotates around the world x axis in object mode! It should defintately rotate around the local axis as do the y and z axes. The click&drag of the x-axis works fine though. Now in world space, rotation always displays as 0.0.0 and everything I enter there is an offset around world axes. The values for all the axes in object space would change accordingly. When I would now enter an expression for rotation into one field while in object space, only this axis would update. Nvil does that already.
In this setting I don't see the need for "Offset Fields" if I would be able to use + - / * in the input fields.
I attached a simple scene to play around with that I used to visualize what is happening when fiddling around with local rotation and move.
-
+ I didn't yet mention that I totally dig the way you are able to use the steppings in every tool I encountered up until now!
-
I don`t see a difference. Thus my question. When i type in four times 30 into the offset box then i am at 120. When i add 30 four times to the absolute value, then i am also at 120.
The only difference is that i need to do that in an extra edit box. And that i don`t need to add a mathematical sign like a plus or a minus. But in case of a multiplication it`s already better to be able to calculate instead of working with an offset box.
1. Create a box at zero.
2. Set the pivot orientation to 'Object', position to 'Selection'.
3. Make sure in 'Object Mode'.
4. Turn on 'Move' manipulator so we can see the axis directions.
5. In 'Manipulation Input' Window, set this to the Rotate-Absolute field, (45, 45, 45) and execute it. Make a screen shot of this pose. Name it 'pose1'.
6. set this to the Rotate-Absolute field, (45, 90, 45) and execute it. Make a screen shot of this pose. Name it as 'pose2'.
7. Undo and the Rotate_Absolute files should be back to (45, 45, 45).
8. set this to the Rotate-Offset field, (0, 45, 0) and execute it. Make a screen shot of this pose. Name it as pose3'
Compare the three poses you should be able to spot the difference.
The visual expolanation, imagine you rotate it by your hand in the real world.
pose 2: From zero orientation, rotate x 45, rotate y 90, rotate z 45.
pose 3: From zero orientation, rotate x 45, rotate y 45, rotate z 45, rotate y 45.
As you can see, if you use the the absolute fields, The application will read the values of the three absolute fields to generate a result space. But if you use the offset fields, the application will only read the input offset value and rotate the manipulator by that amount along the corresponding axis from the current manipulator pose. The same as you just use your mouse to rotate that axis by the offset input amount manually.
-
The only thing about my conception that is bugging me is, that you perhaps always have to switch between object and world space. What if I mostly want to edit the absolute postiion but also the local rotation axis? I think it would be wise to have a window where the local and global values are side by side. Besides position and orientation, I would put Size on the global column and Scale on the local column. The layout would still be the same, just that the offset fields would be replaced by the local values.
-
As I said, the "local" checkbox should have an impact on the input fields. Or even better: Forget about the local checkbox, remove it and control it via the manipulation setting as you would normally do. So these two don't work against each other and you always know where to set your space.
No, I'll still keep it. You can try this
1. Create Two objects.
2. Rotate them sperately so they don't have the same orientation and should be facing different directions.
3. Make sure the two objects are selected.
4. Check the 'Local move' Option.
5. Drag Position x/y/z label to move the two objects. They should move in different directions. You won't be able to to this with the manipulator method.
-
I'm still trying to understand how things work and what the implication of my suggestions are. I feel the concept of the input fields in Nvil is not quite intuitive, maybe I even found a bug.
Translation/Move/Position: When I am in object space and enter a value on one axis into absolute, it translates/rotates by world axes. But when I click&drag the axis letter in front of absolute, it translates by local object axis? The numeric input should also work on local axes, just like click&drag. Remember, that when changing to object space the input fields should all be set to 0 (at origin/pivot of the object) and everything I enter in this mode would be an offset along the local axis. The world space holds the absolute position of the object.
Rotation/Orientation: This time the behaviour should be the other way around. Object space holds the rotation in relation to world space axes. Nvil already does that, but there's a small bug, that got me confused. The absolute input of the x-axis rotates around the world x axis in object mode! It should defintately rotate around the local axis as do the y and z axes. The click&drag of the x-axis works fine though. Now in world space, rotation always displays as 0.0.0 and everything I enter there is an offset around world axes. The values for all the axes in object space would change accordingly. When I would now enter an expression for rotation into one field while in object space, only this axis would update. Nvil does that already.
In this setting I don't see the need for "Offset Fields" if I would be able to use + - / * in the input fields.
I attached a simple scene to play around with that I used to visualize what is happening when fiddling around with local rotation and move.
I think it is quite a simple concept. The offset fields and x/y/z label drag are used to mimic the operations you do with the manipulator in the scene, highlight axis, clik and drag.
-
No, I'll still keep it. You can try this
1. Create Two objects.
2. Rotate them sperately so they don't have the same orientation and should be facing different directions.
3. Make sure the two objects are selected.
4. Check the 'Local move' Option.
5. Drag Position x/y/z label to move the two objects. They should move in different directions. You won't be able to to this with the manipulator method.
So this is a cool trick (thanks for sharing), but there are a few coherence issues with that: I should be able to enter the numeric offset directly (like valueX+1) to move a bunch of objects 1 unit in each local direction. But this trick only works in the object list. When I'm in object mode and try the same thing in the manipulation window, it won't work. All objects get translated along world axis. Why is that if I'm in object space?! That's what I mean by "lack of concept" or unintuitive.
With these offset fields I'm still not able to do multiplication/division.
Your example to demonstrate the differences when rotating are absolutely true, but I don't think that is what he actually meant. Let's say we are again in object space and want to rotate something around a local axis. If I enter ValueX+45 into a field, as a modeller I should know that all the values for all axes get recalculated, because they change their orientation in worldspace. That's due to the fact, that they must remain perpendicular to one another (not in maya as I mentioned).
I think that you really did a fine job, but my opinion is that my suggestions would make the software more coherent and therefor easy to use and understandable.
-
I think that you really did a fine job, but my opinion is that my suggestions would make the software more coherent and therefor easy to use and understandable.
I understand and very appreciate your input and the app has been improved by your good suggestions already. But sometimes it is possible that the app works in a different but better way and you haven't understood yet.
The only thing about my conception that is bugging me is, that you perhaps always have to switch between object and world space. What if I mostly want to edit the absolute postiion but also the local rotation axis? I think it would be wise to have a window where the local and global values are side by side. Besides position and orientation, I would put Size on the global column and Scale on the local column. The layout would still be the same, just that the offset fields would be replaced by the local values.
I don't think it is practical as there are world, object, selection, parent, screen, manual space options here. By the way, 'What if I mostly want to edit the absolute postiion but also the local rotation axis' can be achieved already in the 'Manipulation Input' window with proper pivot orientation/position settings.
So this is a cool trick (thanks for sharing), but there are a few coherence issues with that: I should be able to enter the numeric offset directly (like valueX+1) to move a bunch of objects 1 unit in each local direction. But this trick only works in the object list. When I'm in object mode and try the same thing in the manipulation window, it won't work. All objects get translated along world axis. Why is that if I'm in object space?! That's what I mean by "lack of concept" or unintuitive.
With these offset fields I'm still not able to do multiplication/division.
The input fields in 'Object List' are for individual objects. They are not manipulator related. While the input fields in 'Manipulation Input' window is selection and manipulator related. They work on the whole selection as a group in all modes.
Your example to demonstrate the differences when rotating are absolutely true, but I don't think that is what he actually meant. Let's say we are again in object space and want to rotate something around a local axis. If I enter ValueX+45 into a field, as a modeller I should know that all the values for all axes get recalculated, because they change their orientation in worldspace. That's due to the fact, that they must remain perpendicular to one another (not in maya as I mentioned).
Of course, if you enter ValueX+45 into absolute field, the app will recalculate. But if you enter 45 in offset field, it is not. Imagine you have an object in the scene, you don't care what its current orientation is, you just want to rotate it along its y axis by 33.3 exactly, how can you do it with just absolute input fields?
-
The good news is: Your object transformation already works better than Blender's! I couldn't find a way in Blender to rotate an object around a global axis by numeric input. It always uses the local axes. It seems you can only rotate around global axes via visual tools in Blender, regardless of which space you have chosen.
But you can use multiple arithmetic expressions in the input fields. So if for whatever reason I want to rotate or translate by additional 3 times 12/7, it's no problem. Just type in "+3*12/7" behind the original value and you're done. Sadly, Nvil can't do that (yet).
Ok, I let alone your precious offset fields for now. :) They just should do multiplication as well.
But what I still don't understand: 3 different windows to input values. That's 2 too many. Furthermore:
The input fields in 'Object List' are for individual objects. They are not manipulator related. While the input fields in 'Manipulation Input' window is selection and manipulator related. They work on the whole selection as a group in all modes.
Why would you do that?! For me it makes more sense, if it wouldn't treat the selected objects as a group when in object orientation mode. Think about this: I have a bunch of non-uniform objects (different position, orientation, scale[not to confuse with size]) selected and want to offset each of them by a specific value along the local x axis of each object. Same goes for rotation and scale! As I see it, it's not possible at the moment.
*Whew* This is a tough one. ^^
-
+ Island selection method is useful and pattern selection is quite fun!
-
As you can see, if you use the the absolute fields, The application will read the values of the three absolute fields to generate a result space. But if you use the offset fields, the application will only read the input offset value and rotate the manipulator by that amount along the corresponding axis from the current manipulator pose. The same as you just use your mouse to rotate that axis by the offset input amount manually.
I start to understand what you mean. What i don`t understand though is why this shouldn`t work with an expression and just one edit box. You just manipulate just one edit box by an expression, so just this axis should change. The first value of the expression is the absolute coordinate, the second value is the offset.
-
I start to understand what you mean. What i don`t understand though is why this shouldn`t work with an expression and just one edit box. You just manipulate just one edit box by an expression, so just this axis should change. The first value of the expression is the absolute coordinate, the second value is the offset.
Give me an example of the 'expression'. Do you use that in TrueSpace?
-
Let`s say i have 30 in the Y rotation. Then i type in a +30. What you can read now is 30+30. When i hit enter then it turns into 60. And the model rotates to 60.
trueSpace uses Eulerangles though. Means when i type in 190 then the expression for this axis jumps to -10. And the other angles may change too, flipping by 180 degrees. Which is a bit nasty sometimes. Because you cannot add it in the way you do with your offset box. trueSpace was Beta when it gots abandoned. And is pretty incomplete in some areas. So Blender is a better example here. It works with Quaternions, and counts up or down behind 0 and 360. Also here a 30+30 is a valid expression. Or a 430*2 Or 60/5.4 Or 120-50. It rotates around the chosen angle by the calculated value. Which is what you do with your offset box.
Since Blender is free, why don`t you simply download it and try it there? To see the Properties panel with the edit boxes hit N :)
-
I was expecting an 'Expression' you mentioned which is so special that I can distingquish it's absolute or offset input. If you are not so sure, it's ok.
-
I have the feeling too that we talk about two different things sometimes. But that`s the way it is :)
I was expecting an 'Expression' you mentioned which is so special that I can distingquish it's absolute or offset input
You can :)
19+22
=
Absolute Value + Offset Value
-
Can't use it. 19+22 can be considered as a new absolute value of 41. Unless you can type in colors and green as absolute red as offset. lol.
-
You need of course to do string parsing in that case, and separate the two values. With the math signs as a delimiter. And then you can use it ;)
But i still don`t get why you are this fixed at the offset edit boxes and its offset methods anyways. No other app uses this method. Could you please tell me one case where your offset method is of any better use than using absolute values? :)
-
I know I can use parsing to seperate them. What I mean I can't use '+' sign because it is a arithmetic operator. Anyway, this method doesn't seem intuitive. I just dismiss it.
I think the offset input is more usefull than the absolute input in rotation. If you type in y offset 45, the selection will be rotated around manipulator's y axis by 45 degrees no matter what the current manipulator's orientation is. If you try to click and drag the manipulator to do that you will never get the exact precision unless you use steppings.
Let's change the tranformation to move transforming. That may be easier to explain. Supporse I have an object selection and the current move manipulator's x axis is pointing halfway between world x and z axis. Now I want to move the object along the manipulator's x axis by 20.1 exactly. I just type in 20.1 into the offset x field. If I type in the absolute field instead, the object will move along world x axis and that's not what I want. Don't you think being able to move selection along the manipulator's axis by a precision amount is usefull? I wonder how you can achieve this in TrueSpace.
-
Let's change the tranformation to move transforming. That may be easier to explain. Supporse I have an object selection and the current move manipulator's x axis is pointing halfway between world x and z axis. Now I want to move the object along the manipulator's x axis by 20.1 exactly. I just type in 20.1 into the offset x field. If I type in the absolute field instead, the object will move along world x axis and that's not what I want.
Now i get it. Thanks for taking the time to explain it again and again until my old brain has accepted the data set :)
I wonder how you can achieve this in TrueSpace.
I simply can`t. At least not directly. trueSpace is incomplete here. And Blender too from what i can see. Interesting. That`s worth a request at the Blender Mailing list :)
-
Let's change the tranformation to move transforming. That may be easier to explain. Supporse I have an object selection and the current move manipulator's x axis is pointing halfway between world x and z axis. Now I want to move the object along the manipulator's x axis by 20.1 exactly. I just type in 20.1 into the offset x field. If I type in the absolute field instead, the object will move along world x axis and that's not what I want.
Now i get it. Thanks for taking the time to explain it again and again until my old brain has accepted the data set :)
Not really wanting to upset the "data set", but you can over-ride the absolute directions using a saved transform and setting the "Transform list-> Use as input space"
-
I was wrong when it comes to Blender. There is already a way, at least by hotkeys. G for Movement. Then the axis, let`s say X. To activate the local axis type in again a X. And then simply type in the value at the numpad :)
They don`t provide edit boxes for that though.
Not really wanting to upset the "data set", but you can over-ride the absolute directions using a saved transform and setting the "Transform list-> Use as input space"
*Tilt* Gimme a few days, i will surely understand this one too :D
-
I think this is getting out of hand. I will make a video in the next couple of days exploring the differences between Nvil and other applications when manipulating the transforms of an object in different spaces with the regular tools. Or put simple: I will move and rotate objects around in each application. :) I have an idea that Nvil will score well against Maya and Blender.
Yeah, I actually just discovered that I am eligible for a maya licence as a student. Somebody could have said so sooner. ;D
-
Oh, and in the mean time. This is how other applications handle the rotation. I think it's not much different: https://www.youtube.com/watch?v=zc8b2Jo7mno
The audio and video are a bit desync.
Since we're not animating anything in NVIL, gimbal lock shouldn't be a problem.
-
Recently I installed Silo again to check something out in comparison to Nvil. It was then when I realized that by now Nvil has leapfrogged Silo by far in most areas! Aweseome work, IStonia.
Yet Silo still seems a bit more streamlined and less cluttered. I still have a hard time figuring out the differences of all the tools in Nvil, that somehow are made for the same task, but each does it a little bit different.
-
ya agree, i htink what happend was features are being added without redoing whole tools so existing configs and workflow dont get broken.
something that should be sorted out before a RC of final version.
i would also love to see two builds, a release version, that focuses on polishing existing features, bug crushing and performance, and a bleeding edge fork where new ideas and features are tried out.
i also do agree that it has surpassed silo, is actually more stable too, since i remember a few operations in silo that would crash it like 50% of the time.
the only bit i find really lacking atm is UV editing, which i dont mind too much since there is the clipboard feature so i can fire parts of models between maya and nvil quite quickly.
-
Yet Silo still seems a bit more streamlined and less cluttered. I still have a hard time figuring out the differences of all the tools in Nvil, that somehow are made for the same task, but each does it a little bit different.
Can you list examples? I don't know how to use Silo.
It is inevitable tate more features/options results in more complexity.
There are two types of basic streamline tools
- The first type are those ones which have no ui options.
- The second type are those ones which has an option ui that you can show/hide by tapping Home key once the tool is activated. The tool names have '#' at the end.
There are two variations of the second type basic streamline tool.
- The first one has a default option set. If the option ui is visible, the ui options are used. Otherwise the dault option set will be used. For example, if you activated a polygon vertex normal direction extrusion tool but you want to do it in average direction. Without droping the tool, you tap Home key to bring up the ui, choose option from the ui then do the operation. You can hide the ui by tapping Home key again. This kind of tool suits situations where you use it very often.
- The seond one has no default option set, so it will alway use the options used in the ui regardless it's visible or not. For example, a general purpose polygon extrude tool. If you use the normal direction option 90% of the time and use the other options occasionally, you can set its ui options to normal direction then hide the ui. Only when you want to change your options you bring up the option ui again. This kind of tool suits situations where only one option is used very often and others seldom. So you don't have to make all the similar tools available through StreamLine tools and this can reduce your ui.
-
Ok, first of all, I like a lot of the workflow you implemented, IStonia. To name just a few more:
+ automatic conversion of selections when switching component modes
+ changing tools behavior while in use (tapping spacebar/home before interaction and/or during interaction)
Compared to Nvil's feature set, Silo is limping on a stump. A full comparison would be very unequal. But this I want to point out: Silo doesn't have that many tools, but the tools it does have are mostly applicable to all components (mesh, polygon, edge, vertex, sometimes UVs) and sometimes are context sensitive (is something selected etc.). So you can do most of the work with very few tools. There is just one extrude, chamfer or merge (and unfortunately not that many options).
- When I type "extrude" into Nvils tool search I get a total of 24 (!) results. At first this is overwhelming, and not in a good way. When you want to setup your streamline tools, this is simply overstraining. Eventually at some point, you realize that these are all manifestations of the same tool. But for me, that was quite some time, because I didn't use the visual tools window. And still you need to find the manifestiation that suits you.
- And there's even more, that confuses me. For me, it's visually unpredictable if by click on a button in the visual tools window a new option window pops up, or the options are displayed below, or if it's just an action without options or with a dropdown menu. Some buttons look greyed out, so at first I thought these weren't available. I haven't figured out yet what makes them different.
+ Tiles has done a great job with his toolbars, they're more intuitive.
- Another thing that is bothering me is that there are superordinated categories, but the actions are often not accurately subordinated. If there's a category that says "selection tools" I expect, that EVERYTHING (soft selection, selection style, loop/ring select, grow/shrink etc.) having to do with selection can be found in there and not elsewhere.
The more complexity, the more the order of things must be comprehensible and at the same time, easy to use. I'd like to think, that consistency is one important factor. What I am about to suggest may be a bold move. I have put some thought into it, but not yet thought the whole thing through, precisely because Nvil being really complex by now. I would encourage to have an open mind about it and not to refrain from considering big changes. One could always go back (roll back point, revision history, extra branch) and it's still beta.
The hierarchy in Nvil is this: Subobject -> Tool/Action
Since there are a few components, there are somehow redundant tools. My suggestion is to turn the tables: Tool/Action -> Subobject
So how could this work? At first I thought I'd need a distinction between actions and tools, with actions being "one-shot" operations and tools needing interaction from the user of some kind like it is in Maya, but I don't deem that necessary anymore. And with context sensitive operations these 2 get mixed anyway (e.g. context cut).
The distinction I would make is whether an operation has options or not. I would then take a look at which functions could be consolidated into one tool with different options. A good rule of thumb could be: If they have the same name, join them. Grow/Shrink Selection would be such a candidate. Instead of having several actions, you'd have one tool, that can be set to full grow, loop grow, ring grow, single step and so on and so forth. To pick up the example of extrude again, the options would have a common area like direction plus areas for face (inset, new polygons, grouping options) and edge (flat/shoulder style) extrusion respectively. Well, but how do you access the different options as a specific manifestation for the streamline tools, you might ask. I was thinking of customizable presets. Every tool with options should have the ability to save presets. So you set your options as you please and save it as a preset, maybe giving it a nice name. It would be nice if a help text is generated automatically which lists the chosen options. When you now enter your streamline tool customization, you'd create your tool, but wouldn't set a component type for it. When assigning a tool to a hotkey, you just choose the one extrude that exists, but in addition to that you would have to be able to select a preset for use with that tool. Now the preset contains the information what to do in which component mode. While using the tool interactively, you would cycle through the presets by tapping spacebar or whatever and the home key might open the options in windowed mode. When Nvil ships, you'll just need a decent number of reaonable prepared presets and Streamline tools. Everything the users need beyond that, they could build themselves.
Now there's something that would make the process even more enjoyable. That is a dedicated tool options window (dockable), so it's seperated from the calling of the tool (like it is now with the visual tools). At the moment it's also unpredictable if options are displayed inside visual tools window or if a standalone window pops up. It would be nice to always have it in one spot.
I'm sure there are implications that I have not thought of with this idea, but there may be an easy solution and I believe such a change could pay off. Play around with that idea in your mind.
-
- local move is the same as extruding without creating new polygons.
- collapse ring is the same as weld(general)->collapse edge ring?
-
- local move is the same as extruding without creating new polygons.
- collapse ring is the same as weld(general)->collapse edge ring?
Yes.
Edit: Generally, if the 'Visual Tools' window is hidden or auto-hide, the ativated tool's option panel will appear floating. For tools which can open in more than one modes, their option panel will be always floating.
In 'Visual Tools' window, flat buttons are for command tools. If a button's name ends with '...', it is a multi-commands button.
-
you l know if you use streamline tools only it is more like silo, like I only use 1 streamline extrude for example and it does everything I need. some of the tools are actually more powerfull now like a inset extrude in silo was 2 operations but in anvil it is one since the inset tool can do either inset scale like silo or inset extrude.
-
Yeah, I know I can customize the workflow by using the streamline tools, but the whole point of my idea was to make that process easier on the user by consolidating tools and make it even more customizable.
So here are again the key facts:
+ The number of tools would reduce, but not the functionality!
+ The users would be able to create manifestations (presets/configs) of the tools themselves to use inside a streamline tool or as a user button. On the other hand, IStonia's maintenance effort may reduce, because he wouldn't have to create all the manifestations himself anymore, when features are added to a tool (like extrusion snapping to spline becoming available to all subobjects, or local move not having to be seperated from extrusion).
+ Consistency may increase because of having one area for options, for subobject tools the options for different components are under one roof, maybe sharing common options. If I had saved a preset for extrusion with the direction set to normal, my assigned hotkey, e.g. z+LMB, in the streamline tool would apply that tool in that manner, regardless of component mode (consistent). Personally I would prefer a tool being on the same hotkey (z for extrusion, for example) for any component, rather than having different hotkeys for different components. You'd still be able to do so, by creating another streamline tool with another hotkey and maybe other presets.
+ You can still cycle through all your custom presets while using the tool (tapping Spacebar), modifying options on the fly (WMB) or call the options (home key if the options are not already visible), even when not called by a streamline tool, but activated otherwise (visual tools).
+ You then should be able to switch component modes without leaving the tool, because it's the same tool for all appropriate components.
+ The tooltip help would still show you the different options for each mouse button via the chosen preset. (LMB - Loopcut: selection only, proportional (click edge & drag to slide), #inserts: 1; MMB - Loopcut: midpoint (click edge to cut in the middle & slide); RMB - Loopcut: Doublecut (insert 2 loops at both ends & slide)
+ Besides choosing a preset from a dropdown for a given tool, in the dropdown menu there should also be entries to "show options" and "default". So I could setup presets for duplicate, making a break command (polygons seperated from others, but still inside mesh) or a duplicate command (polygons duplicated, still inside same mesh) and perform these operations via single-key press, or I could call the options when the hotkey is pressed, if I only want to decide then.
I can't think of any downsides of this approach right now, so you've got to help me out, finding them. It's just workload (sorting, consolidating, rewriting the code base ^^, making presets)
I haven't yet considered the implications for all the tools, especially commands/actions, but I think it'll be essentially the same. Save a preset where there are options available (grow selection: ring, full, stride: 2) and assign it (tool+preset) to a streamline tool's 'on activated', if you want to have it that way, or to 'on RMB click', if you want other presets to work as well inside the same hotkey (e.g. On WMB Up - grow selection: ring, single step, stride: 1). Otherwise, when there are no options (e.g. toggle backfaces shaded grey) just assign the command (no presets).
My hope is also that this makes the destinction between streamline hotkeys and normal tool hotkeys obsolete, because I don't get that anyway.
-
- Now and then I stumble upon tools, that do the same. Split and duplicate for example! Or as I mentioned extrude without creating new polygons and normal move, collapse and weld. I just find this redundance confusing.
-
iirc there is no extrude tool that doesn't create new geo rightfully so, and normal move is rather unrelated to extrude, and is equivalent of setting the manipulator to normal and translating.
but i do agree things are redundant as hell with the weld collapse tools, there is even a weld that triggers a menu that has collapse in it.
but it is as a result of there being so many ways to weld, like are you trying to weld everything to 1 point, or just weld to nearest, or target weld?
maybe if in the menu system it existed as just weld, with sub entries.
also im a terrible person to talk about htis since everythign i do i do via radial menus and streamlines that are setup like a hybrid of maya and silo.
-
-'Split' and 'Duplicate' are not the same.
-'Weld(General)' provides the possibility to access all weld/collapse tools. But if you need to do a lot of operations of the same weld, this tool will slow you down. That's why I still keep the individual tools available as seperate entries.
-'Polygon Normal Move' tool is a subset of the polygon visual 'Extrude' tool.
-Some people may like to have all the subset tools made and ready to use, instead of having to create yourself.
-Many tools are not applicable in all modes. So 'Tool/Action -> Subobject' may not be a good general way.
-
-'Split' and 'Duplicate' are not the same.
Ah, now I see, but the options are the same. You could merge the 2 into one tool, having the options that it already has and a checkbox for "duplicate".
-'Weld(General)' provides the possibility to access all weld/collapse tools. But if you need to do a lot of operations of the same weld, this tool will slow you down. That's why I still keep the individual tools available as seperate entries.
Well, with my suggestion, you wouldn't have to keep them as seperate entries, thus cluttering the ui. You just would have different presets of the same tool available at single key presses or seperate user buttons, if you'd like.
-Some people may like to have all the subset tools made and ready to use, instead of having to create yourself.
That's true, there'll be some people. But it's still possible to create all the possible presets ready to use before shipping. It's the same as you're doing it now. And still people will be able to customize to their liking. And there'll also be people that may like a less cluttered UI and a clearer arrangement of tools (count me in).
-Many tools are not applicable in all modes. So 'Tool/Action -> Subobject' may not be a good general way.
I have thought about that, too, but came to the conclusion that having tools that are available for different subobjects under one roof, could be of more value. The benefits I had listed in the previous posts. And some of the tools, that don't work in all subobject modes could be made to at least work for more than one (example: Silo's loop cut also works in face mode). And what's to hold me back from being able to activate a tool, while in some other mode? I could have a checkbox on the tools saying something like "switch to appropriate component mode on activation if not applicable". Or the tool simply doesn't work in that mode and the cursor would show a prohibitory sign.
One thing would get a little bit difficult though: wanting shift+x+LMB to be relax in edge mode and extrude in face mode, for example. But who does that anyway?! ;D You could still set shift+x+RMB to be a totally different tool, or you could create another streamline tool with the same hotkey assigned to another tool, but then you'd better be sure that the compatible modes are disjunct.
So you'd have common commands & tools, as you have now, but in the options of these tools, there are specific options for each subobject, if necessary. And then you'll have all the respective component categories with specific tools.
I would have to make a list of all the tools, I think could be one and the same, as well as work in different component modes, and which ones will still be component specific to get a ratio of common/specific tools. But I dont have the time for that at the moment.
-
don't combine spilt and duplicate, there are no other 3d packages that do so.
also most 3d packages at first appearance seem to have tools that work on all component types like your silo example and maya, and max, but if you look behind the scenes, there is a ton of tools like nvil, that are just being selected based on certain circumstances.
like if you look into the code that generates maya's marking menus, which are context and selection sensitive, you will see the items on the marking menu are actually a bunch of nested "if" statements that choose what tool to use on the go based on selection type and quantity.
same thing for the UI and quad menus in max and almost everything in blender, and modo.
personally i think the solution would be to keep the tools, and have some system for making UI elements do different things based on selection type and amount. which is already done in the streamline engine, and radial menus, it more or less just needs a method for doing this in the menu system, and have a really good default setup.
personally i think the ultimate solution would be to just have a scripting engine like max or maya, where all the tools and commands are accessible from python or a other scripting language, than have some utility commands for getting information like fetching the selection and getting basic scene information.
EDIT:
istonia don't feel too much pressure on the scripting thing, since i know that is a massive massive undertaking and prolly wont happen.
-
I don't think scripting would make it easier for most of the users, but could be a nice advanced feature. Yet, I still feel like my point is not coming across. :( My whole idea was to make stuff EASIER to setup. The fact, that I get 24 different tools for extrude is flooring me. Tools are not well arranged (like most of the selection tools not being in the categorie 'selection tools'). And the process of customizing Nvil's hotkeys is exhausting, because there are so many similar tools, when you just need one (which is customizable). For Example I have to setup extrude 4 times, before it works on all subobjects. Then there are 2 different hotkey setups (tools & streamline tools)?! What's that about?
It's a flat hierarchy for tools. With the presets, besides all the other advantages, you'll have one more hierarchy level and making the tools more identifiable and accessible. The list of tools will become shorter, the features richer, the joy greater.
At least we seem to agree that the status quo is no fun and should be changed. Less redundance, more consolidation, more accesibility, easier setup. My suggestion is just one possible solution, and I would gladly hear from other fertile approaches.
-
24 is a not true though, since if you search extrude there are only 3, with the rest being components of streamline tools, which are needed there for the current method of creating user streamline tools, and most aren't needed by the basic user who doesn't already know about them.
maybe all the streamline basic tools should be hidden from the search, since you can directly access them via the menu system either or even in the radial menu editor or key editor, just in the streamline editor and search atm.
though i do think the the edge, and polygon shortcut tools for extrude should only be one.
-
I certainly perceived them as being 24 tools. When you're using the software for the first time and look for extrude, you'll get this list. I suppose you don't understand right away what the difference between tools and streamline tools is (hell, I still don't get it, or rather wonder whyyyyyy). And especially when you're a basic user, who doesn't already know about all the extrudes, it's hard to tell which one to use.
And when you hide the Streamline basic tools there are tools, you wouldn't be able to access anymore, like the polygon_chamfer. It doesn't turn up in any UI, except the streamline tools. And it's also inconsistent. Whereas you get all the _chop_off and _refine, _refine_rounded tools for edges, for faces there's just one chamfer and you have to switch between the options via spacebar (at least for me it's spacebar). On top of that it's yet another example of tools that could be merged into one common tool.
I think it'll be best to go through all tools and sort them properly, consolidate, where possible and with the resulting hierarchy in mind, see what's best suited to make it all more user-friendly.
-
ya i think all the UI stuff can be consolidated, and made sure of that all features are possible with that method.
but i would like the streamline system to stay similar to how it currently is, since i have my own tools built on it, and it is very flexible for the advanced user in it's current manifestation.
maybe quick fix for now is to have by default a filter on search that makes it no include the streamline basic tools?
-
No, I wasn't looking for a quickfix on the search. :) that would be like fighting the symptoms, but not the cause. The streamline system would still be flexible, maybe even more, and easier to cope with. And you'd be able to achieve exactly the same setup, as you have now, I believe, but perhaps quicker. But I wouldn't restrain from changes, because a few people have already made their setups. when I first proposed this idea, I was also saying, that you could always go back, if it didn't work out or pay off, or having a branch at the side that tests this idea.
-
And the Then there are 2 different hotkey setups (tools & streamline tools)?! What's that about?
I suppose you don't understand right away what the difference between tools and streamline tools is (hell, I still don't get it, or rather wonder whyyyyyy).
Well, before we can go any further, these two questions must be answered first. I would like to see other people's answers rather than I answer it.
-
I think it'll be best to go through all tools and sort them properly, consolidate, where possible and with the resulting hierarchy in mind, see what's best suited to make it all more user-friendly.
Phew, this could take some time. Time I don't have at the moment. I just converted the hotkeys.xml to a table and there are 590 entries (some of them probably user setup streamline tools or radial menus, hence the strange ID names). But what's not in there are these, what I call manifestations that you can choose from in the streamline tool's setup, e.g. Vertex_Chamfer_ChopOff or Polygon_Extrude_AverageNormal.
What I will probably do is, to categorize whether something is concerned with mesh interaction, or with the interface, as well as if something is a one-shot-action or some interactive tool. But I have the feeling that won't do much for the cause. Maybe I get to know the tools a little it better that I've missed so far.
-
+ I just discovered 'Tweak Vertex' and its different brush tools. I had used the brush relax before, but I didn't know there were others. It's a really nice way of tweaking silhouettes of organic models, especially by being able to click outside of the mesh boundaries. WMB can be used to set brush size while the redirect key on the streamline tools makes it possible to set the strength via click & drag.
- Inflate is named "Explode" in the brush tools of tweak vertex.
- Pinch is missing in the brush tools of tweak vertex. It does the opposite of inflate (well, not exactly), which is pulling vertices closer together.
-
+ 'Select Similar' is a really nice feature that saves a lot of selection effort.
+ 'Vertex Transform Along Edges' will become useful. It's nice how you can preserve the surrounding shape of simple meshes with this. Making a cylinder top to be at a specific angle is now as easy as rotating.
-
I have to get back to my suggestion of a preset architecture of tools.
- Everytime I'd like to have a specific configuration of a visual tool as a streamline tool that hasn't been implemented yet, I have to ask the developer. Just now, I'd like to build myself an "orient tool", like Silo has it. I know it's possible in NVil if I open up the extrusion options and uncheck "Create new polygons" and choose cursor control. But I couldn't find a streamline tool for that behavior. If I was able to save that configuration of the extrude tool as a preset and set that preset up as a streamline tool, I would have easily solved the problem without making the developer any hassle. It might be also possible to have presets for 0.5 extrusion, 1.0, 1.5 and so on, if that was what I would always be looking for. Such a preset functionality would make NVil even more flexible and customizable.
-
Just now, I'd like to build myself an "orient tool", like Silo has it. I know it's possible in NVil if I open up the extrusion options and uncheck "Create new polygons" and choose cursor control. But I couldn't find a streamline tool for that behavior.
Streamline tools-> Local move polygon (hotkey H). The MMB is set for "Polygon_LocalMove_CursorDirection
Just to add.
After using that tool/function, the last action is stored and can be recalled by pressing the hotkey(H)+LMB(click)
-
Oh, thanks, steve. So ok, the tool is already there, but my argument still stands! ;D
It just made some other thing more prominent: It would have been a lot easier for me to find this tool, if the hierarchy of tools had an additional level, or another kind of hierarchy. Presets would accomplish such a thing, because the list of superordinated tools would be shorter, and then fan out on the preset level. Now I'm just repeating myself.
And yup, at the moment you can perform the tool with the last settings (unsless it's linked to MMB it seems), but with presets I could set up different settings, for example like a chamfer for really round edges (0.5, refine, rounded, 6 segments, offset 0) and a chamfer for smaller geometry (0.03, refine, rounded, 1 segment, Offest 1).
-
As you guys surely have noticed by now, I'm pretty hardheaded on that tool preset idea to the point where I'd like that spark of an idea to become a full blown plasma torch that burns into the very foundation of the program, more or less. As I was further thinking about it, I imagined what the marketing ads would look like for NVil with it's current system.
"Choose from hundreds of developer predefined tools for your customization!" Well, less is the new more. Instead it could say "Save any personalized setting of a basic tool as a preset and bind it to a hotkey, user button or radial menu for easy access. NVil already comes with the most common presets ready to use." And then something splashy between the lines of "This is my rifle. There are many others like it, but this one is mine."
Don't get me wrong, there' a lot I like about NVil, but the long lists of tools and how they're ordered and cluttered is something only a mother could love. I did start a list with all the tools to work on suggestions how to declutter and consolidate them, but new tools keep coming in, so I probably have to start over.
Since this could mean, that people may have to do their setups again, maybe save it for a major release. OR do it as fast as possible, so less paying customers would have to go through with it! ;)
-
It just made some other thing more prominent: It would have been a lot easier for me to find this tool, if the hierarchy of tools had an additional level, or another kind of hierarchy. Presets would accomplish such a thing, because the list of superordinated tools would be shorter, and then fan out on the preset level. Now I'm just repeating myself.
Why would a list of tool presets(settings) be shorter than the list of tools that give those presets?
And yup, at the moment you can perform the tool with the last settings (unsless it's linked to MMB it seems),
MMB action is stored and repeatable (in current session) on my setup.
but with presets I could set up different settings, for example like a chamfer for really round edges (0.5, refine, rounded, 6 segments, offset 0) and a chamfer for smaller geometry (0.03, refine, rounded, 1 segment, Offest 1).
I have not yet found a need for tool presets. All the models I build are different and therefore are different in the tool settings that are required to create the model.
-
Why would a list of tool presets(settings) be shorter than the list of tools that give those presets?
It wouldn't be one big list on the streamline basic tools level anymore. As I stated, it would be one list with superordinated tools, like Extrude, Chamfer, Cut, Split and so on, and the different manifestations like extrude_cursordirection, extrude_polynormal_individual, local_move_average, last_used_setting, default, show_options etc. would be listed in a dropdown besides the tool. Thus, the list on level 1 you are presented with gets shorter. I could also save a setting, that would make 'by individual polygon' in 'polygon grouping options' of the extrude tool the preferred method of extruding, without the need of pressing space before extruding (but the other way around). It would be up to you.
It could well be that you wouldn't even need the distinction between 2 lists, the tools and the streamline basic tools, anymore. You'd just have the tools list, where each entry, that supports presets, has a dropdown with presets to choose from. The default setting for those tools could be "show options". You could easily change that in the tools list. And when in the streamline tools editor, when choosing a tool for LMB drag, for example, you again get the tools list and select a tool with the wanted preset.
You wouldn't be constrained to just basic streamline tools, you could also set up presets for commands like delete(options), split, duplicate, FlipXYZ, Subdivion, Instance etc.
-
But you would still need presets for each individual function, so the list of presets would still be the same number as the functions (if one preset per function).
For example:- You mentionedand the different manifestations like extrude_cursordirection, extrude_polynormal_individual, local_move_average,
Those can be placed in one streamline engine tool, but they are different functions with different possible results, so each would require different presets.
If you did not have different presets for each individual basic streamline tools, how could you build streamline engine tools in the way you put forward?
To me it looks more like making the basic streamline tools into visual tools, with full options shown in drop_down with preset entries. One of the main aims of the streamline engine tools is to avoid that for quick workflow.
-
But you would still need presets for each individual function, so the list of presets would still be the same number as the functions (if one preset per function).
If you did not have different presets for each individual basic streamline tools, how could you build streamline engine tools in the way you put forward?
I feel like I need to clarify a few things about my suggestion. When I say "tool", I mean the tools that you have, if you go to 'Edit->Customize->Tools'. In the current state, there are a lot of tools that display some kind of options, like 'Delete(Options)', Extrude(Polygon Shortcut Tools). If I assign a hotkey to such operations in the tools customization, it will open up the options window for that tool.
A streamline basic tool is nothing else than a preset made for a visual tool by the developer. When I said "manifestation" I did mean the streamline basic tool, because it is a visual tool that manifests itself in a specific bahavior without opening the options.
What I would add, is the ability to setup and save such streamline basic tools yourself, by adding preset management functionality to EVERY option window where you can choose between different settings, not just for visual tools, but including delete, flipXYZ and split for example.
Since streamline basic tools are subordinated manifestations/presets of a visual tool, I could as well order them in that way, resulting in an additional level of hierarchy. So I would have a list containing these tools: bridge, extrude, chamfer, tweak ... Now imagine that each of these tools has a dropdown menu besides its name, where the streamline basic tools for that specific tool are listed (Poly-Extrude: CursorControl_GroupTogether, IndividualDirections_byIndividualPolygon, IndividualDirections_GroupTogether etc.). In addtion to the user/predefined presets, I would add a default bahavior (kind of default streamline basic tool) and "show options" (which would be the visual tool as it is now), as well as "last used" (last used configuration of that tool as a streamline tool) to the dropdown menu.
I could now go into "Edit->Customization->Tools", look for a tool like extrude and change it's dropdown from default to CursorControl_GroupTogether preset. If I pressed this hotkey I would enter the streamline basic tool, but still be able to call the options with the home key, or cycle through the presets by pressing the option cycler key (which would also change the settings of "last used").
Besides the normal hotkeys, I would still have the streamline engine tools setup. But when clicking on "set" of the LMB Tool I would get kind of the same list with bridge, extrude, chamfer, ... but they'd too have the dropdown besides their name from which I choose a specific preset. So I can set "Poly-Extrude: CursorControl_GroupTogether" to LMB and "Poly-Extrude: IndividualDirections_GroupTogether" to RMB, just like it is possible now. Only the look of the UI has changed, and I can setup my streamline basic tools myself, if I want to. So yeah, the number of TOTAL presets can be way higher, than the current number of streamline basic tools, but it'll be more well arranged, because they'd not be listed one after another in a huge list but by their superordinated tools (extrude, bridge, chamfer,... each with their presets ordered in a dropdown beside the name).
Of course, NVil would have a number of predefined presets per tool, just like it has now with the streamline basic tools.
In the current state of NVil, you could arrange the UI in the same way I described, because streamline basic tools are those presets/manifestations I am talking about.
I hope there are now no more misconceptions about my suggestion. Next time, I will mash up pictures of the UI as I imagine it. Or maybe I will do anyways, just in case.
-
+ I find, the new organization in tree views and expandable categories makes the lists of tools much less intimidating. It gives me a better overview of what's what.
-
+ Retopo tool has some nice features. Being able to move/extrude whole loops by just clicking one egde, striping, creating a polygon from extruding a vertex, bridging multiple edges, rotating and scaling, the improved rendering to better see the mesh.
-
I don't know if it was mentioned here already in this topic, but what I just love are the: Turn Flow and Turn Flow and Relax commands. They're so freakin' cool! They completely eliminate the necessity of using spin edges commands and guessing what edge to spin in order to reroute the geometry flow the way I want it to go. IStonia, you're the best, man.
-
+ Some parts of the whole presets idea I had, are now possible with the composite tool editor. This is great, even though I think this feature is just getting started.
-
+ The tool search inside the tools editor/window is a huge time saver. I now especially noticed it while playing with composite tools, where I search for a lot of tools in quick succession.
-
+ Edit >> Preferences >> Special Options >> "User Settings" folder in application folder
That allows me to start NVil with different setups (e.g. one default for making wiki-screenshots)
+ constant development
-
+ I just realized how important the feature of combined keyboard & mouse shortcuts is for NVil. I think no other application does that and it's totally useful. Press a hotkey + mousebutton, simple but very effective.
+ "tapped" key state to call some function. So I can have the visual tool on tapped and the streamline tool on hold. Still, release state slots in streamline tools would be nice, too.