Page MenuHome

New duplication system falls short of a mechanism to hide to be duplicated objects
Closed, ResolvedPublic


Blender Version
Broken: c7c070c2ece0f4
Worked: 2.79a

Short description of error
There is no way in 2.8 to hide the object that is duplicated. In 2.79a Cycles would do that automatically for rendering. In 2.8 we don't have this for any system. Maybe we should reproduce the old Cycles behaviour

Exact steps for others to reproduce the error

  • In 2.79a with Cycles it renders fine (the plane and the middle cone are hidden)
  • In 2.8 change render engine to eevee and F12: only the plane is hidden, the middle cone is still there.



Event Timeline

@Sergey Sharybin (sergey) what do you think? Should we implement Cycles behaviour by default?

Another option is to always show the children (the duplicated cone in this case) even if the original object is in a hidden collection. Users would then hide / not include the collection with the "to-be duplicated object" in the final render view layer.

This is a bit of a weird feature that I wouldn't mind getting rid of. From what I remember it's there because the old layer system didn't have another way to make this work.

What I would expect is that the dupli object becomes part of the duplicator collection and inherits its visibility from that. So then you could put the original object in a hidden collection. When duplicating a group/collection, I would expect the visibility of that collection to be preserved and follow the same inheritance rules as if the collection was now a child of the duplicator collection. If there was individual visibility of objects, I would expect that to be preserved as well.

It's more manual work, though in many cases users are doing this already to avoid cluttering the viewport.

Alright, commited e75c04898f49. If @Brecht Van Lommel (brecht) and @Sergey Sharybin (sergey) are happy with this we can then move on to get this supported in Cycles as well (duplicators in Cycles are barely working at the moment, but I wanted to get this out of the way before doing (or reviewing) any changes there).

Note to self: e75c04898f49 introduces a lot of memleaks when opening the following file. There is a chance the issue is in draw manager, not necessarily on the commit, but I will look at this further tomorrow.

Sebastian Parborg (zeddb) lowered the priority of this task from Needs Triage by Developer to Confirmed, Medium.Feb 5 2019, 2:11 PM

I'll mark this as confirmed.

Brecht Van Lommel (brecht) closed this task as Resolved.Apr 4 2019, 5:16 AM
Brecht Van Lommel (brecht) claimed this task.