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

Vulkan: SubViewports not functioning unless update mode is set to "Always" #55471

Closed
Leakbang opened this issue Nov 30, 2021 · 32 comments · Fixed by #70132
Closed

Vulkan: SubViewports not functioning unless update mode is set to "Always" #55471

Leakbang opened this issue Nov 30, 2021 · 32 comments · Fixed by #70132

Comments

@Leakbang
Copy link

Leakbang commented Nov 30, 2021


Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.


Godot version

v4.0.dev.calinou [cf67f18]

System information

Linux KDE Neon, Vulkan, NVIDIA GeForce GTX 1050 Ti, Driver Version: 470.63.01

Issue description

I cannot seem to make Subviewports work in any shape or form. The error message Uniforms were never supplied for set (3) at the time of drawing, which are required by the pipeline is continuously popping up. I have tried with both 2D and 3D objects in the viewports, however none seem to work.
Are others able to reproduce this effect?

Steps to reproduce

  1. Setup a basic 3D scene
  2. Add a SubViewport node
  3. Set nodes as its children (Camera, UI control, or others)
    The viewport display is black and rendering the viewport as a texture will also not work.

Minimal reproduction project

No response

@Leakbang Leakbang changed the title [Godot 4] Viewports not functioning [Godot 4] SubViewports not functioning Nov 30, 2021
@Calinou Calinou added this to the 4.0 milestone Nov 30, 2021
@Calinou Calinou changed the title [Godot 4] SubViewports not functioning Vulkan: SubViewports not functioning Nov 30, 2021
@spindlebink
Copy link

Same here. I initially figured they just weren't implemented yet, but good to hear others are having the same issue.

@Calinou
Copy link
Member

Calinou commented Dec 1, 2021

Other people have gotten SubViewports to work on master, such as in #40651 and #54122. It seems that it's mainly breaking in 3D: #50327, #50296

@navy-cap-echo
Copy link

@Leakbang I had the same problem (black display) until i switch the "update mode" in the "Render target" of the SubViewport to "Always". I'm not sure this fixes your problem, but maybe give it a try.

@Leakbang
Copy link
Author

Leakbang commented Dec 1, 2021

I did try setting the "update mode" to "Always" but it didn't make any difference for me.

@FluffyBunniesTasteTheBest
Copy link

FluffyBunniesTasteTheBest commented Dec 6, 2021

Same here in 3D, except that the SubViewport shows only pink instead of black. Changing "Update mode" to "Always" fixed it. (Mono build running on Ubuntu 21.10)

@Calinou Calinou changed the title Vulkan: SubViewports not functioning Vulkan: SubViewports not functioning unless update mode is set to "Always" Dec 6, 2021
@Leakbang
Copy link
Author

I retried this on v4.0.dev.calinou [e31138958], and setting the update mode to Always does not fix the issue.

@KoBeWi
Copy link
Member

KoBeWi commented Dec 19, 2021

I just discovered the existence of UPDATE_WHEN_PARENT_VISIBLE. This should be the default option in SubViewport probably. UPDATE_WHEN_VISIBLE makes sense only for Window viewports and won't work as expected for typical usage.

@KoBeWi
Copy link
Member

KoBeWi commented Dec 25, 2021

Actually no, UPDATE_WHEN_VISIBLE uses render_target_was_used() method, which never returns true. UPDATE_WHEN_PARENT_VISIBLE checks parent Viewport actually.

@Duroxxigar
Copy link
Contributor

Duroxxigar commented Dec 30, 2021

Just wanted to chime in here as well - setting the update mode to Always doesn't fix the issue for me either. 28174d531b

@Zireael07
Copy link
Contributor

In alpha 1, 2D subviewports seem to work, but 3D don't. The resulting texture is either all black or all magenta

@CrezyDud
Copy link
Contributor

CrezyDud commented Feb 7, 2022

In alpha 1, 2D subviewports seem to work, but 3D don't. The resulting texture is either all black or all magenta

works for me

@kalysti
Copy link
Contributor

kalysti commented Mar 19, 2022

Same issue by me, but render target mode is always. 3d is still not working.
Tested with HBox, VBox, HSplit and VSplit Nodes..

Node tree
image
Output
image

When i move it an split controller and change the offset of the split controllers it works.
U can see here:
image

@Zireael07
Copy link
Contributor

Hm, so it seems forcing an update/resize might do the trick? Thanks for the tip...

@kalysti
Copy link
Contributor

kalysti commented Mar 19, 2022

Yeah its looks like that the subviewport size are not setted right by the viewport container. if u do it manualy it works.

@kalysti
Copy link
Contributor

kalysti commented Mar 19, 2022

Small hack which fix the issue:

public override void _EnterTree() { var origSize = this.GetParent<SubViewportContainer>().Size; this.Size = new Vector2i((int)origSize.x, (int)origSize.y); }

@kalysti
Copy link
Contributor

kalysti commented Mar 19, 2022

I think the issues comes inside the code. The SubViewportContainer is set the size of the SubViewport (Vector2 to Vector2i) -> something here is broken

@seocwen
Copy link

seocwen commented Apr 30, 2022

The following line seems to do nothing:
render_target_clear_mode = SubViewport.CLEAR_MODE_NEVER

I've been trying to draw on top of my last frame to no avail. As a minimal test, I have a subviewpoint set to clearMode NEVER, with a single colorRect with the following script:

func _process(delta):
color = $"../../../resources".random_color()
color.a = randf()
position = Vector2(randi() % 384, randi() % 256)
size = Vector2(randi() % 64, randi() % 64)
update()

The result is a new rectangle every frame, rather than a rectangle being added to the render target every frame.

@IriaSomobu
Copy link

IriaSomobu commented May 3, 2022

4.0.alpha.calinou.ce4326df7

I wanted to draw output of secondary Camera3D on MeshInstance3D (PlaneMesh).

Scene layout is really simple

image

I wrote simple shader that maps input texture onto plane based on screen UV.
shader_type spatial;
render_mode unshaded;

uniform sampler2D viewport_texture : hint_albedo;

void fragment() {
	vec4 n_out4p0 = texture(viewport_texture, SCREEN_UV);
	ALBEDO = vec3(n_out4p0.xyz);
}

And then I assigned this shader to OutputPlane as a ShaderMaterial and set that single shader param as a ViewportTexture pointing to my SubViewport.

But all I've got it is a pink texture both in editor and in-game

image

image

I've managed to make it work, but it requires all conditions to be met:

  1. SubViewport must have both size and size_2d_override to be set;
  2. SubViewport must be render_target_update_mode = ALWAYS;
  3. OutputPlane's viewport_texture must be grabbed with viewport.get_texture() directly from viewport (done via script attached to plane).
This is how viewport texture is assigned
extends MeshInstance3D

@export var viewport: NodePath;
@onready var _viewport = get_node(viewport)

func _ready():
	var m: ShaderMaterial = mesh.surface_get_material(0);
	m.set_shader_param("viewport_texture", _viewport.get_texture())

Note: w/o 3rd workaround (i.e. when shader's viewport_texture assigned from editor) shader works properly in editor, but still shows pink color in-game. Also 3rd workaround is not required when SubViewport is placed in SubViewportContainer.

@Zireael07
Copy link
Contributor

Thanks for the workaround, I'll try it, as I still have the pink issue on my mirror mesh.

@thoced
Copy link

thoced commented May 8, 2022

IriaSomobu's solution works for me

@Zireael07
Copy link
Contributor

Confirming the workaround works.

@darrylryan
Copy link
Contributor

Just to update this - I'm still seeing weirdness with pink output like @sboron in the latest master as of time of posting. Setting update / clear modes doesn't seem to help.

@Rindbee
Copy link
Contributor

Rindbee commented Jul 9, 2022

I noticed that if I change the size property of the SubViewport, I won't have this problem. So it may be that the necessary steps in _set_size are not performed during initialization. Maybe we should set the size in the constructor of SubViewport.

Rindbee added a commit to Rindbee/godot that referenced this issue Aug 9, 2022
`SubViewport` has some initialization settings of its own, but these settings are not synchronized to the `RenderingServer` when initialized, which causes some problems.

Split from godotengine#62854.

This is a prerequisite to resolve godotengine#55471, still need to modify `update_mode` manually, or add as a child to `SubViewportContainer` (`update_mode` is automatically set to `UPDATE_ALWAYS`).

Currently, `UPDATE_WHEN_VISIBLE` has no meaning for `SubViewport`. Presumably for **visible**, `RenderingServer` has different rules, viewport needs to have a visible **rect** to be considered **visible**, while `SubViewport` has only `size` and **no** `position`, so it is not considered **visible** even if it is set to be an active viewport (`RS::viewport_set_active`).
@arcanis
Copy link

arcanis commented Oct 16, 2022

Expanding on @Rindbee's comment, the following seemed to work:

extends SubViewport

func _ready():
	set_size(size)

@someguynamedjosh
Copy link

For me what ended up working was deleting the shader and material off the filesystem, re-saving the scene I was working on, and ticking 'local to scene' on those same resources. Then I could assign a new viewporttexture (which was automatically local to the scene) in the shader's parameters and it worked!

@clayjohn
Copy link
Member

Update on this issue, it appears that the resize workaround is no longer needed since #68358 The only issue that remains here is that the update mode "When Visible" is not working. I'm looking into this now. All other update modes are working.

@nukeop

This comment was marked as abuse.

@nvanfleet
Copy link

I am seeing this on Mac OS Arm64 4.0.3 version of Godot. It looks like setting the texture programmatically makes it work for me actually.

self.plane1.mesh.material.set_shader_parameter("portal_texture", viewport2.get_texture())

@RisingThumb
Copy link

I am seeing this on Mac OS Arm64 4.0.3 version of Godot. It looks like setting the texture programmatically makes it work for me actually.

self.plane1.mesh.material.set_shader_parameter("portal_texture", viewport2.get_texture())

Just adding that I am seeing this in Godot v4.2.1 stable version of Godot, on Arch Linux using the official binaries. What nvanfleet wrote seems to be a workaround for this, so it looks like the issue is something to do with using viewport textures from the scene compared to when it's programmatically added 🤷

@lunarcloud
Copy link

I am seeing this on Mac OS Arm64 4.0.3 version of Godot. It looks like setting the texture programmatically makes it work for me actually.

self.plane1.mesh.material.set_shader_parameter("portal_texture", viewport2.get_texture())

Can you provide the full script example? I put this blindly into a script on the subviewport and it clearly needs more setup to work...

@RisingThumb
Copy link

I am seeing this on Mac OS Arm64 4.0.3 version of Godot. It looks like setting the texture programmatically makes it work for me actually.

self.plane1.mesh.material.set_shader_parameter("portal_texture", viewport2.get_texture())

Can you provide the full script example? I put this blindly into a script on the subviewport and it clearly needs more setup to work...

Your mesh should have a material. That material should be a shader. That shader should have a uniform sampler2D with the name "portal_texture". The issue described here, is that setting it in the Engine GUI doesn't work(I.E. clicking the material and clicking the subviewporttexture youw ant), but if you pass it programmatically it does work. I haven't had the time(or a use case) to look into whether this affects other things you can pass a viewport texture to.

This line of code needs to be adapted to get the correct material, and set the correct shader parameter and get the viewport texture. More information needed to point out what you're doing wrong

@colonelzkiller
Copy link

I'm getting this issue as well. Godot v4.2.1 stable. Using Fedora 39 Gnome, none of the above suggestions are working for me.

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