Currently Blenders knife tool is pretty powerfull, however there is one thing that keeps bugging me. The angle constraint is in screen space. Matybe could leave that functionality as is and add X,Y,Z shortcuts working the same as for G,S,R?
Also could anyone point me to a discussion that covers why the default behavior was changed to ‘follow mouse’ instead of click-click it was before. If I understand correctly:
K-Key knife starts at first clicked point and follows mouse with cuts only at edges (no interior poly points)
Shift K-Key knife uses click-click behavior but needs a selection first but it is possible to place points inside polys
Pls, ignore the upper paragraph, was only my shortcuts messed up.
also an undo, many times you miss just one cut and you have to either start all over or fix it afterwards, and it’d be great to just hit x and delete the last cut.
Yep, this happened to me X times. Almost every time I try to make multiple cuts in one session. I just avoid it all together and make cuts one by one with confirming each one.
I think the biggest improvement that could be possible for the knife tool… is making it perfectly accurate… right now the knife tools precision is based on screen camera position…
@el_diablo: sorry about the screen-space-only angle constraints. I had a hard time thinking of a user-interface model that made sense for non-screen space, but maybe I was being lazy. Are you saying that you would be happy with ways of constraining the the cut to the global X, Y, or Z lines? What about other angles? What about local coords?
@Looch: yeah, undo is often requested. I should get off my lazypants and implement it. Or maybe some other budding developer would like to try (wouldn’t be too hard).
@MatsuikoHiroka: no, there is currently no way to set a custom increment. The 45 degree increment is built in.
@doublebishop: I’m not sure I understand. Since the cut is defined by the pixels that the mouse is over when you click, I don’t see how to get more precise than the fuzz implied by that position. Unless you want a keyboard way or a snap way in the UI to indicate cut endpoints and directions? There is another problem with precision, which is that it is all done in single-precision floating point. This is pretty much true of all of blender and would be a huge project to fix. With knife in particular, this limitation has been the source of an endless stream of bug reports. [Edit:] Campbell reminds me that knife project uses the same code, and thus, camera precision. Here my point about pixel fuzz doesn’t apply, so I agree that improvements could and should be made. Especially control over snapping.
another improvement might be to cut in faces
right now seems to cut only edges
and have to agree that for angle it would be nice to be able to set it up in tool panel
can you elaborate on the precision
right now still limited to 7 digits
would it be difficult to make it higher like 9 digits or full double precision like python
or may be have an option if possible to set the precision may be in user preferences panel
PC are becoming more powerful almost year / year
Intel is coming out with Gen 6 very soon which should be faster ect…
What I would like to see implemented is option to move cut line. For example I want to split mesh, I would make line with knife, but usually that is not perfectly precise, so I would hit and hold Space and that would give me option to fine tune cutting line position.
Something like this might be quite possible, in my opinion, after the work of the Wiggly Widgets branch gets merged into master (due to how it facilitates for temporary widget drawing and how it will allow for the user to use widgets instead of tweaking values in the last operator panel).
Then, it could easily be done by drawing a basic widget in the form of a series of lines.
Wouldn’t be 2.8 a good occasion to move to 64bit precision? I mean, the discussion is always ongoing, and a lot of tools will be reprogrammed. It’s better to do it now, than let all the rewrites be done and then move everything to 64bit?
Blender is getting more complex and the scenes we render also do. As you said, many bugs are due to this precision issue. So it may take some time to do, but it will also saves a lot after it has been done and will offer new possibilities for scene complexity to the artists (huge worlds with tiny details, better precision tools, etc…)
For the degree input, I also agree it would be nice. But more important is to get the (shift+) x,y,z constraint together with custom orientation working to be consistent with grab, rotate and all other tools in Blender.
Your tools and communication with us is really appreciated Howard
@doublebishop: I’m not sure I understand. Since the cut is defined by the pixels that the mouse is over when you click, I don’t see how to get more precise than the fuzz implied by that position.
Aiming with the mouse to hit the right screen pixel with a 1920 screen resolution is mission impossible. Just curious, does the knife snap to edges or vertices when the pointer is close enough? Like 5 pixels or so? This could solve some wrong clicks.
It’s not really that simple (I’ve looked into it a little bit). First of all, the roadmap for 2.8 doesn’t really call for refactoring Blender’s tools at that low of a level. Furthermore, even with Blender’s main codebase at double precision, a lot of the libraries that Blender depends on are only written with single point precision… not to mention the fact that the majority of GPUs currently used for working in Blender are optimized for single point math rather than double.
I’m not saying it isn’t possible, but it’s certainly not trivial and I’m not entirely sure doing so will yield the results that you think it will.
This almost makes me think you don’t use the knife tool or maybe you just don’t use Blender at all(<- I forgot about your gripes with the interface)
It snaps to edges and vertices when it is snapping to an edge the edge gets highlighted when it is snapping to a vertex there is a red border around the green cutting box.
holding down shift turns snapping off, ctrl gives you a mid point snap…
@howardt undo with knife tool will really be welcome…this is something I miss sometimes in Blender that AutoCAD has. I wouldn’t know how it would work 100% but this could be something worth looking into for all modal tools in Blender.
This almost makes me think you don’t use the knife tool or maybe you just don’t use Blender at all(<- I forgot about your gripes with the interface)
Indeed, i haven’t used the knife tool for a while. I do everything else like unwrapping and animation, etc. in Blender. But i don’t model in Blender. It’s still too slow and cumbersome compared to what i use. And so i always return to it after playing around in Blender and testing the new things. And yes, the UI is part of the problem. But that’s why i have started the Blender fork.
It snaps to edges and vertices when it is snapping to an edge the edge gets highlighted when it is snapping to a vertex there is a red border around the green cutting box.
holding down shift turns snapping off, ctrl gives you a mid point snap…
Okay, so it does theoretically what it should. Thanks for explanation. Next step in the analysis: when so many people have still problems with it, then maybe increasing the snap radius could help.
Wouldn’t be 2.8 a good occasion to move to 64bit precision? I mean, the discussion is always ongoing, and a lot of tools will be reprogrammed. It’s better to do it now, than let all the rewrites be done and then move everything to 64bit?
Upping to 64bit precision but not removing the screen dependent knife cutting will still make it inaccurate, just more accurate then it currently is… IMO they should rework the tool to make it not based off screen space at all.
We work on projects sometimes 20km x 20km (1m = 1 blender unit)… if we need to do a knife cut we use one of two ways…
Preferred method - Create a mesh of the cut area, which allows us to get smooth curves if needed… and knife project it in from side / top view (orthogonal).
Alternate method - use Knife tool to cut from side / top view by clicking on the mesh where we want it to be cut and then refine afterwards.
BOTH are dependent on your screen… if you take the large object, and knife cut it when the viewport is zoomed so you can see the entire mesh… sometimes the lines are not perfectly straight… sometimes knife projecting fails… sometimes there are weird glitches caused from this operation… however if you zoom all the way in (as in you cant zoom in any further) and then knife project, it works fine.
Could use some options on the F6 panel, that custom angle suggestion is a good one. I know it has a key to disable snapping, but there are times where I’d rather it had the opposite - it doesn’t always want to snap to a vertex and you have to fidget with positioning to get it to do so. Really would be useful to have a force-snapping toggle.
As for some positioning, I also find that one of the shift numpad options which makes you “view along selection” is good for certain cut alignments while in ortho view mode. It can orientate in some disorientating ways though, so you have to use one of the other numpad views to get rightside up again.
Sounds like undo is a popular request. I will try to find time to look into adding that.
@doublebishop: I corrected myself about knife project. That should probably not depend on any aspect except the view direction. But, I suspect the major difference you are getting between zooming in and not doing so is snapping behavior. Maybe knife project should never try to snap? Or require much more closeness (order of .0000001 difference) to snap when projecting?
A threshold parameter (in world units) would be good.
@Fweeb Maybe it’s possible to not have everything in double precision, but just some parts. For example, many image retouch programs use 32bit/channel processing on 8 bit/channel images to lower the precision loss due to several transformations. Maybe the object coordinates could stay 32bit, but mesh and/or tools could compute in double precision? For the speed, the OpenGl viewport can also be 32 bit with the real data being 64bit or more (many open world games already do it as far as I know).
