-
-
Notifications
You must be signed in to change notification settings - Fork 97
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
Comments
There is a reason you need a That said, there should be a way to preview a
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
As mentioned above, they do work, but they serve a different purpose if they are not inside of a
I don't understand what you mean here. Seems to be related to #1465 and godotengine/godot#20619 |
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
?
In this picture the container is not sized properly. |
@pycbouh 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. |
I've said that the container is not sized properly, not the viewport inside of it. A
Yes, because a
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, |
@pycbouh Nothing renders to the screen. If I right-click on 'TileMap' and save as branch then it renders. Why? 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. |
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. |
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
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.
Regardless of this missing documentation, and why a container is actually required, add a viewport container:
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?
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
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.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
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.
The text was updated successfully, but these errors were encountered: