HI, I noticed some changes in stroke behavior, in the last 2.92 the stroke is perfectly smooth for large and quick stroke but you have to wait a while to see the result on the object you are painting, this is an appreciable improvement but still to slow (a stroke take about 30 seconds to be displayed on a single 2 millions polys sphere with a single 8k texture and with a brush of less than 10% the diameter of the sphere that are totally displayed on the viewport) . This is not usable for terrain or other relatively heavy meshes (2 millions is not really an heavy mesh now), zooming in the object allow to recover correct reactivity but not a true solution. All these was done with an rtx2080 ti and a i7 10700, not really a weak PC. I hope improvement are planned on painting module, this one seems to be a bit abandoned at this time ....

Hi, I confirm that enabling developer extra 'sculpt vertex color' seems to break the vertex color display in object mode (flat mode), disabling the extra features fixes the problem.

sorry my last message is not very clear, now the issue with the pen and the walking mode seems to be solved in the last 2.92 release (2.92.0 Alpha, branch: master, commit date: 2020-12-20 17:48, hash: rBd283a093d664). Just on thing, when the pen comes close to the edge of the tablet and that you have to recenter it, it should be possible to resume the walk from the last position. Actually the orientation change brutally and unpredictably when repositioning the pen on the tablet (same behavior when repositioning the mouse).

Concerning the lags, it seems that all work normally for me since the two or three last 2.92 releases, I don't see the problem on the same heavy scene. I can't say for the pen pressure as I don't really use it, but the walk is still present. Thanks.

great!, as you are working on this problem you may be able to make Blender able to forget the pen position when this one is leaving the tablet surface's in order to continue to 'walk' normally (for exemple when the pen arrives to close to the tablet border as you would do with your mouse in any application when it comes to close to the edge of your desk lifting it and replacing it in a better position) ;-).

Hi, same (or related issue here) : view rotation using tablet freezes a while every minutes (variable), a mouse click or a selection can restore the rotation until the next freeze. Also walking (with gravity) using stylet is impossible (to sensitive, a very small movement and you turn like a spinning top). Pressure seems to work correctly for me.
Thanks

not exactly, not easy to show with video, first I translate a camera with the transform tool, this can be undone normally with ctrl Z, in the second time I am moving a camera through the view (locked camera), the lower part of the viewport shows that camera is moving but these movement can't be undone with ctrl-Z, I don't understand why, because the camera is moving like if it was a transform movement but apparently for Blender it is not the same thing.

Robert,
please, could you give me more information about the setup with which you could not recreate the issue?
Thanks.

Hello, sorry but I confirm my first observation, I tested again with 2.90.1 and the 2.91 and 2.92 last release, the brush is hugely more reactive with Blender 2.90.1.
My config :
windows 10, Intel HD630 (driver 27.20.100.8190)
I tested also with a geforce 2080 rtx (on windows 10 ), in this case the difference is not visible, but not everyone has such a card ....
Thanks.

Hi, is there a chance to see this problem corrected in the 2.91 version? thanks.

yes, I understand that, but the slowdown is huge in 2.91 compared to the current version, something else is happening.
rq : Painting with hight zoom (only some pixels in the brush) is also very slow when using 8k (and more) texture.
.

The issue seem to be linked to the image size, a 1k image can be painted with an good fluidity, but the fluidity starts to drop as the texture size increase to be very slow at 8k.
The zoom factor has also a big action on the painting behavior as the apparent brush size increase the painting become slower until in extreme case freezing Blender during some seconds.

you can see the issue in this file :

I think no, it seems different, it appears only in 2.91 (since some releases but not in 2.90) and the issue appears both in solid or shaded display mode (not only in shaded mode as it seems to be the case in the T79370 report.
The video was done with the today 2.91 release.

Hi, seems to be fixed, thanks.

ok, after some tests (2.91 version) it appears that the issue occurs when one of the following tab is used (converted with the object interaction mode selection menu) for painting : layout, modeling, shading. With the native painting tab and other tabs (when painting mode is selectable) there is no problem apparently.

I just find that the issue occurs when the stroke is slow, a quick stroke is ok but not really usable of course (no control and no smoothed curve but this is another problem I think ...)

it happens both with mouse and tablet, not in 2.83 but in the last 2.9 version (a mouse was used for these video)

Hi,
definitively we appreciate dyntopo and as a lot of people said, it is an heavily used tool without equivalent. Making it deprecated would be an error. Of course some improvement could be done, one of them
could be the UV preservation, this is perfectly possible as this feature is already implemented in the last Mudbox release, and could make dyntopo even more attractive.
I hope that our voices will be heard and the dyntopo development will know a second life with exiting new features.

Hello, my last tests seem to show that the issue is fixed, thank you very much.
There is another little issue related to the texture panting, but I do not know if I have to begin another thread.
It concerns the lag observed in the beginning on the first painting action (it disappear further in the same stroke and reappear when you begin a new one) , this lag (a portion of second) prevents painting by little and quick brush strokes like in a real painting (I can try to post a video to show the phenomenon). This is less pronounced using a very fast graphic card but it never disappear completely, may be there is something to do with that in order to have a very pleasant painting feeling.
Thank you again for your work, have a pleasant journey
.

Hi, no body want to work on this issue? it's a shame, it's still quite critical as a bug.

Hi, I saw for the tag, I changed it, I hope it is ok (I am not so familiar with the site yet).
Thanks.
Pascal

Hi,
thank you for the answer, sorry for the bad tag, no this issue is not related to an add-on (
To reproduce the problem, simply create a sphere for example, split its UV to produce islands, pack them, subdivide the sphere to get more than 4 millions triangles and begin to paint ... you should see the bleed problem (use contrasty colors for base and painting), if you look at the uv island limits in uv editor you should see that bleeding dos not work. You can also try with the attached file, it use a modifier to be lighter but the problem is visible.
Thanks.
Pascal