GSoC 2021: Curve Improvements: Feedback

Ctrl to toggle snap on/off is default for all transform and draw operators in Blender… if the pen tool will have the snapping features some time then I think it would be with the standard hotkey.

1 Like

Yes, I agree, changed this in the previous post. What I am concerned about though is that you may not be able to add points by holding Ctrl, whereas this is standard practice elsewhere. Maybe these would then need to be under a curve edit tool? Then it would at least be possible to satisfy all hotkeys with minimal use of double modifiers.

3d curves
What about 3d curves?
To my understanding:

  1. There is no way to constrain a point’s handle to a plane, which is important so the curve won’t ‘wobble’ in all kinds of directions
  2. There is no way to planarise a curve (on an arbitrary plane)
  3. There is no draw on surface mode, so you can draw a curve on a mesh face and constrain it to this face.
  4. Ideally, there would be a gizmo which allows you to draw a curve in 3d, in which you can change the plane the next point is drawn on relative to the previous. This gizmo would have 3 planes along XYZ axis, you click a plane and draw on that. It would also have rotation handles for all 3 axis, so you can draw on an inclined plane. Each time a point is drawn, the gizmo moves to this point so you can change planes on the fly. Local constraints and global XYZ constraints are far from ideal when you are drawing curves in a truly 3d space, wherein you don’t draw on 90 degree angles.
  5. For smooth curves for industrial and automotive design, curvature combs (or curvature analysis) would be much appreciated. It is based on the derivative function that describes the curve and shows the rate at which the curve changes direction (accellerates/ crowns). Taking into account that there are a couple of people working on the 2014 NURBS GSOC project, that this may come in handy later. But it would also be nice for when you start lofting/ sweeping meshes with curves using Geometry Nodes.

Will do. Thanks a lot for all the help so far.

If/when snapping is implemented, we could move the current Ctrl behavior to a different key binding and use Ctrl for snapping. The only concern with this would be if a user had gotten used to the current Ctrl behavior already, but I don’t think it’s a big problem to get used to a different key binding.

Assuming you mean pressing the spacebar while dragging with left-click, I don’t believe it’s possible. I looked into this previously and I wasn’t able to find a way to do it in Blender. It may be possible with Sculpting because it works on the Sculpt mode and not the Edit mode (like the curve pen). But I’ll take a look at it. Could you point me to an example of how Sculpt mode uses it? I haven’t used sculpt mode much so I don’t think I’ve run into it. Trying it again, I wasn’t able to trigger it.

This actually used to be how it worked but turns out my last change had broken it. So, thanks for finding it. Will fix it.

When double-clicking, it always first triggers a single-click before triggering the double click. So you would have to have no functionality assigned to single-click on a curve meaning, with the current keybindings, you won’t be able to extrude to a point near a curve (which was a major complaint sometime back). I think it has too many downsides to it.

For A and B, as I mentioned previously, the tool isn’t implemented as a modal tool, so they aren’t possible. It’s the same case for D. As for C, it’s not possible to use 2 tools at the same time. Besides, I think the existing shortcuts for box select (B) and circle select (C) are quite convenient, and they should work within the tool as well.

I’m not entirely sure what you mean. Do you mean the handle type of the first point should change based on the types of the remaining points when the spline is closed?

I should also note that Toggle Vector and Close Handle Type may not always result in the most sensible result when used in a key binding with other functionalities. I’m considering moving them into a separate operator so that there’s no confusion.

As I mentioned earlier, that’s just not how Blender works. As I also mentioned previously, the reason why it works near the middle point is not because of the handle moving functionality but rather because of the segment moving functionality.

Yes. Simply enabling the Extrude Point option for Shift-Click in the preferences should do it. Let me know if that’s not the case or if that’s not what you meant.

Yes. It’s expected to extrude the selected endpoints by default.

Ah yes. That was intentional since it seemed easy to lose track of what functionalities were enabled and what was not. For example, if you had Lock Angle enabled and then you press shift to free handles, you wouldn’t be able to move the handles freely since the angle would still be locked. But I don’t have a strong opinion on this so please do tell me if the issue I mentioned is not a big concern.

Regarding keymap suggestions, I won’t be able to take them into consideration without there being a suggested keymap for each and every functionality since it’s quite difficult to avoid conflicts. This is why I decided to move all the functionalities to the preferences so that the user can customize them and simply disable the functionalities that are unused. But thanks for the suggestion. It’s good to see the variations of the options that are used.

Thank you!

There won’t be any conflicts with this since Left-Click or Drag followed by pressing Ctrl is detected differently compared to pressing Ctrl and then Left-Click. The snapping belongs to the first scenario while adding points (if the key-binding was changed) would belong to the second scenario.

Yes.
The main reason is that, unfortunately, a lot of this is easier said than done.
I’ve mentioned why 3 isn’t possible before so I won’t go into it again.
As I understand, 1, 2, and 4 are referring to practically the same thing. To my knowledge, there is no existing gizmo that would achieve this. So it’s more or less out of the context of this project (but I do understand its usefulness; hopefully we’d have something similar at some point in which case it could be added to the tool). Number 5, on the other hand, is likely doable but this may not be too urgent. If anything, I think snapping should be the next functionality to add but I think even this can wait till post-merge.

The other reason is that the main intention of the tool was to combine a set of existing functionalities with a few new functionalities. In all honesty, I’m not sure how much of the existing functionalities would survive the review process. Hopefully, all of them. But sometimes some of this may have to be dropped (with good reason).

Sorry, I had to say no to a lot of these, but I do sincerely appreciate the suggestions and the time you took to try out the tool and provide feedback. It’s just that some of these are not possible with Blender’s current code base and some of these are not too urgent. At the moment, I’m just looking to fix any bugs we find and make improvements to the existing functionalities where necessary. The sooner that’s done, the sooner we could restart the review process and hopefully get the tool merged. Hope you understand :slight_smile:

2 Likes

I completely understand that lots of the features I requested were outside of this project scope. For me it helps to think of how it should be in the ideal end-state and deduce what it would take to get there. I do think it is good to have these mentioned here now as future reference as well. So it is certainly not meant to criticise what you have achieved sofar!

In sculpt mode you can hold down Ctrl + Shift and then do an LMB drag to mask parts of the mesh with a lasso. The spacebar movement is under “Gesture Lasso: Move”, couldn’t pinpoint it exactly in the keymap (but it’s a modal).

There’s also one for Box select in Edit mode:

Oh yes, I see. Is there some place for you to log this issue? I had a regression earlier because of this: ⚓ T94465 Pick Shortest path interferes with Ring select - Regression and it would help resolve such conflicts.
Would be good to know if and when it gets resolved, so you could take advantage of it as well.

And pressing ‘C’ to close won’t be possible, you answered that already :wink:

I prefer to have the ‘builtin.select_box’ tool (since you don’t need to invoke this multiple times for adding/ removing to a selection). But I don’t want to be switching tools much either. :thinking:
Will have to make do for now, that’s a me problem.

Actually, I was wrong here. What I would expect is that if I close the curve, the vertex handle would be editable by click dragging upon closing. That way, I would be able to manually change the handles to fit the curve I need, whereas just clicking would leave the initial point as a vector. If the handle was not a vector to begin with, I would also need to be able to adjust the direction/ size anyways.

These are the scenarios:

  1. The end point is a vector, the rest of the curve has (a mixure of) align handles. If I click on the vector, it closes with the end point as vector. If I click drag on the end point, the curve is closed and the end point’s handle is converted to aligned handles, so I can drag them.
  2. The end point has aligned handles. I can click to close the curve or click drag and adjust the end point’s aligned handle in terms of direction and size.

Like having a separate operator for the double click to toggle, if I understand you correctly.

Yes, it is indeed. Works as I expected, great!

Note to self

I understand that much, pressing shift once on locked handles should indeed unlock them. I agree with you on that.
What I hope to see is that if I press shift for a second time, this unlocked state is reverted, which it does, but it does not link the handles back again.
The way I see this, accidental keypresses do sometimes occur and in that case I want to undo the accidental press by pressing shift once more. Furthermore, if I only wanted to change one handle, I would use the other modifier combination to modify just one part of the handle to begin with. To me that would make the tool more robust.

Thanks for taking my feedback into account!

Yes, I definitely agree.

I see. Unfortunately, both tools are modal like you mentioned. So not much we could do at the moment. But good to know it’s possible.

I might be wrong, but I don’t think there’s any way of knowing whether the first click is done with the intention of a double click or not. The only way (as I see), would be to wait for about 200-300 ms and see if a second click was made. But this would mean all single clicks would have a delay of 200-300 ms to be detected, which is very noticeable.

Makes sense. Not much I could do about it at the moment, unfortunately.

This was how it worked initially, but later there was a suggestion to close the spline on mouse release which would allow the user to move the endpoint without triggering it, so I changed it. Now that there are more workarounds for the issue, I think we could go back to that version. Will change it in the next build.

Yes. That’s right.

Ah, right. Makes sense. In the next build, Lock Angle would be triggered when held down rather than as a toggle. So the problem would only be with linking handles. I’ll add this suggestion to the next build as well.

Sorry, didn’t quite understand what you meant. What do you mean by “other modifier combination”?

Thanks!

What I meant is that if I want to change just one handle I would use Ctrl+Shift directly rather than hitting shift twice to unlink one handle. :wink:

1 Like

The new build should now be available at Blender Builds - blender.org.

Changes:

  • Preserve Link Handles state when switching to and from Free Toggle.
  • Added Close Spline Method option which can be one of None, On Press, and On Click. (Now there’s a checkbox for Close Spline in the header toolbar that can be checked or unchecked to activate or deactivate the default settings for Close SplinE which are defined by the Close Spline Method)
    • None: Functionality turned off
    • On Press: Gives the ability to drag to move the handle after closing the spline
    • On Click: Dragging would cancel the close spline behavior and instead move the endpoint.
  • Added support for moving adjacent handles on either side of an internal point (for Move Adjacent Handle).
  • Lock Angle is now activated on hold rather than as a toggle.
  • Fixed bug where handles of points that are just inserted into a segment cannot be controlled.
  • Improved the insert point algorithm for much better accuracy.

Let me know if any bugs are encountered. Thanks!

1 Like

hmm I don’t see this option in the last build


blender-3.2.0-alpha+soc-2021-curves.b300a334115a-windows.amd64-release

other than than did not discover any new bugs and still works very nicely

one more suggestion would be to add hints (all the modifiers) in to info bar down same as there are for other tools like grab

3 Likes

Ah, my bad. Turns out the change hadn’t been committed when I created the build. Thanks for pointing it out and for testing the tool again.

Thanks for the suggestion. I looked into this some time back but it seemed only possible for modal tools. I’m not entirely sure if this is the case, so I’ll give it another try. But I wouldn’t get my hopes too high.

The vertex slide modal is shown in the top header. I’m saying this because there may be a second method that might be worth trying. :wink:

Sorry, I’m not sure how this might help with the “hints” at the bottom bar. Could you elaborate a bit more?

Maybe the vertex slide modal uses a different method for showing ‘hints’ that you would be able to use, whereas the regular modal hints may not work (at least last time you tried). So what I am pointing at is that if you can’t get the hints to show in the bottom bar, maybe you can use the hints method in the vertex slide modal.
afbeelding

Other than the missing option, everything looks good to me. I think it can be submitted for review at this point.
btw what is the situation with curve fillet tool? Do you still plan to add it for curve edit mode?

@Hologram Those tooltips are for modal tools so I don’t think they can be added to a live tool.

Yeah, that seems to be the case.

Thanks. I’ll clean up the code a bit and post the changes for review today.

TBH, I’ve not been in touch with the Blender devs for a while so I’m not sure about its status. I believe it was dependent on a separate implementation that allows the same code to be used by both the regular tools and by the geometry nodes. If/when that implementation is done, we could port the curve fillet to the regular tools.

6 Likes

why i build no longer in experimental buids ?

how hard would be to implement this ?
it would optimize the curve resolution adding segments only when needed to keep its smoothness

2 Likes

Sorry, I didn’t receive your notification for some reason. The new builds replace the old ones at the top of the list in experimental builds. The old ones should still be there if you go to “All Archived Builds” (Blender Builds - blender.org).

I tried creating a new build recently but there seems to have been a permissions change, so I wasn’t able to create it. Didn’t get a chance to fix the issue. Will look into it next week.

Sorry for the delay in response @Kranos. I didn’t receive the notification for this one either.

This is actually one of the first things I looked into, but after some discussion, it was decided to not have this as a part of the proposal. The main reason for that was that, as it is implemented now, all segments of a curve would have the same resolution. However, all efficient algorithms that I came across relied on changeable, segment-specific resolutions. It is possible to implement an algorithm where the overall resolution remains constant while the local resolution is adjusted according to the tangent angle. However, from what I found, the solution would have to be iterative, and somewhat computationally inefficient. Another reason to add to the main reason was that there was some discussion at the time of having a segment-specific resolution. So, it was suggested to pursue this issue after that’s ready. However, I’m not aware of the current state of that task.
I think it would make sense that there is a non-iterative solution to the issue, and it’s possible that I missed something. It could be worth looking at for any potential candidates for GSoC 2022, but keep in mind that it could also be a dead-end with the current implementation of curves.

2 Likes

Hi everyone! The patch is quite close to being ready. The next step would be to create an icon. Let me know if anyone is interested to make it. Thanks! :slight_smile:

13 Likes

Awesome! Heck yeah I’m open to designing an icon for it. I need to go back and read about the features introduced and test it out first. Lol :wink:

2 Likes

Thanks a lot for the offer (and the enthusiasm :wink: )! I received a design suggestion a bit earlier today which I’m quite happy with, but I’m yet to confirm it with Hans (my mentor):
image

If creating a design might take up a lot of time, could you kindly hold your offer until I receive confirmation? I wouldn’t want you to spend too much time in case the above design gets confirmed. Hope you understand, and thanks again for the offer! I really appreciate it.

8 Likes