4
$\begingroup$

I've got a setup for cell-division (biological) that works really well in the viewport using cycles but when I render it using F12/ Ctrl + F12, some frames (repeatable) become heavily corrupted.

Render in viewport compared to simply rendered

Blender file Cell-division

Render frame 95 as an example (there will be other corrupt frames too) and see the difference.

I need the initial cell and subsequent two cells to wobble about and I need both cells to be separately surfaced after the division (which is included in the current blend file).

I can't use metaballs as they are not nearly flexible enough. I've also tried a different method using join mesh > mesh to volume > volume to mesh but that gave similarly corrupt results.

It feels so close, yet so far, so thought I'd see if anyone can figure out why it's failing and hopefully how to fix it. Or is this s bug that I should report?

$\endgroup$

2 Answers 2

3
$\begingroup$

Not sure why but something about the combination of the Remesh Modifier and the Subdivision is breaking things in render.

Maybe it is a bug, because viewport preview and EEVEE seem unaffected.

Either way to solve it you need to make the parameter Adaptivity in the Remesh Modifier non zero. Setting it to $0.01m$ fixed it for frame 95 at least.

enter image description here

$\endgroup$
3
  • $\begingroup$ Fixes it for frame 95 but does not remove the issue - render frame 5 and 9 with adaptivity set to 0.01 and you'll find the corruption again. $\endgroup$
    – David M
    Dec 1, 2022 at 16:52
  • $\begingroup$ Strange. This should probably be reported as a bug. For bug reports please see Where to Report a Bug $\endgroup$ Dec 1, 2022 at 16:53
  • $\begingroup$ The error appears related to motion blur - If you turn motion blur off the issue disappears. I'll report as a bug and remove this question in a few days. $\endgroup$
    – David M
    Dec 2, 2022 at 11:10
0
$\begingroup$

This visual aberration is a side-effect of the way motion blur is calculated in Blender which relies on vertex positions from frame to frame. In this setup the vertices are dynamically calculated on a per frame basis due to the remesh modifier, with the number and vertex IDs being unstable (changing frame to frame). This means that Blender cannot detect how each vertex has moved which leads to the aberration you see.

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .