Page MenuHome

Cycles renders only first duplivert when mesh has generative modifier
Closed, ResolvedPublic

Description

System Information
Operating system: Linux Mint 19.0 x64
Graphics card: Nvidia GeForce 820M

Blender Version
Broken: 2.8 Date: 2019-01-16 21:59 Hash: e57ee5934a30
Worked: 2.79b

Short description of error
When rendering a mesh with dupliverts with Cycles, if that mesh has a modifier from the "Generate" column, only one instance will be rendered.
Exceptions: Bevel, Boolean, Decimate, Edge split, Skin, Triangulate, Wireframe
Note: This bug also happens in the Cycles viewport and when it does, for some reason the progressive sampling refreshes constantly as if something was being edited.
Other note: This bug doesn't happen with duplifaces

Exact steps for others to reproduce the error
From start:

  • Keep cube
  • add another one
  • scale this one down
  • parent it to the big one
  • enable dupliverts on the big one
  • add a subdivision modifier (or any other that is not in the exceptions) to the big one
  • render with Cycles

Only one instance gets rendered

Event Timeline

Caetano (Caetano) updated the task description. (Show Details)
Caetano (Caetano) edited projects, added BF Blender: 2.8, Cycles; removed BF Blender.
Caetano (Caetano) updated the task description. (Show Details)
Philipp Oeser (lichtwerk) lowered the priority of this task from Needs Triage by Developer to Confirmed, Medium.Jan 22 2019, 11:42 AM

Confirmed, checking...

The problem is that meshes sometimes have a CD_ORIGINDEX layer that is not filled in. Need some time to figure out when it should be created now in the new code.

Brecht Van Lommel (brecht) raised the priority of this task from Confirmed, Medium to Confirmed, High.Mar 18 2019, 4:14 PM

In 2.7, CDDM_from_template, cddm_copy and maybe more functions would create CD_ORIGINDEX on the original derivedmesh. This makes things work mostly automatic without modifiers having to do anything.

In 2.8 we are no longer doing this, and we probably shouldn't because the input is now the actual original mesh instead of a derivedmesh. I can think of 3 solutions:
a) Let modifiers initialize original indices manually
b) Make a shallow copy of the mesh that can have its customdata modifier like derivedmesh used to
c) Add special handling of CD_ORIGINDEX instead CustomData_copy so copies the element index

@Sergey Sharybin (sergey) or @Bastien Montagne (mont29), any ideas?

@Brecht Van Lommel (brecht), think creating a shallow copy is the cleanest and the most isolated solution: only needs to be done in a single place of modifier stack evaluation.

Let modifiers initialize original indices manually

This would make modifiers implementation more verbose and more prone to errors.

Add special handling of CD_ORIGINDEX instead CustomData_copy so copies the element index

That *could* work, but kind of introduces extra special handling, making it even further unclear what is to be used where.

Make a shallow copy of the mesh that can have its customdata modifier like derivedmesh used to

The only downside here i can think of is an extra allocation/pointers assignment. I am not convinced that this will show up in the profiled any time soon. And i don't want to make things more complicated/unclear just to gain unmeasurable speedup in the real world usecase.

Not saying that optimization can not happen later. But for now i think we really want something simple, reliable, and error-proof.

Agree with @Sergey Sharybin (sergey), overhead should be neglectable, and this is by far the simplest and safest solution.