ViewportTexture set for Sprite2D in editor doesn't work

[EvelynTSMG]

Godot version

4.0-alpha6

System information

Ubuntu 20.04.3 LTS, Vulkan, NVIDIA GTX 1060 6GB, nvidia-driver-470 (proprietary, tested)

Issue description

ViewportTextures set in the editor for Sprite2Ds don't work. Instead, they result in this error:

0:00:00:0411      setup_local_to_scene: Condition "proxy.is_valid()" is true.
  <C++ Source>    scene/main/viewport.cpp:87 @ setup_local_to_scene()

As a workaround, setting the ViewportTexture programmatically works, albeit the resulting image is inverted on the Y axis and the transparent_bg property of the SubViewport making the background black if on, or gray if off:

var view_texture = viewport.get_viewport().get_texture()
viewport_sprite.texture = view_texture

This given the following structure, using the Godot 3 demo https://godotengine.org/asset-library/asset/128 as base.

Using a SubViewportContainer as a workaround is also possible, though this also results in the transparent_bg property of the SubViewport making the background black if on, or gray if off:

Steps to reproduce

The minimal reproduction project presents the issue using SubViewport1, as well as the workarounds using SubViewport2 and SubViewport3.

On running the project two more errors undocumented above are pushed:

0:00:00:0526      get_path: Cannot get path of node as it is not in a scene tree.
  <C++ Error>     Condition "!is_inside_tree()" is true. Returning: NodePath()
  <C++ Source>    scene/main/node.cpp:1617 @ get_path()
0:00:00:0526      get_node: Node not found: "SubViewport1" (relative to "").
  <C++ Error>     Method/function failed. Returning: nullptr
  <C++ Source>    scene/main/node.cpp:1335 @ get_node()

At the time of writing I cannot be certain whether these were pushed because of a glitch or because of me making a mistake.

Minimal reproduction project

3d_in_2d.zip

[Calinou]

albeit the resulting image is inverted on the Y axis

Note that unlike Godot 3.x, you don't need to enable flip_y anymore to get the image with the right orientation.

[EvelynTSMG]

Updated main comment after further testing of the transparent_bg property

[nonunknown]

I can confirm this bug, during editor no message appears, but at runtime the error appears:

version: v4.0.alpha.mono.custom_build [947a1fa]

[ztc0611]

Still occurs in 4.0.beta2 in case it needed confirmation.

[Waringh4m]

I can confirm this bug, during editor no message appears, but at runtime the error appears:

version: v4.0.alpha.mono.custom_build [947a1fa]

Interestingly you can fix 2 of those errors by placing the object that displays the ViewportTexture lower than the Viewport itself in the scene tree.

I still have not managed to get rid off the 'Condition "proxy.is_valid()" is true.' error mesage.
(Godot 4.0 beta 5)

[prominentdetail]

I get this error when I move the object below the viewport.
If I move it above the viewport, then I get a different error "_ready: ViewportTexture: Path to node is invalid."
It still works when it is above, but it doesn't work when it is below. (it breaks when I get "'Condition "proxy.is_valid()" is true.")
(v4.0.beta.custom_build [0b958971f])

[JulianHeuser]

I'm having the same problem in beta 8 - the console reports the "proxy,is_valid() is true" error for every viewport. I'm not using a sprite though, just UI (although I'm guessing the same issues is happening here). Everything appears to work fine in-game

[ztc0611]

Is anybody having this issue on Windows? Or is it just Mac and Linux?

[JulianHeuser]

I'm on Linux (Mint 21 Cinnamon)

[Waringh4m]

Can confirm, issue appears on Windows 10 and 11.

[dreamsComeTrue]

Confirming (Win 11) as well.
The same exact error happens, and results in game crashing every time when closing the window.

[ghaz0]

Having this issue as well with using a viewport containing a control node in a 3D environment.

[michaeltintiuc]

The strange thing is that I get this error in the debugger yet the texture is shown fine when running from the editor. But when exporting the game (release or debug) the viewport texture is black. I was able to remove all the errors and warnings by getting the texture through code, but the result is the same, just no errors.
The only thing that solved it for me was to use material_override, setting the viewport texture through code and not using local to scene:

extends MeshInstance3D


func _ready():
	var vpt := (%SubViewport as SubViewport).get_texture()
	material_override.texture_albedo = vpt

Note: doing the same from the editor results in the error and black texture when exported

[baptr]

The strange thing is that I get this error in the debugger yet the texture is shown fine when running from the editor. But when exporting the game (release or debug) the viewport texture is black.

This is probably a separable issue, but the SubViewport's render_target_update_mode seems to be the trick here. For some reason, when run from the editor, the sub viewport gets drawn as long as the update mode is at least "When Visible". But when exported, that no longer triggers draws, only "When Parent Visible" or "Always" does.

For extra fun, if your viewport changes via a @tool script so it should vary directly in the editor without running - only "When Visible" or "Always" (not "When Parent Visible") cause it to be redrawn live.

Here's a fresh (4.0rc5) MRP with toggles to mess with the refresh mode, and otherwise as a working example of 2d in 3d (despite the proxy.is_valid() error logs) :
2d3d.zip

[L2750558108]

same problem in 4.0 release

[Gegbee]

The strange thing is that I get this error in the debugger yet the texture is shown fine when running from the editor. But when exporting the game (release or debug) the viewport texture is black.

This is probably a separable issue, but the SubViewport's render_target_update_mode seems to be the trick here. For some reason, when run from the editor, the sub viewport gets drawn as long as the update mode is at least "When Visible". But when exported, that no longer triggers draws, only "When Parent Visible" or "Always" does.

For extra fun, if your viewport changes via a @tool script so it should vary directly in the editor without running - only "When Visible" or "Always" (not "When Parent Visible") cause it to be redrawn live.

Here's a fresh (4.0rc5) MRP with toggles to mess with the refresh mode, and otherwise as a working example of 2d in 3d (despite the proxy.is_valid() error logs) : 2d3d.zip

Thank you so much. Using the Godot 4.0 release, changing 'render_target_update_mode' to "Always" solved the issue, however, the issue without changing that attribute remains unsolved on my behalf.

[Mercerenies]

Trying in Godot 4.0 stable release today, I just ran into this same issue on Linux. Varying the render_target_update_mode did not help for me. I can still run successfully if I set the viewport texture in code rather than in the UI.

[SlashScreen]

Ran into this issue on 4.0.1 Mono Win10.

E 0:00:00:0731   setup_local_to_scene: Condition "proxy.is_valid()" is true.
  <C++ Source>   scene/main/viewport.cpp:89 @ setup_local_to_scene()

Setting it from code did help, although my viewport is still black, but I thin that's a me issue.

[matthew798]

I am also having this issue.

@SlashScreen I don't think it is a "you" issue. I use vscode for debugging and when I run in the editor, the viewport texture is black but when I run from vscode the viewport texture is correct and I get no errors in the console.

[SlashScreen]

@matthew798 in my case, it was at least partially a me issue. setting the sub viewport update mode to always instead of when visible fixed it.

[akien-mga]

Is this still reproducible in 4.1 beta 3 or later?

[YuriSizov]

Using 4.2 beta 6 I don't see any issues in the reproduction project. Every subviewport in the scene provides a working texture in the editor.

Here's the updated project: godot-4.0-viewport-texture-on-sprite.zip

Given that, the lack of responses since the last comment, and the fact that several viewport texture related issues have been fixed in 4.1 and 4.2, I think this can be closed. If you still can reproduce the issue, please provide an updated MRP and we can reopen it.