Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Improve Collections to work Better and Closer to old Layers, Scenes and Groups #1896

Open
2 tasks
UnidayStudio opened this issue May 21, 2024 · 0 comments

Comments

@UnidayStudio
Copy link
Collaborator

Since we've been teaching UPBGE (both 0.2.5 and 0.3+) to thousands of students and we also provide support to them, I noticed that there is a constant ongoing discussion regarding the ease of use and also the limitations of the new Collection, Overlay Collection and Object Adding system. More specifically related to how it used to work on 0.2.5. I've been experimenting with it a lot with them as well and taking some important notes. I think I have something interesting on this regard to share with y'all.

So I'll do my best to explain the issues I've been noticing over the past years and also my proposal on how to fix them.

The Issue:

➡️ Example 1:

image (38)

On 0.2.5, groups had this option for you to select what layers are visible and what aren't. That is VERY iseful because, for example, if you create an enemy that shoots a projectile, the projectile could be part of the enemy group, but on an invisible layer. Meaning that if I add instances of this enemy across different scenes, the projectile will also be there effortless.

That is A VERY GOOD FEATURE.

For 0.3, I believe that the same logic should've been applied to the collection, whereas the object's visibility replaces the layer. So if I wanted, I could create a Collection for the enemy, then leave the enemy objects visible but disable the projectile's visibility and that would be it. What's the issue with this? Well, in order to add this enemy, I need to disable the visibility of all objects, meaning that we lost this information of which object should be visible or not. Resulting in all of them to be visible.

➡️ Example 2:

A similar situation occur when creating interfaces. On 0.2.5, we could create another scene and add them as overlay. A similar thing could be done with Overlay Collections on 0.3, but there is a catch: For complex interfaces, you may want to add or remove objects in real time (to add menus, effects, icons, etc) and the way we used to do that on 0.2.5 was simple: since it was a separate scene, we could just move the objects we wanted to add to an inactive layer and that's it.

On 0.3, unfortunatelly, the same thing can't be said: for the overlay collection to work, once again, all objects must be disabled. Meaning that we once again lost the visibility information, resulting in all objects to be visible when added as an overlay.

And what could be a good possible solution for that?

I've discussed with some people, including youle, and as good as "bring back layers and groups" may sound to some, it's not a good idea.

Why?

Because of two reasons:

  1. it will be a lot of work and a sketchy one and...
  2. ...as some of you pointed out, Collections are part of the new Blender and they're a core and important feature. So it will be better if we could iterate over that instead of trying other sketchy approaches.

So my proposal would be to use a second criteria to define if each object is in an state that "it's possible to instantiate in game" (former inactive layer) and leave the object's visibility as they were supposed to work: if disabled, they're inactive, if enabled, they're active. BUT the catch here will be this second criteria: if you move the object to a collection and Disable it (Exclude from View Layer), then those objects in it should also be considered ready to be instantiated in game.

In other words:

  • If the Object is invisible and in an "Active Collection", then it can be added in real time (as it's already possible)
  • If the Object is Visible but in an "Inactive Collection", then it can also be added in real time (and its children will be added, checking one by one, to the "scene.objects" if visible and " scene.objectsInactive" otherwise.

⚠️ There are two catches with this approach:

  • 1️⃣ First one is that as youle explained to me, if you disable a collection, it does not get added to the depsgraph, making adding the objects in it a bit more complicated, in theory. Maybe we should create a different toogle parameter to specify the collection "deactivation"? Or just work around the depsgraph thing...

  • 2️⃣ Second catch is that both Vanilla Blender 4 and UPBGE 0.3+ have a behaviour that when you disable (Exclude from View Layer) a collection and then ENABLE IT BACK, all objects in it are set to visible... bringing the problem back. So it will be necessary to change this Blender behaviour in order to preserve object's visibility.


Conclusion

I'm sharing this here as an issue so we can discuss a bit further about it. And maybe some good soul could help implement it to the engine.

I believe, based on what I see from my audience, that this difficulty to use those features are one of the key elements that prevent people from moving from 0.2.5 to 0.3 nowadays. The hardware requirements nowadays are only a factor to about 20% of the people still using 0.2.5 (based on my researches here).

So resolving that will likely bring A LOT of new people from 0.2.5 to 0.3, not to talk about the newcomers that will find it much easier to understand.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant