Expose `World3D.compositor`

[nonchip]

Describe the project you are working on

a script (planned addon) to manage WorldEnvironment and Camera related effects

Describe the problem or limitation you are having in your project

World3D exposes environment and camera_attributes and does have but does not expose the compositor property.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

it would allow accessing the compositor property right on the World3D, where it "matters", instead of having to go through a "dummy" WorldEnvironment node's internal setter or the Server.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

by being the World3D.compositor it already is, but visible through the ClassDB

If this enhancement will not be used often, can it be worked around with a few lines of script?

it can be worked around by adding a WorldEnvironment node and setting the property on it instead (which will then call World3D.set_compositor internally on the world of its associated viewport).

it can also be worked around by calling RenderingServer.scenario_set_compositor, but that won't actually update the World3D, just work all the way around the scenetree/viewport.

neither of them allow the World3D resource to retain its compositor property in storage.

Is there a reason why this should be core and not an add-on in the asset library?

because that's where it already is, we just miss 3 lines of telling the ClassDB about it (and its accessors, that's the other 2 lines).

[fire]

World3D exposes environment and camera_attributes and does have but does not expose the compositor property.

A script (planned addon) to manage WorldEnvironment and Camera related effects

This is not a game problem. What is the problem you are solving in your game?

Some guesses from my clients in Game Development:

1. Need to make settings menu for the game
2. Have a mmog and want to save server costs by dividing one server into many that don't cross World3d boundaries.

[nonchip]

@fire i have not the slightest clue what your example is about, but that really doesn't sound related to World3D and its compositor property. rendering has nothing to do with networking.

and the problem is that i want to access World3D.compositor without abusing a WorldEnvironment node. and that the implementor(s) of World3D.compositor/Compositor/CompositorEffect forgot to expose the property to the ClassDB.

so yes, "the problem or limitation" i have in my project that is about managing the World3D.compositor is that i don't have access to it (despite having access to the other properties managed in that resource which is why i pointed that out).

---

should this ticket just be a bug report maybe? pretty sure that just got missed in the PR, there was no mention about its omission as far as i could tell.

[fire]

I have no clue why you would want to use World3D and its compositor property so I'm trying to figure out. Assuming it's used for something.

Saying that World3D and its compositor property is useful because it's the World3D and compositor makes me confused and lost.

Edited:

Trying to figure out why https://github.com/godotengine/godot/blob/master/scene/resources/3d/world_3d.cpp#L151-L152 get_environment is not in your build.

[nonchip]

@fire yeah i wasnt aware this issue is supposed to document existing features just for mentioning them. usually people look things up in docs or ask if they don't know what a builtin class does before blaming people for being "unclear what it's even for" and "not describing 'a game problem'". because sometimes the problem really is "someone forgot this", and not just "i have no idea what I'm even doing". this isn't an "X/Y problem", it's "trying to access the 'Y' that exists for the sole purpose of enabling 'X', but directly instead of abusing a Node or circumventing the whole Viewport", just you apparently didn't know that "Y" even existed before and gdscript/classdb/docgen doesn't get to see it (for no reason).

World3D.compositor is where the World3D extends Resource stores (at runtime; but doesn't expose and therefore also not really store in the Resource) its Compositor extends Resource instance that's then used to define the render pipeline to draw all of that World3D (when assigned to a Viewport).

and get/set (plus the actual property decl for) environment are there, as explained twice (no offense but do either of us need more coffee or something? you seem to be reading the exact opposite of what i wrote in multiple spots), just not "compositor" (in the same function you linked to), because there are no method registrations for {s,g}et_compositor and then the property declaration for compositor itself.