Cycles renders only first duplivert when mesh has generative modifier #60735

New Issue

ChameleonScales · 2019-01-22T05:00:57+01:00

ChameleonScales commented

2019-01-22 05:00:57 +01:00

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: e57ee5934a
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

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

ChameleonScales commented

2019-01-22 05:00:57 +01:00

Added subscriber: @ChameleonScales

blender-admin commented

2019-01-22 05:00:57 +01:00

#62568 was marked as duplicate of this issue

blender-admin commented

2019-01-22 05:00:57 +01:00

#61547 was marked as duplicate of this issue

blender-admin commented

2019-01-22 05:00:57 +01:00

#59837 was marked as duplicate of this issue

Philipp Oeser commented

2019-01-22 11:42:00 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2019-01-22 11:42:00 +01:00

Confirmed, checking...

Brecht Van Lommel self-assigned this 2019-01-22 12:09:02 +01:00

Jason Clarke commented

2019-01-23 20:06:09 +01:00

Added subscriber: @JasonClarke

Brecht Van Lommel commented

2019-01-28 19:27:57 +01:00

Added subscribers: @finnb, @brecht

Brecht Van Lommel commented

2019-02-01 20:09:54 +01:00

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.

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 commented

2019-02-14 20:14:19 +01:00

Added subscriber: @yohoo

Brecht Van Lommel commented

2019-03-14 13:02:47 +01:00

Added subscriber: @DenisBelov

Brecht Van Lommel commented

2019-03-27 16:31:24 +01:00

Added subscribers: @mont29, @Sergey

Brecht Van Lommel commented

2019-03-27 16:31:24 +01:00

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 or @mont29, any ideas?

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 or @mont29, any ideas?

Sergey Sharybin commented

2019-03-28 11:12:54 +01:00

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

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

Bastien Montagne commented

2019-03-28 11:37:14 +01:00

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

blender-admin commented

2019-03-28 14:44:12 +01:00

This issue was referenced by 0680525147

This issue was referenced by 06805251478c53a262bc1fe9a7224d1f1b5bf449

Brecht Van Lommel commented

2019-03-28 20:05:11 +01:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2019-03-28 20:05:11 +01: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

Cycles renders only first duplivert when mesh has generative modifier #60735