What you show in the top picture would be covered by what I am currently working on.
However, in the buttom picture I am slightly unsure what is going on. Are you saying you want to be able to make a cut on one object and then apply the cut to another?
Thank you very much for the detailed feedback!
In response to your various points:
That bug actually existed prior to my GSOC project and I had tried fixing it but I believe it is a problem with the way blender tool’s work in the code. I will nonetheless take another look at it to be sure.
The reason it is apart of a popover is as a result of: ⚙ D10853 Knife Tool Constrained Angle Mode Improvement. It gives space for later on when more options may potentially be added to the top bar (which will be the case as part of @CybranM feedback).
To keep it consistent with the rest of blender I have labelled it as an angle and so it was automatically given that increment. When click dragging I do agree it should be increments of 1 degree, as that is more intuitive, so I see if it is possible to change.
Local angle snapping only works when there is a face for the angle to snap along. This is why you see it not working when your mouse goes off of the face. However, I see how it is fairly strange and will definitely make improvements. For example, it should work when a cut is started from an edge as you show, without requiring a second cut.
Snapping to points through the mesh was not possible before my GSOC and I think it would be quite difficult to add. I would say it is out of scope for this project. The reason for the “ON” and “OFF” meaning is because of what depth checking means. I realise this may not make sense to some end users and will rename it to something else.
I think this is what is wanted, to continue line with constraint. I mention about it in 4th point as some area issue with local constraint
Maybe it should be “ON” (not seeing through) by default then? in order not to confuse users.
Need to know the opinion of other users about this.
On first picture - to be able to snap to any snap point on any model in scene. Same as we able to snap to anything in scene when extruding vertex, for instance, not only to mesh of models currently in edit mode.
On second picture -same snapping to"outside" models but selected polygon sliced by contiuous line based on two points snapped anywhere (“ubbounded line mode” something, you name it). Very common case in poly modeling.
Right now only way to do such cuts in Blender is by help of Snap Bisect addon (big thanks to author!!!) and some workaround of duplicating temporary vertices (because it can snap to only current mesh points as well).
My typical house model for Unreal usage.
Dozens of house model parts - walls out, walls inn, floors, roofs, etc. hundreds of diffetent dors windows and so on instances. It is very common action for archviz modeling to cut something according to/aligned to anything else in scene.
For example it need to cut in wall opening based on new window position. Believe me - you will not want to go out from edit mode, select one of window (instance, one of few dozens), go back to multi edit mode of this wall and those dozens of instances, do your cut, go out from multi edit mode, deselect all windows instances, go back to edit mode of just wall…
What you want instead is just start Knife, do two clicks on two window model corners, confirm.
Multi edit mode not solve this case… you will not want to go all the time IN/OUT from/to multi edit mode, select/deselect object to do simple cuts thousand times per working day. Same as you will not want to work all the time in multi edit mode of everything in scene. This multi edit mode is cool for character modeling something maybe, it is not so cool for many other workflows.
Not understanding of such things IMO come from the fact that feature developed by people who not do real work with those feature… in imagination of such developers feature is amazing, in reality it is not.
Old screenshot from 2.79 but it does not matter. All this below ALE_H1 is single house, fully modeled inside - all flats, stair, lifts. This is “real work”, not some test cube and sphere in test scene you cut in multi edit mode while coding…
But instead of thousand words - just go to my old old RCS suggestion link and wathc video in my reply in comments section.
the short answer is because modal operators don’t have any concept of snapping, it has to be done on a per-operator basis. why? because an operator can be anything, it doesn’t necessarily have anything to do with transformations at all. hell, even the transformations themselves are handled on a per-operator basis because it’s just a framework for executing some kind of functionality. The snapping functionality you are familiar with is pretty much exclusive to the built-in transform operators: the bpy.ops.transform family. Pretty much every other operator is the wild west and does whatever it wants. Would it be nice if every operator that could utilize snapping actually used it? absolutely, but that’s not how it works right now, and probably won’t anytime in the near future considering the snapping functionality itself isn’t even feature complete yet.
I agree with double A, it is a nice solution since knife is not a drafting tool.
The ability to temporairly ignore snap is a demanded feature as well.
Also it is interesting how much people need Polycross functionality. I’ve got some ideas of its enhancement here.
dbl A is reserved:
first click A - screen constraint
second click A - local constraint
third click A - Off
so how it should behave with dbl A idn…
move “Off” to fourth click and on third click add this …?
I think 3 clicks on same modal key is to much, 4 clicks - you can lose yourself in it=)
Adding new modal key - there is no screen space for it already…
Found another bug with Local constraint.
It related to my previous notes about edge area.
and finally how to do this, no needs in additional modal key
I’m glad the list was of use, looking forward to seeing the next version!
The only point I would contest is getting rid of “ignore snapping”. I would consider this a useful feature to some, and not everyone is going to make use of the knife tool with angle snapping always on as you perhaps would.
That’s fair, I only know my own preferences. How easy or hard would it be to allow users to change that in the tool hotkey settings? More options → more better 
How would you propose to toggle between edges for snapping relative to? I could see pressing ‘A’ further times to cycle between edges while in local angle snapping mode, but only when there is multiple edges
I agree that “A” is already overcrowded, its not a function I’d use all the time and I don’t think “R” is occupied so for me that would be a candidate. Not that I agree with the “hotkey based on name of tool” system for hotkeys but “R” is close and sort of makes sense with “Reverse edge angle”
@APEC Didn’t think of doing it like that and it’s good that you can, although it isn’t very intuitive or fast. I’d prefer it be a quick toggle and then you keep going instead of having to stop and reverse.
Would it be nice if every operator that could utilize snapping actually used it?
Actually - yes. Would be I think, as well as I don’t see reasons why would it not be. Would be nice to have such unified snapping API implementation for addon developers to use in their addons.
From user perspective I dont see that much difference between extruding vertices and drawing Knife cuts. Both about same shit - create point in space and snap it to something in scene if needed. Why Knife in 99% similar case should not use same snapping behavior? Modal, not modal… who care.
If it was implemented from start in way that not allow to use general snapping, than this implementation is wrong and has to be remade. Instead of adding angle snaps or so it need to work on this.
Angle snaps is cool, no doubt, undo functionality even cooler, big thanks of course for working on it. Big thanks to you HobbesOS bro for doing this. I appreciate it.
But still, from my pro user perspective this is nothing but adding spoilers to car with no wheels. It has engine, nice and loud in test room, it has cool aerodynamic now with new spoilers… but it still can’t ride real roads without danm wheels. So what the point of all those spoilers?
Actually - if Snap Bisect addon not exist I would never switch to Blender as main modeling soft. I think in 90%+ cases in my work on modeling houses and everything around - Knife Tool as cutting tool are absolutely useless. Same as default Bisect tool useles because of same lack of snapping.
No snapping = no precise modeling. No precise modeling = useless tools. What else to say here…
I think you’re bringing up good points and I agree with them but the way you phrase them isn’t very friendly. There’s a lot I wish was better in Blender but there’s no reason to be rude to the people working on fixing them
I have not done much with the hotkey settings menu yet, I will see if it is possible.
I like the idea of using “R”. I would have it only work while in local angle snapping mode and with multiple edges that can be cycled between. My main concern would be the sheer number of modal keys that the knife tool is beginning to have, but for the time being I will add it and see what people think when I publish a next build. (cc @APEC , @1D_Inc)
Thanks, I will try fixing these things this week!
When you wait for so many years for any progres in some sensitive question and finally something is going on, but it seams like people have no understanding what really mater. It burn me out of course.
Someone/sometimes have to say something not 100% complimentary to get only likes. Let it be ugly me. If someone disagry - I always opened for argued discussion.
I do appreciate all of the concerns you have with the tool, but in its current state changes like this would require a lot of work to the existing code. It certainly could be argued that the initial design of the tool was flawed if this is the case. Nonetheless, I would really like to see these changes myself and I believe that the work I am doing in these last weeks (aside from the various bug fixes suggested by you all) will enable such changes to be made, whether by me or someone else.
At the end of the day, these features were not included in my initial project proposal and as the GSOC period comes to a close I cannot make promises about implementing them myself in the future. If I do work further on it I will make sure to share.
Actually I have say no bad word against any “people working on fixing them”. But someone someshere in offise lead this fixing and choose what to do. It seams that this someone have no experience of using tools in real work cases.
Eg. if I asked here - did anyone of those who responsed on Knife development have at least few years of experience working on some complex poly modeling (hypothetic modeling spaceships for Star Citizen, tanks for WarThunder, huge houses, like me). I can’t be sure, but answer will be silence, probably .
I understand you are passionate about this topic, but I would prefer if we leave it rest until after the GSOC period is over. There is no time to include it in the project and at the moment I am primarily looking to receive feedback and discuss in this thread about the work I have already done, specifically any bugs or quality of life improvements.
Dude, big thanks to you for all what is done. My criticism is more to people (I don’t know who exactly) who lead development and guide it. I wrote it with hope that my arguments posted here may be see by such people.
