I had a follow-up question about this bug. I saw that it was noted that the current fix only works for translation, not rotation or scale, but then the thread was closed. Multiframe editing falloff still doesn’t work for rotation or scale in Edit mode, both in 4.3.1’s stable release and the most current 4.3.2 candidate (pushed Dec 14). Is this still being worked on? I have a hard time parsing the thread structure of the issues forum.
It feels like a minor thing, but multiframe falloff rotation is sort of the only way to compensate for frame interpolation’s difficulty with rotating shapes.
If you’re talking about the fill bucket tool then it does take fills into account. I’m guessing that the issue you’re running into is that fills can’t have holes, which is just a limitation at the moment.
If you’re talking about something else, it might be a bug. Would have to see a concrete example.
Here’s two shapes with identical strokes Both are on the same layer. On the left - with stroke material, on the right - with fill material.
Using Fill Tool or Inverted Fill tool will fill only the left one.
As a storyboard artist my drawings are pretty loose. With old GP when inverted fill tool failed once, I could just click a few times to fill over the strokes that had been created at first fill. Or I could manually fill some gaps with SHIFT+fill tool to guide Inverted Fill.
But now that’s just impossible. I have to spend a lot more time to control gaps with line-material strokes only… That’s kinda sad.
I’m still not super well-versed in the process/terminology here, is there a difference between a commit and a fix that’s been pushed? Multiframe falloff still isn’t working in edit mode for rotation or scale in 4.3.2, but it was listed as a commit in the module meeting notes.
Sorry if I’m turning into a hassle. I’m trying to keep up with this information on my own but like I said, I’m having difficulty understanding what I’m looking at.
Am I missing a step or is drawing on surfaces just not working at the moment. Whenever I chose surface as stroke placement option, it seems that the viewport camera itself is chosen as the object. So all I can draw is a black dot somewhere in space, when I zoom further back I can see that dot. When I change drawing distance to something like a meter I have a stroke set back 1meter behind the camera at the time of drawing. It’s very odd
Did you test this on the latest 4.4 Alpha ? I remember that there was a regression but that should have been fixed by now. Otherwise, please create a bug report.
Some thoughts about sculpt mode. I always try to speed up my workflow. For storyboarding I am mostly in drawing and tweaking my drawings in sculpt mode, I don’t polish much so I don’t use Edit Mode a lot. But what I’ve noticed, that sometimes to tweak part of my drawing I need to go into Edit Mode just to Translate, Rotate or Scale. And it’s kinda annoying - because you draw - go to sculpt to tweak part - go to edit just to transform - go to sculpt to tweak more - go to edit to transform more - sculpt tweak - go to draw…
I’ve made modal ops for transforms in sculpt mode which are laggy, but I’ve found it very usefull.
My question - are there any plans to incorporate transform tools into Sculpt Mode or/and Draw Mode? We have native transform tools in Mesh Sculpt for example that are pretty handy. So it’s not only a feature request but a matter of consistency.
Now that I’m at the other side of Christmas I finally got the chance to check this in the daily alpha. Multiframe falloff seems to be back to its old self again (Thank you!), but I bumbled onto something new. It looks like GP objects turn invisible when their Viewport Display is set to “In Front.” For reference, this is from the 4.4.0 Alpha from Dec. 26th.
Draw a stroke, go to edit mode and select the stroke, switch to point select mode to show all points are selected. Press CTRL - to select less points. Nothing happens.
Expected behavior: The first and last points on the stroke are deselected like in v4.2.
Sculpt mode “Push brush” has been renamed to “Pull”? The brush really pushes points around depending on the falloff. I visualize it as a snow plow. Snow plows do not pull snow, rather it pushes it as the plow moves forward. The Grab brush behaves more like Pull. Not sure why it was renamed. Also there are 2 essential Pull brushes. Perhaps there was Pull and and Push brushes intended?
Recently it was decided that locked layers should mean “locked” (nothing in , nothing out , no changes.)
So i just think this same logic should be applied to Materials.
Here’s a video to show what i mean.
When i weight paint the sneakers i had the materials for each element locked, But the weight painting still effects it. It shouldn’t be able to paint anything onto those locked Materials and should just go ahead and paint the weight onto the unlocked ones.
This would make weight painting on complex gp objects like this much easier.
In edit mode with 1 stroke in scene and a few points selected in the view, the following shows ALL points as selected (select=True). In v4.3.2 the code shows the correct selection state of the points.
gp = C.active_object
f = gp.data.layers.active.current_frame()
for p in f.drawing.strokes[0].points: print(p.select)
What is the “correct” way to determine if a point is selected on a stroke?
Thanks everybody for the feedback that was provided during the development of Grease Pencil v3.
Since 4.3 is now out, this project is complete and further bug fixing becomes part of regular module work. If you find issues in 4.4 and onward, please report them as bugs and we’ll address them.
We will create new feedback threads for specific upcoming projects. This thread is going to be closed.
