Page MenuHome

crash when viewport rendering point density texture
Closed, ResolvedPublic


System Information
Windows 10 x64, GTX 1070

Blender Version
Broken: 2.78a (e8299c8), also tested daily build bd8cbf5
Worked: (optional)

Short description of error
When using a point density texture node in a cycles material, blender crashes after changing the resolution value.

Exact steps for others to reproduce the error

  • Render engine: Cycles (GPU or CPU rendering)
  • any material (must be visible in the 3d viewport, i. e. not on a hidden layer), use nodes
  • add a texture->point density node (node editor or properties panel). It must affect the material (e. g. color input of default diffuse).
  • switch 3d viewport to rendered mode
  • change the "Resolution" value of the node. Blender crashes.

Bug seems to appear only when changing the value immediately after switching to rendered viewport and changing the "Resolution" value with click-and-drag (not clicking or typing in directly)

Event Timeline

newbs added a subscriber: newbs.Nov 27 2016, 3:13 PM

Joel Meyer, Can you upload a blend file please? Thank you.

This one was easy to repro,

just switch to rendered view, and click the up or down button on the resolution a few times (doesn't happen all the time but after a few tries blender crashes) probably a race condition somewhere.

race condition, in between the time ImageManager allocates ram for the texture and the time it gets sampled the ui managed to get in a change to the resolution. causing things to overflow in point_density_sample_func. Not quite sure how to stop that from happening. @Sergey Sharybin (sergey) any hints/tips?

Not sure what would be best here, can in theory use similar technique as initial sync is doing: have a main thread locked while sampling point density (see WM_job_main_thread_lock_acquire). This is annoying tho, because it introduces interface locks which we hate and must avoid.

Probably better approach for until we've got proper data separation would be to re-set viewport render from RNA update callback for PD resolution. We had that for some properties already (can't find them atm tho). Nice point of research is ED_render_engine_area_exit() and see it's users and such.

Ideally i'd like to extend builtin_image_float_pixels_cb and builtin_image_pixels_cb to include the buffer dimensions (passing a pointer to a buffer, without telling the callee what size it is, just seems bad faith to me, and inviting issues like these) however that in turn causes a change to rna_ShaderNodePointDensity_density_calc (to include the buffer dimensions there as well) but that might be a breaking api change, not sure if that's ok? (doesn't look like any python is calling it though, so it just be a c/c++ code change)

Not sure that will solve anything. You can still change PD settings while builtin_image_float_pixels_cb() is sampling the PD causing threading conflicts.

It would, BlenderSession::builtin_image_info would query the PD settings once, to get the resolution, and beyond that the buffer dimensions would be passed down, so there's no need for rna_ShaderNodePointDensity_density_calc to query the PD Settings and get a potentially different answer.