metaballs converted to meshes appear to render at an incorrect isosurface #65996

New Issue

Garry R. Osgood · 2019-06-21T12:48:10+02:00

Garry R. Osgood commented

2019-06-21 12:48:10 +02:00

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: 197661c733, type: Release
Worked: 2.80 (sub 74), branch: master, commit date: 2019-06-02 21:33, hash: 19dcb22a88, 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

Open attached blend file metaball_2_2.80.blend
Find that the viewport is in object mode.
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.
Convert to mesh (Object --> Convert to)
Observe that the isosurface converted to a mesh appears to be different, corresponding to one of a larger stiffness.
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)
Note that the description in terms of stiffness levels is for illustration only. I have not confirmed an actual change in stiffness level.
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.
metaball_2_280.blend
metaball_2_279.blend
gosgood-system-info.txt

**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** - Open attached blend file **metaball_2_2.80.blend** - Find that the viewport is in object mode. - 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. - Convert to mesh (Object --> Convert to) - Observe that the isosurface converted to a mesh appears to be different, corresponding to one of a larger stiffness. - 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) - Note that the description in terms of stiffness levels is for illustration only. I have not confirmed an actual change in stiffness level. - 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. [metaball_2_280.blend](https://archive.blender.org/developer/F7430161/metaball_2_280.blend) [metaball_2_279.blend](https://archive.blender.org/developer/F7430276/metaball_2_279.blend) [gosgood-system-info.txt](https://archive.blender.org/developer/F7430297/gosgood-system-info.txt) ![metaball_279_before_tomesh.png](https://archive.blender.org/developer/F7430302/metaball_279_before_tomesh.png) ![metaball_279_after_tomesh.png](https://archive.blender.org/developer/F7430311/metaball_279_after_tomesh.png) ![metaball_280_before_tomesh.png](https://archive.blender.org/developer/F7430315/metaball_280_before_tomesh.png) ![metaball_280_after_tomesh.png](https://archive.blender.org/developer/F7430319/metaball_280_after_tomesh.png)

Garry R. Osgood commented

2019-06-21 12:48:10 +02:00

Added subscriber: @grosgood

Philipp Oeser commented

2019-06-21 13:15:52 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2019-06-21 13:15:52 +02:00

Confirmed, checking...

Philipp Oeser commented

2019-06-21 14:59:53 +02:00

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...

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...

Garry R. Osgood commented

2019-06-21 15:08:22 +02:00

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.

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.

Bastien Montagne was assigned by Philipp Oeser

2019-06-21 18:32:15 +02:00

Philipp Oeser commented

2019-06-21 18:32:15 +02:00

Added subscriber: @mont29

Philipp Oeser commented

2019-06-21 18:32:15 +02:00

This is actually caused by 8aa87972ca
(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 [ https:*developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/scene.c$1100 | 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...

@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?

This is actually caused by 8aa87972ca (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 [[ https:*developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/scene.c$1100 | here ](https:*developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/mball_tessellate.c$1202), 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... @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?

blender-admin commented

2019-06-24 20:40:56 +02:00

This issue was referenced by c0c1b4542f

This issue was referenced by c0c1b4542f391fbec18b7168d2d845212fb44ac3

Bastien Montagne commented

2019-06-24 20:46:41 +02:00

Changed status from 'Open' to: 'Resolved'

Bastien Montagne closed this issue

2019-06-24 20:46:41 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

metaballs converted to meshes appear to render at an incorrect isosurface #65996