Source Collection visbility will affect the final render of the links object(geo nodes) in eevee/cycles #97535

New Issue

yonghao lv · 2022-04-22T06:58:14+02:00

yonghao lv commented

2022-04-22 06:58:14 +02:00

System Information
Operating system: Windows-10-10.0.22000-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.15

Blender Version
Broken: version: 3.2.0 Alpha, branch: master, commit date: 2022-04-21 22:11, hash: 179100c021
Worked: (newest version of Blender that worked as expected)

Short description of error
When collection is used in GN tree and it is disabled for final render (camera icon in outliner). Then the new object is not visible in final render
Which is not the case when object is used instead of collection in GN tree

Exact steps for others to reproduce the error

create a simple object
move it to a new collection
turn off the collection's visibility
new object with geo mod, use the collection as output
render, the new object didn't show in the final render(but viewport)

or

Open test file
Do final render i.e. F12 (object is not visible in final render)
Now connect object info node to group output and render (object is visible)
Test File
#97535.blend
2022-04-22 12-55-10.mp4

**System Information** Operating system: Windows-10-10.0.22000-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 SUPER/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.15 **Blender Version** Broken: version: 3.2.0 Alpha, branch: master, commit date: 2022-04-21 22:11, hash: `179100c021` Worked: (newest version of Blender that worked as expected) **Short description of error** When collection is used in GN tree and it is disabled for final render (camera icon in outliner). Then the new object is not visible in final render Which is not the case when object is used instead of collection in GN tree **Exact steps for others to reproduce the error** 1. create a simple object 2. move it to a new collection 3. turn off the collection's visibility 4. new object with geo mod, use the collection as output 5. render, the new object didn't show in the final render(but viewport) or - Open test file - Do final render i.e. F12 (object is not visible in final render) - Now connect `object info` node to group output and render (object is visible) Test File [#97535.blend](https://archive.blender.org/developer/F13067407/T97535.blend) [2022-04-22 12-55-10.mp4](https://archive.blender.org/developer/F13015392/2022-04-22_12-55-10.mp4)

yonghao lv commented

2022-04-22 06:58:14 +02:00

Added subscriber: @1029910278

blender-admin commented

2022-04-22 06:58:14 +02:00

#102331 was marked as duplicate of this issue

blender-admin commented

2022-04-22 06:58:14 +02:00

#97373 was marked as duplicate of this issue

Germano Cavalcante commented

2022-04-25 04:24:34 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2022-04-25 04:24:34 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Germano Cavalcante commented

2022-04-25 04:24:34 +02:00

This doesn't look like a bug to me.
By clicking on the camera icon you are Globally disabling the collection in the render.
If you want the collection to continue to exist, but not appear in the render, you need to click on the icon to Exclude the Collection from the View Layer.
If you want to disable it in the Viewport (as you disabled in Render), you need to enable this icon:

(The eye only affects the viewport).

But I can be wrong. Does what I said make sense to you?

This doesn't look like a bug to me. By clicking on the camera icon you are Globally disabling the collection in the render. If you want the collection to continue to exist, but not appear in the render, you need to click on the icon to Exclude the Collection from the View Layer. If you want to disable it in the Viewport (as you disabled in Render), you need to enable this icon: ![Captura de Tela 2022-04-24 às 23.13.17.png](https://archive.blender.org/developer/F13024088/Captura_de_Tela_2022-04-24_a_s_23.13.17.png) (The eye only affects the viewport). But I can be wrong. Does what I said make sense to you?

yonghao lv commented

2022-04-25 07:45:45 +02:00

I think getting geo info from collection is just like getting geo info from obj. They should have the same behavior. Visibility is based on the obj level not mesh, it should not affect the geo info

Germano Cavalcante commented

2022-04-25 20:34:57 +02:00

Changed status from 'Needs User Info' to: 'Needs Developer To Reproduce'

Germano Cavalcante commented

2022-04-25 20:34:57 +02:00

My guess is that in this case the Mesh is not an instance, but a kind of copy of the geometry.

However I tested the As Instance option, and it also appeared in the render (which is not bad as it is the only way to hide the original object in the render).

Indeed it seems to be a bug, or an inconsistent design.

I'll leave it to the #user_interface or #geometry_nodes team to decide what to do here.

My guess is that in this case the `Mesh` is not an instance, but a kind of copy of the geometry. However I tested the `As Instance` option, and it also appeared in the render (which is not bad as it is the only way to hide the original object in the render). Indeed it seems to be a bug, or an inconsistent design. I'll leave it to the #user_interface or #geometry_nodes team to decide what to do here.

Pratik Borhade commented

2022-04-26 06:47:25 +02:00

Added subscribers: @boson, @PratikPB2123, @HooglyBoogly

Mikael Virtanen commented

2022-04-26 15:50:50 +02:00

For the question of which way is right and which way is wrong, the following criteria seems meaningful for the good way of having things:

1. blender permits you to do as many meaningful and common changes to your scene as possible, in an easy and intuitive way.
2. each icon/functionality does something different from the other icons, each icon has a purpose.
3. UI elements that are not really needed are often better to avoid

If there is just a single instance of some collection, it doesn't really matter so much what is the way you turn it visible or invisible, and how the related icons work. It will be easy and doable in any case. (And even more so, if there are no instances of the collection, just the collection itself.) The real differences come when there are really many instances of the collection in the scene.

Example: (Here I am commenting a more general case)
Let's suppose we have a collection named "ABCD" and also that there are 100 instances of ABCD around the scene. (Note that the collection itself has to be located somewhere(!!!) in the scene, so let's have it unmoving in the world origin. The instances are located wherever, and moving around. The collection acts like a template for these instances.)

