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

SubViewport + ViewportTexture doesn't work when created programmatically #75008

Closed
bluenote10 opened this issue Mar 16, 2023 · 3 comments
Closed

Comments

@bluenote10
Copy link
Contributor

bluenote10 commented Mar 16, 2023

Godot version

v4.0.stable.official [92bee43]

System information

Ubuntu 22.04, GeForce GTX 980

Issue description

Creating a SubViewport + ViewportTexture programmatically doesn't seem to work. The content of the viewport is simply not visible, and there are debugger errors:

image

The message Viewport Texture must be set to use it on first glance suggests that this is another manifestation of #66247, but in this case it is not a false error: The issue in #66247 seems to go away when setting the update mode to "always". That's not the case with the issue I'm facing. Also, creating exactly the same scene tree statically in the editor works, which indicates that the issue has rather something to do with creating the SubViewport + ViewportTexture programmatically.

Steps to reproduce

Simply use a single Node as the scene root with this script attached:

extends Node


func _ready():
    # Create the viewport, add something to it, and add it to the scene tree:
    # Note that setting UPDATE_ALWAYS doesn't help.
    var viewport = SubViewport.new()
    viewport.render_target_update_mode = SubViewport.UPDATE_ALWAYS
    add_something_to_viewport(viewport)
    add_child(viewport)
    
    # Now that the viewport has a path, we can create a texture and connect it:
    var viewport_texture = ViewportTexture.new()
    viewport_texture.viewport_path = viewport.get_path()

    # Finally create a sprite that uses the viewport texture:
    var sprite = Sprite2D.new()
    sprite.centered = false
    sprite.texture = viewport_texture # <== this line causes debugger errors
    add_child(sprite)


func add_something_to_viewport(viewport: SubViewport):
    var label = Label.new()
    label.text = "Hello world"
    viewport.add_child(label)

The example builds this scene tree dynamically:

image

For comparison I have created another minimal project, where I'm creating exactly the same scene tree statically in the editor:

image

In this case the SubViewport + ViewportTexture works, i.e., the contents of viewport are visible.

Minimal reproduction project

Full minimal reproduction:

@Rindbee
Copy link
Contributor

Rindbee commented Mar 16, 2023

In this case, it is recommended to obtain ViewportTexture directly from Viewport.

# var viewport_texture = ViewportTexture.new()
# viewport_texture.viewport_path = viewport.get_path()
var viewport_texture = viewport.get_texture()

The way of directly specifying viewport_path is just for convenience in the editor.

@smix8
Copy link
Contributor

smix8 commented Mar 17, 2023

When you create ViewportTextures in script you creating an unlinked / empty texture as rendertarget.
Setting the path on the ViewportTexture does nothing expect setting the path variable on the ViewportTexture.

You need to use the texture_proxy_create() and texture_proxy_update() functions of the RenderingServer to link rendertargets together. If you use Viewport.get_texture() this is done for you in the background. The returned ViewportTexture is just a wrapper for a texture that was proxy linked in the background. You can link any texture with the same format as your Viewport texture together using the RenderingServer API, it does not have to be a ViewportTexture at all.

@bluenote10
Copy link
Contributor Author

bluenote10 commented Mar 17, 2023

@Rindbee @smix8 Thanks for the clarification! Indeed, using Viewport.get_texture() works just fine. I took the opportunity to simply document this externally on StackOverflow, which is maybe already sufficient in terms of documenting the behavior?

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

No branches or pull requests

4 participants