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

Make viewports/containers usable inside Godot, improve viewport documentation and make it simpler to actually use viewports #2139

Open
chucklepie opened this issue Jan 17, 2021 · 7 comments · May be fixed by godotengine/godot#74573

Comments

@chucklepie
Copy link

chucklepie commented Jan 17, 2021

Describe the project you are working on

2D Platform

Describe the problem or limitation you are having in your project

As soon as you use a viewport you lose any and all abilities to edit and manipulate the contents and in addition there is almost no documentation on how viewport contains and viewports function in order to use them, i.e. add a viewport to your 2D game and you cannot edit properly.

Consider the following simple scene, which is just a tilemap and a couple of sprites
image

Add a viewport as per the documentation (https://docs.godotengine.org/en/3.2/tutorials/viewports/viewports.html) and as soon as you do, everything disappears both in the editor and runtime, you have no means of editing, even after the viewport is sized. I appreciate 'viewportcontainer' was created, but the documentation does not say it has to be a parent, simply the viewport will take it's size and isn't even mentioned in the viewport documentation.

image

Regardless of this missing documentation, and why a container is actually required, add a viewport container:

image

You still get no ability to view or edit your scene, although it does now show at runtime, i.e. you have no means of editing. In addition, the viewport container seems completely pointless, why is it set as a 40x40 box on the screen when all it does is host viewports and auto sizes?

Anyway, if you create a Scene from the stuff in your viewport, then magically it becomes 'visible', but there is no means of editing unless you go inside the branch, so why is the scene file rendering at all when you weren't allowed to see it before?

image

At this point you're saying, well that's fine, save it as a branch and you can edit it. But what if there are other objects in your viewport? there is no means of editing them, seeing them, moving then or seeing how they work with the other elements, i.e. in this case the tilemap is there but all the new sprites are now invisible

image

Now, go back and remove that viewport container and viewport. You can view all the objects, you can see them together and you can move them together, i.e. you can actually edit and continue creating your game. Add a viewport and you lose everything. Typical use cases for 2D viewports are not just split screen but things like separate hud/tilemap, etc.

image

image

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

  1. Make viewports visible within the editor
  2. Allow editing of items within a viewport
  3. Add some documentation to state viewports don't work without viewportcontainers
  4. Allow viewports to be rendered when the contents are just nodes and not a scene file

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

I don't know, I do not know the internals

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

Yes, because as soon as you add a viewport, your ability to create a game is severely hampered.

@YuriSizov
Copy link
Contributor

YuriSizov commented Jan 17, 2021

Make viewports visible within the editor

There is a reason you need a ViewportContainer control, even though it may not be documented well. Viewports by themselves are render targets. This is useful for abstracting parts of your scene into a texture so that you can use it for various purposes, such as portals, picture in picture, and post production, to name a few. Making them "visible" as is is not possible, because in the editor you see exactly what there is if you don't add a container: nothing.

That said, there should be a way to preview a Viewport without a container, and I think there is already a proposal or an issue for that.

Allow editing of items within a viewport

To the preview window whatever you display in viewport is just a picture. Once again, the editor shows you the final result, where the nodes inside are rasterized and rendered. Making a dedicated scene is your best option. You can make scenes with a simple Node at their root to group your various nodes inside of the Viewport node. Maybe a scene with a Viewport node at its root should also be transparently editable, but I'm not sure it is possible to implement given how viewports operate.

Add some documentation to state viewports don't work without viewportcontainers

As mentioned above, they do work, but they serve a different purpose if they are not inside of a ViewportContainer. People use Viewports for ViewportTexture quite often. But the docs can be improved indeed.

Allow viewports to be rendered when the contents are just nodes and not a scene file

I don't understand what you mean here.


Seems to be related to #1465 and godotengine/godot#20619

@Zireael07
Copy link

Allow viewports to be rendered when the contents are just nodes and not a scene file

He means viewport doesn't render in editor when contents are not in a separate scene (3rd picture in OP)

@YuriSizov
Copy link
Contributor

YuriSizov commented Jan 17, 2021

Allow viewports to be rendered when the contents are just nodes and not a scene file

He means viewport doesn't render in editor when contents are not in a separate scene (3rd picture in OP)

Isn't it the same as

Make viewports visible within the editor

?

(3rd picture in OP)

In this picture the container is not sized properly.

@chucklepie
Copy link
Author

chucklepie commented Jan 17, 2021

@pycbouh
The viewport is sized properly (in this case the size is set to 960x672), as per my description it only displays in the editor when you turn it into a branch. Hence why I simply added a parent container, did nothing and it rendered. But then you lose visibility of other siblings, i.e. you simply cannot view a viewport in Godot properly.

But my whole point is as soon as you start using viewports you lose any ability to properly view and edit siblings and children together underneath the viewport, as per my example screen where i had a tilemaps with some sprites.

In my actual case I'm making two separate views, a tilemap with a camera that is inside a viewport taking up 90% of the screen and a HUD taking up the other 10%. As soon as you put the tilemap in a viewport, you are severely crippled in the editor.

@YuriSizov
Copy link
Contributor

The viewport is sized properly (in this case the size is set to 960x672)

I've said that the container is not sized properly, not the viewport inside of it. A Viewport node is just producing a texture. A ViewportContainer seamlessly displays this texture. For example, you can just as well display that texture with a TextureRect node. Or a Sprite. In your 3rd picture the container has the default size of a small rectangle (40x40 as you claim), so it cannot properly display a 960x672 texture.

But my whole point is as soon as you start using viewports you lose any ability to properly view and edit siblings and children together underneath the viewport, as per my example screen where i had a tilemaps with some sprites.

Yes, because a Viewport node turns everything inside of it into a texture. To the editor it's just that, a texture of the contents of the Viewport node, rendered. If you want to edit what is inside, you make them into dedicated scenes and edit those. Using sub-viewports is an advanced technique so it won't be as straightforward as having nodes directly in your edited scene. You use sub-viewports to render parts of your tree before the rest of it, which is why it works like that.

In my actual case I'm making two separate views, a tilemap with a camera that is inside a viewport taking up 90% of the screen and a HUD taking up the other 10%. As soon as you put the tilemap in a viewport, you are severely crippled in the editor.

In this case it sounds like you can preview everything just fine if you use containers and give them the appropriate size and position. You still won't be able to edit nodes within viewports directly for the reasons provided. Also, CanvasLayers may be a better solution for separating your game branch from your UI branch, if that is the problem you are trying to solve.

@chucklepie
Copy link
Author

@pycbouh
If I do this:
image

Nothing renders to the screen. If I right-click on 'TileMap' and save as branch then it renders. Why?
image

I'm on Linux using 3.2.3, maybe there's a bug if you're saying it should be different or I should be able to edit my tilemap without specifically opening the 'TileMap' scene I had to create and save?

But regarding your CanvasLayer, that does not work because if you have a screen set to say 1024x768 with a tilemap and a camera, the camera/viewport will take up 100% of the screen. If you wanted it to have a HUD taking up the first 100 pixels and the tilemap the rest, even with a simple case of presuming it's full width, you cannot adjust the default viewport co-ordinates.

@clayjohn
Copy link
Member

A properly sized ViewportContainer should display its contents in the editor. The fact that it shows children that are inherited scenes, but not other children shows that there is a bug in the Viewport Container.

IMO this should be a bug report and not a feature proposal.

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