The possible actions that I would like do, without changing anything else in the scene, and in a simple way, are at least the following:

A1. Turning the collection ABCD visible/invisible. Here our collection is staying in the world origin at all times, unmoving and not rotating. Note that this action should not affect the instances of that collection in any way. Some could call the collection ABCD as a "model", "template" or "prefab" for the actual instances that are moving in the scene. For most realistic scenarios I would assume the collection ABCD is always be turned invisible (when there are lot of instances of that collection in the scene), except when editing the collection's appearance.

A2. Turning some individual instance of ABCD invisible. In Viewport or Renders (or both), as I choose.

A3. If some number of the 100 instances are generated with geometry nodes or other similar method, turning all of the so generated instances invisible. In Viewport or Renders. Let's have 90 of the instances generated by geometry nodes, whereas 10 are generated individually and made to move in more individualistic ways.

A4. Turning all of the 100 instances of ABCD invisible, Viewport or Renders, in a single move.

(I wrote those actions as turning something invisible and not making it visible/invisible, since for something to be visible, often several variables should all agree it is visible and that can't be guaranteed, whereas invisibility is certain by having just one of those variables tagging it invisible.)

Luckily there would be a simple way of achieving all those actions A1-A4. At least by the following way:

Whether or not the collection ABCD (that is a template(!!!), located at origin) is visible, is controlled by the checkbox next to collection's name (the icon Exclude the Collection from the View Layer). If the checkbox is unchecked, the collection ABCD is not visible in Viewport or Renders, and if it is checked, the collection ABCD is visible when its eye or camera icons allow visibility. Note that this checkbox is just for the template itself, not for any instances made out of it.
Whether all of the 100 (or however many) instances in the scene are collectively turned invisible, is controlled by the collection's eye icon for Viewport, and camera icon for Renders. (So for an instance to be visible, several conditions must be met, and blender should check that the collection's eye icon (Hide in Viewport) and camera icon (Disable in Renders allow visibilitity; in addition to checking that instance's own eye or camera icons/those variables allow visibility, too.) Note that 3.1 have had this inconsistent, since Renders does check that the collection's camera icon visibility and instance's camera icon both allow visibility before showing the object in Renders (good!), whereas Viewport ignores the collection's eye icon.
Individual instances can be turned invisible by changing that instance's own eye icon (Hide in Viewport) to a closed eyelid icon for Viewport, and similarly with that instance's own camera icon for Renders. This will turn that instance invisible (whereas having the eye/uncrossed camera icons would turn it visible, if the collection's eye/camera allowed visibility, too.)
Similarly with instances that are generated with geometry nodes (or other similar methods). Those have their own eye and camera icons that would need to allow visibility, too, if an the so generated instances are to be shown in Viewport or Renders. (The eye/camera icon for those geometry nodes, and the eye/camera for the collection ABCD should both allow visibility.) As mentioned in 2) above, blender 3.1 has a bug in this, since Renders and Viewport behave inconstently. Since this way of having things (which is also the way Renders is behaving) would allow the all meaningful actions A1-A4, and the way Viewport behaves would not, it would seem that this is the right way of having things. (As for the linked blender 3.1. bug report this would mean that the Renders way is right, and Viewport rendering should check the collection's eye icon, too.)

So, this way of having things would allow all the actions A1-A4, those would be achieved in a simple intuitive way (which is likely also the simplest possible way), and all icons would have a unique purpose.

(As a theoretical note, in the system suggested above the only deviation from maximum flexibility seems to be that when there are instances of some collection, one would change the collection's visibility with the checkbox Exclude the Collection from the View Layer for both Viewport and Renders with the same setting. So not individual settings for both. Yet this is not even a minimal real issue, since most likely either the collection has several instances and in that case the collection itself (which then acts like template) would likely not be shown wherever it is located, except when user is editing it. Just the instances of the collection would be visible. Thus no issues.

The other typical case is that there is just the collection, and no other instance of it. In that case, even if one would like to have its visibility different in Viewport and Renders, one could also use the eye and camera icons to achieve that. It wouldn't matter that those would also change the visibility of instances, since there are none in addition to the collection itself. Thus no issues.

In the rare case that one would have the collection, some other instances of the collection, and most importantly, one would wish to have the collection (template)'s visibility different in Viewport and Renders(!), then the suggested way of having things would indeed require an extra mouse click from the user before doing the final rendering. This is likely to so rare situation and so small trouble that I wouldn't change UI to something more complicated (such as having two checkboxes for collections, one for Viewport visibility and and the other for Renders visibility of the collection.) Even if it didn't require any programming work, the version with just one checkbox might well be the better one.

Germano Cavalcante (mano-wii) had a picture of four icons, the checkbox, eye, computer screen and a camera. In 3.1 I don't have the computer screen icon which might be there in 3.2(?) So I don't know how it would work. Yet it kind of seems that such computer screen icon could be like the extra checkbox of the paragraph above.... In that case I would wonder if the UI would still be better without it, with the checkbox and computer screen icon functionalities merged into the sole checkbox...

Making such computer screen icon into 3.2. UI might also be a result of fixing a real and quite annoying bug, but IMO in wrong way. That bug being that one could not turn all the instances of some collection invisible in a simple way in Viewport. And if one had say 20 instances of some collection made individually, then to turn off/on those would require 20 mouse clicks... So let's have this new computer screen icon that would turn all of those instances on/off with a single click in the Viewport? Yet it would seem that the better fix for this bug is just to check that the collection's eye icon (Hide from Viewport) allows visibility, just like the Renders already checks that the collections's camera icon allows visibility. That would achieve the same goal without adding a new icon.

(Also, if some collection is used as a template for instances, it likely has the same visibility in Viewport and Renders, and there doesn't seem to be a real need for individualized visibility setting for the template itself. Having it different few times while editing the collection, doesn't seem enough. And if some collection is used just for collecting all assets of some single use object into one place, then there apparently isn't a need for the extra icon for the collection's visibility, since all visibility changes could already be handled with the usual eye and camera icons. )

For the question of which way is right and which way is wrong, the following criteria seems meaningful for the good way of having things: *1. blender permits you to do as many meaningful and common changes to your scene as possible, in an easy and intuitive way.* *2. each icon/functionality does something different from the other icons, each icon has a purpose.* *3. UI elements that are not really needed are often better to avoid* If there is just a single instance of some collection, it doesn't really matter so much what is the way you turn it visible or invisible, and how the related icons work. It will be easy and doable in any case. (And even more so, if there are no instances of the collection, just the collection itself.) **The real differences come when there are really many instances of the collection in the scene.** **Example:** (Here I am commenting a more general case) Let's suppose we have a *collection* named "*ABCD*" and also that there are 100 *instances* of ABCD around the scene. *(Note that the collection itself has to be located somewhere(!!!) in the scene, so let's have it unmoving in the world origin. The instances are located wherever, and moving around. The collection acts like a template for these instances.)* **The possible actions** that I would like do, **without changing anything else in the scene**, and in a simple way, are at least the following: A1. Turning the collection ABCD visible/invisible. *Here our collection is staying in the world origin at all times, unmoving and not rotating. Note that this action should not affect the instances of that collection in any way. Some could call the collection ABCD as a "model", "template" or "prefab" for the actual instances that are moving in the scene. For most realistic scenarios I would assume the collection ABCD is always be turned invisible (when there are lot of instances of that collection in the scene), except when editing the collection's appearance.* A2. Turning some individual *instance* of ABCD invisible. In Viewport or Renders (or both), as I choose. A3. If some number of the 100 instances are generated with geometry nodes or other similar method, turning all of the so generated instances invisible. In Viewport or Renders. *Let's have 90 of the instances generated by geometry nodes, whereas 10 are generated individually and made to move in more individualistic ways.* A4. Turning all of the 100 instances of ABCD invisible, Viewport or Renders, in a single move. (I wrote those actions as turning something *invisible* and not making it *visible/invisible*, since for something to be visible, often several variables should *all* agree it is visible and that can't be guaranteed, whereas invisibility is certain by having just one of those variables tagging it invisible.) **Luckily there would be a simple way of achieving all those actions A1-A4.** At least by **the following way:** 1) Whether or not the collection ABCD *(that is a **template(!!!)**, located at origin)* is visible, is controlled **by the checkbox** next to collection's name (the icon *Exclude the Collection from the View Layer*). If the checkbox is unchecked, the collection ABCD is not visible in Viewport or Renders, and if it is checked, the collection ABCD is visible when its eye or camera icons allow visibility. Note that this checkbox is just for the template itself, not for any instances made out of it. 2) Whether **all of the 100** (or however many) **instances** in the scene are collectively turned invisible, is controlled by **the collection's** eye icon for Viewport, and camera icon for Renders. (So for an instance to be visible, several conditions must be met, and blender should check that the collection's eye icon (*Hide in Viewport*) and camera icon (*Disable in Renders* allow visibilitity; in addition to checking that instance's own eye or camera icons/those variables allow visibility, too.) **Note that 3.1 have had this inconsistent**, since Renders does check *that the collection's camera icon visibility and instance's camera icon **both** allow visibility* before showing the object in Renders (good!), whereas Viewport ignores the collection's eye icon. 3) Individual instances can be turned invisible by changing that instance's own eye icon (*Hide in Viewport*) to a closed eyelid icon for Viewport, and similarly with that instance's own camera icon for Renders. This will turn that instance invisible (whereas having the eye/uncrossed camera icons would turn it visible, if the collection's eye/camera allowed visibility, too.) 4) Similarly with instances that are generated with geometry nodes (or other similar methods). Those have their own eye and camera icons that would need to allow visibility, too, if an the so generated instances are to be shown in Viewport or Renders. (The eye/camera icon for those geometry nodes, and the eye/camera for the collection ABCD should both allow visibility.) As mentioned in 2) above, blender 3.1 has a bug in this, since Renders and Viewport behave inconstently. Since this way of having things (which is also the way Renders is behaving) would allow the all meaningful actions A1-A4, and the way Viewport behaves would not, it would seem that this is the right way of having things. (As for the linked blender 3.1. bug report this would mean that the Renders way is right, and Viewport rendering should check the collection's eye icon, too.) So, **this way of having things would allow all the actions A1-A4, those would be achieved in a simple intuitive way (which is likely also the simplest possible way), and all icons would have a unique purpose**. (As a theoretical note, in the system suggested above the only deviation from maximum flexibility seems to be that when there are instances of some collection, one would change the collection's visibility with the checkbox *Exclude the Collection from the View Layer* for **both** Viewport and Renders with the same setting. So not individual settings for both. Yet this is not even a minimal real issue, since most likely either the collection has several instances and in that case the collection itself (which then acts like template) would likely not be shown wherever it is located, except when user is editing it. Just the instances of the collection would be visible. Thus no issues. The other typical case is that there is just the collection, and no other instance of it. In that case, even if one would like to have its visibility different in Viewport and Renders, one could also use the eye and camera icons to achieve that. It wouldn't matter that those would also change the visibility of instances, since there are none in addition to the collection itself. Thus no issues. In the rare case that one would have the collection, some other instances of the collection, and most importantly, one would wish to have the collection (template)'s visibility different in Viewport and Renders(!), then the suggested way of having things would indeed require an extra mouse click from the user before doing the final rendering. This is likely to so rare situation and so small trouble that I wouldn't change UI to something more complicated (such as having two checkboxes for collections, one for Viewport visibility and and the other for Renders visibility of the collection.) Even if it didn't require any programming work, the version with just one checkbox might well be the better one. Germano Cavalcante (mano-wii) had a picture of four icons, the checkbox, eye, computer screen and a camera. In 3.1 I don't have the computer screen icon which might be there in 3.2(?) So I don't know how it would work. Yet it kind of seems that such computer screen icon could be like the extra checkbox of the paragraph above.... In that case I would wonder if the UI would still be better without it, with the checkbox and computer screen icon functionalities merged into the sole checkbox... Making such computer screen icon into 3.2. UI might also be a result of fixing a real and quite annoying bug, but IMO in wrong way. That bug being that one could not turn all the instances of some collection invisible in a simple way in Viewport. And if one had say 20 instances of some collection made individually, then to turn off/on those would require 20 mouse clicks... So let's have this new computer screen icon that would turn all of those instances on/off with a single click in the Viewport? Yet it would seem that the better fix for this bug is just to check that the collection's eye icon (*Hide from Viewport*) allows visibility, just like the Renders already checks that the collections's camera icon allows visibility. That would achieve the same goal without adding a new icon. (Also, if some collection is used as a template for instances, it likely has the same visibility in Viewport and Renders, and there doesn't seem to be a real need for individualized visibility setting for the template itself. Having it different few times while editing the collection, doesn't seem enough. And if some collection is used just for collecting all assets of some single use object into one place, then there apparently isn't a need for the extra icon for the collection's visibility, since all visibility changes could already be handled with the usual eye and camera icons. )

Germano Cavalcante commented

2022-04-26 21:28:59 +02:00

In #97535#1346956, @boson wrote:
(...)
Germano Cavalcante (mano-wii) had a picture of four icons, the checkbox, eye, computer screen and a camera. In 3.1 I don't have the computer screen icon which might be there in 3.2(?)

It is filtered by default:

> In #97535#1346956, @boson wrote: > (...) > Germano Cavalcante (mano-wii) had a picture of four icons, the checkbox, eye, computer screen and a camera. In 3.1 I don't have the computer screen icon which might be there in 3.2(?) It is filtered by default: ![image.png](https://archive.blender.org/developer/F13030454/image.png)

Hans Goudey commented

2022-04-27 20:24:59 +02:00

My guess is that this is a bug, but I don't know the design of the collection "enable" toggle well enough to know. So I'll bring in the #Core module here ;)

Mikael Virtanen commented

2022-04-28 08:58:44 +02:00

And if it is a bug, then I would say everything else is working well, except in Viewport.

And to correct Viewport behavior, before showing the instances made of some collection (that is, the geometry of those instances is from the collection) in Viewport, several conditions must be fulfilled. (Already it is like this.) And if even one of those conditions is not fulfilled (some variable is False or something), then the instances are not shown in Viewport.

Just include one more check for instances before showing those in Viewport: that the collection's eye icon (Hide in Viewport) would allow visibility**, too**, before showing those instances in Viewport.

And if it is a bug, then I would say everything else is working well, except in Viewport. And to correct Viewport behavior, before showing **the instances** made of some **collection** *(that is, the geometry of those instances is from the collection)* **in Viewport**, several conditions must be fulfilled. (Already it is like this.) And if even one of those conditions is not fulfilled (some variable is False or something), then the instances are not shown in Viewport. Just include one more check for instances before showing those in Viewport: that **the collection's** eye icon (*Hide in Viewport*) would allow visibility**, too**, before showing those instances in Viewport.

Bastien Montagne commented

2022-05-11 11:57:12 +02:00

Added subscriber: @mont29

Bastien Montagne commented

2022-05-11 11:57:12 +02:00

Changed status from 'Needs Developer To Reproduce' to: 'Needs User Info'

Bastien Montagne commented

2022-05-11 11:57:12 +02:00

This report is confusing to say the least, with initial report lacking (incomplete steps description, no reproducible .blend file), and giant wall of text added in comments.

Please update report itself to clearly state actual issue, with simple reproducible case etc.

This report is confusing to say the least, with initial report lacking (incomplete steps description, no reproducible .blend file), and giant wall of text added in comments. Please update report itself to clearly state actual issue, with simple reproducible case etc.

Pratik Borhade commented

2022-05-11 12:30:18 +02:00

Updated the description. Reproducing steps and other necessary info was already there in task description
i don't think if something for #core module to check here.
with current setup of GN tree, no data is written in spreadsheet. So I used realized instances and it solves the issue (object visible in final render)

Updated the description. Reproducing steps and other necessary info was already there in task description i don't think if something for #core module to check here. with current setup of GN tree, no data is written in spreadsheet. So I used realized instances and it solves the issue (object visible in final render)

Bastien Montagne commented

2022-05-11 14:20:39 +02:00

This is definitely not a UI issue, and indeed don't think this is Core issue either, more like how geometry nodes acquire their input data I guess...

Hans Goudey commented

2022-05-11 14:57:21 +02:00

Changed status from 'Needs User Info' to: 'Confirmed'

Richard Antalik commented

2022-11-10 22:36:22 +01:00

Added subscribers: @Vyach, @iss

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Source Collection visbility will affect the final render of the links object(geo nodes) in eevee/cycles #97535