AThousandShips
commented
1 month ago Open ItzCog opened 1 month ago
AThousandShips
commented
1 month ago 
salianifo
commented
1 month ago Node2D thumbnail centered at (0, 0), and the Control thumbnails adjust to the screen size.PackedScene as some kind of meta data (someone mentioned about making sure thumbnail generation was deterministic for multiple users on the same project, so this could be a way to achieve that potentially). The terminology for the menu options should refer to camera transform rather than camera angle & position, though.
Quick Edit: right after I submitted this I found out that there are several issues very similar to this one. (most importantly #7232, also a bunch of its predecessors) for some reason all of those went completely under my radar when I was searching about similar topics before I started writing š Still there are some independent value in this issue (a specific design for one "tool" mentioned in that issue, also some inspector specific stuff) so it could probably at least stay open for a while
Describe the project you are working on
The real-world project: a card game with dozens of different card types, each of them is saved as a scene file. There are also a bunch of levels, stored as a scene file as well.
This game uses packed scene references extensively. A list of packed scene fields are used for the CPU opponent's deck, and each level also stores reference to other levels as the game requires.
Describe the problem or limitation you are having in your project
The current packed scene preview is way less instructive than it should have been. The scene thumbnail uses whatever you would see when saving the scene, which is not ideal for quickly pinpointing exactly what scene file is referenced.
A quick example:
If someone else on the team passed this to me, the only thing I would know by looking at the images is that these are two different scenes. I wouldn't know if the two are swapped unintentionally, or if any of them is pointing to a completely wrong level. (for this game specifically, the narrative design is that you spend the whole gameplay inside the same room so distinguishing levels by visual is also not very effective)
And every once in a while, you might get a completely unhelpful thumbnail like this:
I know it's possible to just hover the mouse cursor above the field to see the file path, or just make sure the viewport is right before saving the file every time, but that would slow down the workflow significantly, and I believe an editor with well-designed user experience should not be relying on those as the only solution. (I myself certainly wouldn't want to hover cursor and wait for one second over each of a 40-card deck)
Also, for scenes with no visuals, the thumbnail would be just a full black rectangle, which is pointless as well.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
A set of changes to make packed scene preview more straightforward.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
(the following images are made with mostly poor image editing techniques so they don't look as good as they're supposed to be, but it should be enough for you to get the idea)
This way, it would be easier to know which scene is referenced, regardless of what is going on with the thumbnail. Even with the other thumbnail improvements added, this can still be valuable e.g. for larger projects where it can be hard to memorize all the visuals, or in early development phase where the visuals are just a bunch of graybox prototype model that don't represent their behavior very well.
For a scene without any visuals, the thumbnail won't really provide any additional info so it's probably better to only display the root node (I think the scene icon is enough to distinguish it from a node path property):
Keep the behavior of refreshing the thumbnail each time on save, but instead of using the viewport's camera at the moment, use a fixed camera position & angle as default.
For 3D scenes, use some predetermined position & distancing in the first octant; for 2D scenes, place the camera at (0, 0); for UI, position the camera so that (0, 0) is on the top-left corner of the thumbnail and adjust the zoom according to the screen size, etc.
For the times when the default camera position & angle mentioned above does not fit, an extra option to allow customizing thumbnail camera (that's not just using the position at save) can be used. Below is one possible example I came up with, where the options are placed under the view menu:
These can also be assigned with a hotkey if appropriate.
If the user wants to frequently edit this camera and going to this menu repeatedly turns out to be too slow, an option can be added to editor settings to let the user go back to using save to decide camera position if they want to.
If this enhancement will not be used often, can it be worked around with a few lines of script?
No.
As far as I know, custom thumbnails seem possible with editor plugins but you would need to make a screenshot for each of your scene manually. Would probably create an unrealistic amount of extra workload for any mid-to-large-scale project.
Is there a reason why this should be core and not an add-on in the asset library?
This proposal would improve out-of-the-box experience for almost every project and therefore is best implemented in the core.
Also, an exact recreation of the design mentioned above as an add-on might not be technically possible because the relevant class members are not public in the core code.