Hard Ops Thread

If you start the cut off the model, it automatically uses View projection cuts. You can then hit tab and move it around and tweak it.

If that’s still not enough: You could also put your changes in source control like git, on a separate branch(important), then copy BC updates to master and merge master into your branch. Unless the changes directly overlap yours, git’s auto merge will take care of it.

A third option that wouldn’t make such a drastic change to existing Boxcutter behavior would be for @masterxeon1001 & team to tweak bc.surface to make it friendly to hotkeying. Right now it doesn’t appear you can hotkey from UI nor does it accept a parameter you can tweak in the keymap for which Draw Surface type you want to switch to.

thanks for the insights!

Uh, why would you possibly make it so complicated? That makes no sense. There are 4 cutter orientaion modes, Object, View, Cursor and World. The latter two rarely used.
image
And there is a “Behavior” section completely overloaded with various micro management checkboxes:


So all it’d take is to add one more checkbox which would automatically switch between “View” and “Object” mode based on if the 3D view type is User Perspective or not. The option would be off by default, so nothing would change for existing users, and no new hotkeys would be introduced.

Basically, instead of manually opening the BC pie and telling BC which kind of cut you are intending to do, the BC would determine that based on if you are in a perspective view or not. Almost no one makes view aligned BC cuts in perspective view because the result is unpredictable.

This would speed up workflow significantly, because you can signal BC your intention just by whether you are in perspective view, where you most likely want to make object aligned cut, or if you are in ortho view, where you most likely want to make a view aligned cut. There is also a case where you are in a user ortho view, and still want to make an object aligned cut, and in that case you’d manually switch the mode yourself. But it would reduce the amount of mode switching from “almost all the time” to “only in some specific cases”.

The suggestion to BC team is so two hotkeys could be made(and maybe it can be now, I didn’t dig into the operators, I just leaned on the tooltips) one that changes to View and one that changes to Object. Then you could flip back and forth as needed without going through the UI. This was suggested as a quick change without a lot of code changes or adding new behavior.

Maybe they don’t want to add another checkbox to all those checkboxes? They could be trying to get rid of them completely.

I’m not discounting your idea, I just had nothing to add to it you explained it clearly enough. I was just trying to suggest something that might help that is faster to implement with less impact and a useful addition if this switching can’t be done through hotkeys now.

To elaborate, the idea is mainly an error prevention. Often, you are in a perspective view, wanting to make a cut like this:


but after you click and drag, you see this:

And you are like “oh, I forgot to switch the mode!”

Or you are in an ortho view, wanting to make a cut like this:



but after you draw your shape, and cut it, you end up with a result like this:

cause the cutter was in object mode, so it was aligned to a starting point normal. So you are again like “oh, I forgot to switch the mode!”

The thing here is that this is not something that can’t be determined by a simple rule based logic. If it’s a decision a computer can make dynamically, why offload it onto the user?

by design it’s use is supposed to be like this.

Yeah, it did this because you started the cut on the model. Had you started the cut off the model, in this situation, it would have done the right thing without having to change out of Object.

Well, that’s the issue actually. I am AutoPerspective user and love it. I should not be forced to turn that off. I also like to work in perspective view, as ortho distorts the proportions of the 3D object.

In the video, you yourself have made an unintended action of making view aligned cut in perspective view and got unpredictable result. And in the two subsequent videos you are constantly wrangling the pie to toggle between object and view mode. It doesn’t prevent one from getting the work done, but it slows down the process and distracts from the creative aspect of it.

My idea is to have an option to simply signal BC which type of the cutter orientation alignment I want to use based on the type of the view I am in. That would mean you no longer have to wrangle that setting most of the time.

Let’s say I have a cylindrical shape from a side view, and I want to make a cut like this:


How do I start that cut outside of the shape? (Excluding the unfeasible workflow of always drawing it outside and then moving it inside, which would not make sense if you want to for example draw an Ngon along existing contours of the object)

something like that.

if users choose to hide their topbar or other assistive elements then its another story. Then you have the Pie or the Helper.

1 Like

Not disagreeing with your issue here: You remember to change the Draw Surface to View

I do have the topbar, but I am still confused. At no point in that vide are you in actual perspective view. Using the topbar, you just trade off amount of clicks for large mouse cursor travel distance. But it changes nothing about the need to constantly remember which state you are in and keep manually toggling it, more often that not to correct an unintended action only after you already started it.

Here’s an example of what I’d just like to have:


Just ability for the workflow to be as smooth as this, without any UI interruptions. If it worked just like this except that the cuts made from the ortho view would be automatically made view based, not normal based like they ended up in this video. If you see how effortless is to switch between perspective and ortho using auto perspective without any hotkeys involved, if BC worked with it, you could just move around your object and work on it freely, without being burdened by the technicalities of the tool.

thanks for the insight! It will be taken into consideration.

1 Like

To be clear, I am not hating on BC or anything. I’d just like the already great workflow to be even better than it is. There’s so much potential in it in terms of focusing just on the art. So this small thing could make it even better.

I am actually browsing the Python API docs right now to see if there’s any way to get the state of the viewport (User Perspective, User Orthographic, etc…) so that I could switch the mode based on it. If I get it working, I can send that python snippet here.

Changing line 368 of addon/operator/shape/draw/invoke.py to:

if context.space_data.region_3d.is_perspective and (hit or bc.snap.hit):

seems to do what you want. Though you can no longer use objects as draw surfaces in Ortho mode. Since you’re using Auto Perspective, it wouldn’t be an issue.

1 Like

Huh, amazing! You’ve just saved me a lot of time!

I think I will try to modify it so that the auto switching only happens if the mode is set to “View”, and if it’s object, it won’t be automatic. This should keep both workflows intact.

The View mode actually has already similar sort of option existing:
image
But it’s a bit of inverted logic. Instead of solving the unwanted view aligned cut in perspective by falling back to object orientation in perspective, it switches the view from perspective to ortho. So my solution would just be inverse of that, where if you have “View” mode set as orientation, it would fall back to “Object” if the view is detected to be perspective :slight_smile:

Something weird about that Auto Perspective checkbox. I don’t have it visible when I open Blender. I did something to make it appear but now I can’t figure out exactly what.

Maybe it’s present only when Auto Perspective is enabled in Blender Preferences?

1 Like

Yep, that’s it. I turned on Auto Perspective to test my change since I don’t normally use it.

It works really well. Thanks again!

It’s crazy how literally a single changed line of code can affect how such a complex tool feels!

1 Like