You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
it will be a lot of work and a sketchy one and...
...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!
The text was updated successfully, but these errors were encountered:
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:
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:
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:
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!
The text was updated successfully, but these errors were encountered: