Page MenuHome

dyntopo mode sculpt use node texture Brush will produce noise
Open, Confirmed, MediumPublic

Description

System Information
Operating system: Darwin-18.6.0-x86_64-i386-64bit 64 Bits
Graphics card: Intel(R) HD Graphics 530 Intel Inc. 4.1 INTEL-12.9.22

Blender Version
Broken: version: 2.80 (sub 74), branch: master, commit date: 2019-06-01 22:51, hash: rB079c7f918c81
Worked: (optional)

Short description of error
[Please fill out a short description of the error here]
use node texture brush in sculpt mode with dyntopo on


some not wanted noise will draw on mesh

Exact steps for others to reproduce the error
use basic node texture setup
and dyntopo sculpt on ,detail size small to 1px or 3px

this problem not only on macOS,also on windows or other system will appear.

Details

Type
Bug

Event Timeline

xueke pei (yuzukyo) updated the task description. (Show Details)
matc (matc) triaged this task as Needs Information from User priority.

I couldn't reproduce this problem. Can you upload a .blend file?


here‘s the file
the detail size needs to 0.5px will appear this noise.
the file are big enough only add one stroke on mesh.

matc (matc) raised the priority of this task from Needs Information from User to Confirmed, Medium.

Now I'm able to reproduce.

The problem is bound to the use of a Node Texture Setup set as the texture of a brush. The problem manifest in single vertices that are shifted along one axis independent of viewing angle. These shifts happen on both sides of the mirror, but in independent locations.

The selected vertices are the problem. To me it looks like those vertices were not affected by the texture.

The problem does not exist for the "Area Plane" mapping.

The problem does not exist if the Mesh already has a denser topology than what dyntopo would generate.

Turning the option Threaded Sculpt off, makes the problem disappear completely.

I created a smaller file with dyntopo detail size set to 2.0 (less cpu usage). Two single clicks on the mesh should make the problem visible. Switching between workspaces will deactivate dyntopo.

This problem is not limited to Dyntopo, any mesh with high enough density will show some defects. The problem seems to originate from node texture. I was able to somewhat isolate this particular problem.

I just picked a random lock to test things, the use of LOCK_NODES should not be relevant.

diff --git a/source/blender/nodes/texture/nodes/node_texture_output.c b/source/blender/nodes/texture/nodes/node_texture_output.c
index cdacb05153d..98dd43c6196 100644
--- a/source/blender/nodes/texture/nodes/node_texture_output.c
+++ b/source/blender/nodes/texture/nodes/node_texture_output.c
@@ -60,7 +60,9 @@ static void exec(void *data,
       TexParams params;
       params_from_cdata(&params, cdata);

+      BLI_thread_lock(LOCK_NODES);
       tex_input_rgba(&target->tr, in[0], &params, cdata->thread);
+      BLI_thread_unlock(LOCK_NODES);

       target->tin = (target->tr + target->tg + target->tb) / 3.0f;
       target->talpha = true;

Call stack:

>	blender.exe!exec(void * data, int UNUSED_thread, bNode * node, bNodeExecData * execdata, bNodeStack * * in, bNodeStack * * UNUSED_out) Line 64	C
 	blender.exe!ntreeExecThreadNodes(bNodeTreeExec * exec, bNodeThreadStack * nts, void * callerdata, int thread) Line 332	C
 	blender.exe!ntreeTexExecTree(bNodeTree * nodes, TexResult * texres, float * co, float * dxt, float * dyt, int osatex, const short thread, Tex * UNUSED_tex, short which_output, int cfra, int preview, MTex * mtex) Line 322	C
 	blender.exe!multitex(Tex * tex, float * texvec, float * dxt, float * dyt, int osatex, TexResult * texres, const short thread, const short which_output, ImagePool * pool, const bool skip_load_image, const bool texnode_preview, const bool use_nodes) Line 1175	C
 	blender.exe!externtex(const MTex * mtex, const float * vec, float * tin, float * tr, float * tg, float * tb, float * ta, const int thread, ImagePool * pool, const bool skip_load_image, const bool texnode_preview) Line 1776	C
 	blender.exe!BKE_brush_sample_tex_3d(const Scene * scene, const Brush * br, const float * point, float * rgba, const int thread, ImagePool * pool) Line 1039	C
 	blender.exe!tex_strength(SculptSession * ss, const Brush * br, const float * brush_point, const float len, const short * vno, const float * fno, const float mask, const int thread_id) Line 1259	C
 	blender.exe!do_draw_brush_task_cb_ex(void * userdata, const int n, const ParallelRangeTLS * tls) Line 2275	C
 	blender.exe!parallel_range_func(TaskPool * pool, void * userdata_chunk, int thread_id) Line 1080	C
 	blender.exe!task_scheduler_thread_run(void * thread_p) Line 451	C
 	[External Code]	
 	blender.exe!invoke_thread_procedure(unsigned int(*)(void *) procedure, void * const context) Line 92	C++
 	blender.exe!thread_start<unsigned int (__cdecl*)(void * __ptr64)>(void * const parameter) Line 115	C++
 	[External Code]

This problem is not limited to Dyntopo, any mesh with high enough density will show some defects. The problem seems to originate from node texture. I was able to somewhat isolate this particular problem.
I just picked a random lock to test things, the use of LOCK_NODES should not be relevant.

Did this means texture node's threads works not safe? it's interfere each other when export rgb texture color?

thanks this patch,I will test it with other users.

diff --git a/source/blender/nodes/texture/nodes/node_texture_output.c b/source/blender/nodes/texture/nodes/node_texture_output.c
index cdacb05153d..98dd43c6196 100644
--- a/source/blender/nodes/texture/nodes/node_texture_output.c
+++ b/source/blender/nodes/texture/nodes/node_texture_output.c
@@ -60,7 +60,9 @@ static void exec(void *data,
       TexParams params;
       params_from_cdata(&params, cdata);
+      BLI_thread_lock(LOCK_NODES);
       tex_input_rgba(&target->tr, in[0], &params, cdata->thread);
+      BLI_thread_unlock(LOCK_NODES);

I test this method, it will slow down the draw processing on mesh, but no more artifacts.