Page MenuHome

metaballs converted to meshes appear to render at an incorrect isosurface
Closed, ResolvedPublic

Description

System Information
Operating system: Linux bertha 5.1.0-gentoo-bertha #1 SMP Sat May 11 18:27:21 EDT 2019 x86_64 Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz GenuineIntel GNU/Linux

Graphics card: Radeon Pro WX 9100 (VEGA10, DRM 3.30.0, 5.1.0-gentoo-bertha, LLVM 6.0.1)

Blender Version
Broken: 2.80 (sub 74), branch: master, commit date: 2019-06-20 22:36, hash: 197661c7334d, type: Release
Worked: 2.80 (sub 74), branch: master, commit date: 2019-06-02 21:33, hash: 19dcb22a885d, type: Release
Worked: 2.79b

Short description of error
When converting metaballs of any type to a mesh, the conversion seems to choose the wrong isosurface. For example, isosurfaces corresponding to a stiffness of approximatly 0.6 are rendered as if they are approximately stiffness 1.8 - 2.0 isosurfaces.

Exact steps for others to reproduce the error

  1. Open attached blend file metaball_2_2.80.blend
  2. Find that the viewport is in object mode.
  3. Find that one object, MBall is selected. (a) The metaball has four radiating points, arranged in a square (b) For purposes of illustration, the Viewport and Rendering resolutions have been set to 0.05 (c) The stiffness of each radiating point is 0.630, creating a surface which looks like an open square.
  4. Convert to mesh (Object --> Convert to)
  5. Observe that the isosurface converted to a mesh appears to be different, corresponding to one of a larger stiffness.
  6. The phenomenon can be seen at all various stiffness levels, but is most apparent at stiffness levels approximately equal to the object Influence Threshold (0.6)
  7. Note that the description in terms of stiffness levels is for illustration only. I have not confirmed an actual change in stiffness level.
  8. For comparison, metaball_2_2.79b.blend opened in blender version 2.79b converts to a mesh with no discernable changes in isosurface. Similarly for the June 02 version of 2.80.







Event Timeline

Philipp Oeser (lichtwerk) lowered the priority of this task from 90 to 50.Jun 21 2019, 1:15 PM

Confirmed, checking...

first note: changing MBall threshold goes into polygonize(&process); once [via depsgraph]

conversion to mesh goes there multiple times (suspicious?):

  • via depsgraph
  • via depsgraph again [and now process->totelem changed from 4 to 8 and also process->bvh_queue_size changed...]
  • via operator [with aboved changed values...]

needs some more investigation...

Ah...!
A total element count change from 4 to 8 is interesting, for if there is now two radiating points where there were just one before, the isosurface would reflect the resulting change in field strength, which, methinks, we are seeing.
Pity I'm in my office and need to do paywork. Be nice to drop a watchpoint on totelem field and find out where it flips.
Thank you for checking.

This is actually caused by rB8aa87972cac3
(this is why code reaches polygonize(&process) multiple times as mentioned in above comment)

I first assumed there was something wrong with BKE_scene_base_iter_next (called here -- we are getting multiple objects back) or it would just wrong that (*base)->next is not NULL here, but it turns out that above commit causes the depsgraph to be updated and so new objects end up in the depsgrah --> thus BKE_scene_base_iter_next picks them up...

@Bastien Montagne (mont29): not sure what the best way would be to prevent that? Or how we could could tell them apart in BKE_scene_base_iter_next? (otherwise process->totelem will falsely grow, see above comment)
I guess, you'll get there quicker, mind checking?