Add ThumbnailCamera2D and ThumbnailCamera3D nodes to use for editor scene thumbnail generation

[Calinou]

• Related to Remove scene previews in the inspector #4757 and Allow explicit scene preview image saving godot#17932.

Describe the project you are working on

The Godot editor 🙂

Describe the problem or limitation you are having in your project

Right now, the editor uses the current 2D/3D camera position in the viewport to generate thumbnails. The camera's angle at the moment of saving therefore determines the appearance (and the usefulness) of this thumbnail. As a result, the user lacks control over what's displayed in the generated thumbnails, unless they're willing to go to the same location every time they save the scene. This is obviously not viable for large-scale projects, and even in small-scale projects, it can get pretty tiresome.

If you don't take those specific steps, you'll often get uninformative scene thumbnails in the editor. You can see examples of this in #2493, godotengine/godot#57321, and more.

Having useful scene thumbnails is important, as they're presented throughout the editor in the FileSystem dock, EditorFileDialog, and exported PackedScene properties in the inspector.

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

Add ThumbnailCamera2D and ThumbnailCamera3D nodes to use for editor scene thumbnail generation.
This gives you a more flexibility to generate more useful thumbnails when you need it. You can even use custom sprites as thumbnails by putting a Sprite2D node in full view of a ThumbnailCamera2D node (and hide this Sprite2D when the project is running).

This approach of using a dedicated camera is often used in games that have level editors, so you can always take a screenshot at a given location for the level's preview image. So there's definitely some precedent here 🙂

Question: Could we automatically choose a reasonable camera angle and zoom?

Displaying the entire scene is often not an option for large scenes, and even for smaller scenes, the automatically chosen angle could end up generating uninformative thumbnails. I think manual control will always give you better results, even if you have to put in a few minutes' time to get better thumbnails out of your scenes.

This remains optional in any case, so the current thumbnail saving behavior is used if the current scene doesn't have a ThumbnailCamera2D or ThumbnailCamera3D node.

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

• Add ThumbnailCamera2D and ThumbnailCamera3D nodes (inheriting from Camera2D and Camera3D respectively).
  • Only one ThumbnailCamera node of each type is accounted for per scene. If more than one is present in the given scene, select the first top-level camera of that type, and ignore the rest. This prevents ThumbnailCameras from instanced sub-scenes from interfering.
• These nodes are still available outside of editor builds (to prevent script errors when using their class identifier in scripts), but they have no effect while the project is running.
• If both ThumbnailCamera2D and ThumbnailCamera3D nodes are present in the scene, we can either:
  • Overlay the results of both cameras on top of each other (2D on top of 3D).
  • Have ThumbnailCamera3D take priority over ThumbnailCamera2D, with ThumbnailCamera2D being ignored in this case.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No.

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

This is about improving editor usability, and it probably can't be done with an add-on anyway.

[Wokarol]

You can even use custom sprites as thumbnails by putting a Sprite2D node in full view of a ThumbnailCamera2D node

This is not something that feels good. As an alternative I would suggest having base "Thumbnail" node which provides a texture/image.
This node could be extended for different behaviour like "ThumbnailCamera2D", "ThumbnailCamera3D" or "ThumbnailSprite" nodes. And if needed would allow users to create custom "Thumbnail providers" specific for their games.

[Calinou]

This node could be extended for different behaviour like "ThumbnailCamera2D", "ThumbnailCamera3D" or "ThumbnailSprite" nodes. And if needed would allow users to create custom "Thumbnail providers" specific for their games.

Unfortunately, it's not possible to do this if you also want to inherit Camera2D/Camera3D, as Godot doesn't support multiple inheritance. We absolutely need to inherit Camera2D/Camera3D here to get the various properties and gizmos available (such as FOV and camera preview).

I think the common use case will be to use a camera to show the most important part of the scene anyway, with custom sprites being a rare use case. I mentioned it in passing just in case, but I don't expect it to the main focus of thumbnail generation.

[Wokarol]

Oh right... if Godot supported interfaces it would be doable.
One solution is to define some method that would be found on a node in the scene like "_render_thumbnail". This would allow for said flexibility but would be limited doe to lack of static typing for it.

Other alternative is to just provide "ThumbnailCamera2D", "ThumbnailCamera3D", "ThumbnailSprite" and "ThumbnailCustomBase" which while far from ideal would allow for the flexibility while mantaining static typing.

No matter what, "ThumbnailSprite" would be preferred and option to add custom thumbnail generators would be really nice

[me2beats]

These nodes are still available outside of editor builds (to prevent script errors when using their class identifier in scripts), but they have no effect while the project is running.

will these nodes be in the game, in the nodes tree?

If so, this sounds to me like a good example of having "editor only" nodes meaning they are really editor only
#3433 (comment)

[me2beats]

ThumbnailSprite makes sense imo because you don't need to put it as a child of ThumbnailCamera2D

[me2beats]

I think it also could be useful to have ThumbnailAnimatedSprite that would take a gif or a video for example with a camera flying around the scene

[MewPurPur]

The more I thought about this, the less I liked it.

The philosophy of Godot is to solve problems with small isolated solutions. For example, small raycasts were improved not by letting us control parameters like width and arrow head size, but by adjusting them automatically.

This takes editor-only nodes - something completely new - and solves a small problem. It also asks for the user to do work. I think we should instead improve the previews automatically first, then see if people still want better.

We could for example:

• Add a flag that shows the scene's name on top where the context is missing, like in export vars
• Clamp the camera in the rect where there are things in the scene

Even if we want further improvements, thumbnails have no business being nodes. If you want an icon, you must add it to the real game, which you might not even want. It's better as a setting than having two nodes, one being real, that you add to the SceneTree.

[KoBeWi]

For 2D, rendering the scene at (0, 0) would suffice in most cases (assuming your scenes have default origin). It wouldn't work for big level scenes though, but preview for them is not that important.

[me2beats]

It wouldn't work for big level scenes though, but preview for them is not that important.

Why tho?
When you have many scenes you want to quickly recall what it contain.
The name is not enough sometimes.
You don't want to open each scene to just see what it contains

[MewPurPur]

It's the user's responsibility to make scenes discernible from their names, the thumbnail is more like a bonus. You don't even see it when a scene is opened as a tab until you hover it.

[KoBeWi]

Why tho?
When you have many scenes you want to quickly recall what it contain.

I mean, level scenes are big and you'd need to have some very distinct spot in each of them to make a meaningful thumbnail. If you have e.g. 30 levels, the images will be less helpful than names in most cases. If you have trouble remembering their contents, you can come up with a better way of organizing them, like grouping them in folders.

[Zireael07]

Auto generated thumbnails are often really bad in 3D. In most cases. editor camera placement when opening a 3D scene seems more or less random-ish to me.

Regardless of the "organize"/"remember" thing, it would be nice to have a single consistent thumbnail instead of the current mess (and it would also avoid recreating the thumbnail every time I save)

[Wokarol]

For 2D, rendering the scene at (0, 0) would suffice in most cases

@KoBeWi, I cannot disagree more with you on that. For top down games (like Pokemon) that would either leave half the thumbnail blank or even the whole thumbnail blank if we assume (0, 0) to be top left as Godot does

[ghost]

Add ThumbnailCamera2D and ThumbnailCamera3D nodes to use for editor scene thumbnail generation.
This gives you a more flexibility to generate more useful thumbnails when you need it. You can even use custom sprites as thumbnails by putting a Sprite2D node in full view of a ThumbnailCamera2D node (and hide this Sprite2D when the project is running).

why use 2 nodes when you can use 1? if you want to use "custom sprites as thumbnails" or an image, just add the image as ImageTexture to the (ThumbnailCamera2D) node. like you did with the Sprite.

Displaying the entire scene is often not an option for large scenes, and even for smaller scenes, the automatically chosen angle could end up generating uninformative thumbnails. I think manual control will always give you better results, even if you have to put in a few minutes' time to get better thumbnails out of your scenes.

even with manual control, it's still possible to capture "uninformative thumbnails". just use gimp or the other photo editing software to add text to the "thumbnails" or edit it to make it more informative.

here's what i think, make a new node called "ThumbnailSprite", and make it possible to capture the viewport that i am currently on and save. then i will use gimp or the other photo editing software to edit. then i will put it on "ThumbnailSprite" to display. you will get thumbnails with maximum information in the least time if you did this way. because moving camera3D in Godot is a pain for me, whereas in blender you can just hit ctrl+alt+numpad0 to move active camera3D to view.

It can be solved by ctrl+alt+m to move the selected node to view.

[KoBeWi]

The base problem is that thumbnails are taken from the current view and changed every time.

What if, instead of making a new thumbnail with every save which is useless in most cases, the thumbnail was created only once and then you'd have to refresh it explicitly? Like with "Retake Thumbnail" button somewhere.

Or the opposite. If you are happy with the thumbnail, we could have an option to "lock" it, so that it's no longer updated until you unlock it.

Adding a special node basically means that you'd need such node in every scene to have useful previews.

[ghost]

The more I thought about this, the less I liked it.

The philosophy of Godot is to solve problems with small isolated solutions. For example, small raycasts were improved not by letting us control parameters like width and arrow head size, but by adjusting them automatically.

This takes editor-only nodes - something completely new - and solves a small problem. It also asks for the user to do work. I think we should instead improve the previews automatically first, then see if people still want better.

We could for example:

• Add a flag that shows the scene's name on top where the context is missing, like in export vars
• Clamp the camera in the rect where there are things in the scene

Even if we want further improvements, thumbnails have no business being nodes. If you want an icon, you must add it to the real game, which you might not even want. It's better as a setting than having two nodes, one being real, that you add to the SceneTree.

I agree with this. the "Thumbnail" thing should be a setting or per scene only. not a node that gets instanced to unneeded parent scene. because my "WorldEnvironment" nodes for the model's color check get instanced to the parent scene when I don't want to.

The base problem is that thumbnails are taken from the current view and changed every time.

What if, instead of making a new thumbnail with every save which is useless in most cases, the thumbnail was created only once and then you'd have to refresh it explicitly? Like with "Retake Thumbnail" button somewhere.

Or the opposite. If you are happy with the thumbnail, we could have an option to "lock" it, so that it's no longer updated until you unlock it.

Adding a special node basically means that you'd need such node in every scene to have useful previews.

I liked the idea of refreshing the thumbnail explicitly than auto-refreshing the thumbnail. because refreshing the thumbnail is destructive edit. but if you don't update, it could be a misleading representation of the scene. Making an option for auto-refreshing thumbnails sounds better for me.

[xix-xeaon]

Requiring users to manually add and configure special camera-nodes to every single scene in order to not have absolutely terrible thumbnails is frankly quite ludicrous.

For large scenes, like entire levels, it might sometimes make sense to manually configure the thumbnail. I don't think nodes are the way to go though - sure it would allow for a lot of functionality but it's complicated (to use) but rarely needed - just add a menu option (under tools?) for configuring manual thumbnail for the current scene.

First PR would simply either capture the editor camera settings (position and rotation mostly) and it'll use that when updating the thumbnail on save, or if there's already a manual setting it would clear it. The text for the option would reflect this. And then maybe, a second PR could instead open a dialog with various options for the thumbnail of this scene, and you can choose current editor camera or any other (normal) camera in the scene (including showing a preview) and if it should update the thumbnail on every save or just keep it until manually updated again, or select a custom image, or clear the setting (making it automatic again).

However, every "game object" is generally also going to be its own scene. That means most scenes will often be small scenes, including only a chair, a tree or similar, and that can easily be previewed automatically. The default thumbnail should be generated by calculating the AABB of the scene and automatically capture it from an angle (for 3D, no angle for 2D obviously). You can have settings for changing the angle, zoom level, etc but they're global settings.

I want decent thumbnails for my large scenes but I don't need them because I find them quicker by searching for their name. However, I need decent thumbnails for all my small scenes, because I'm building a level and I need to find that specific tree with that weirdly shaped trunk among hundreds of game objects and I don't know what it's name is, and there are several scenes named "tree"-something. Or, I need to browse all the different trees to choose one that fits. I've only just started on a larger project and this is already hurting my productivity.

Thumbnails should absolutely not be configured manually unless you absolutely have to. You may have to for a large scene, but with the automatic option you also may not have to, even for large scenes. Small scenes should pretty much always give good thumbnails automatically.

The current scene thumbnails are almost always bad. They also include gizmos, cluttering them up and making them even less useful. They were probably not even "designed" to act as thumbnails for scenes in general. They were probably just used as previews for the open tabs (for which they kind of make sense) and it was just easy to use them for thumbnails as well because it's slightly better than absolutely nothing.

[JoNax97]

Agree 100% with @xix-xeaon.

I think the approach of automatic AABB at a reasonable angle (probably top-down, looking at the top-left-front of the AABB) plus a shortcut to override this angle with the current editor camera's position would cover almost every case for 3D.

[Mickeon]

Upon more thought, a Node to just do this sounds somewhat excessive. It'd almost be present in all scenes anyhow. If I may share a suggestion on the matter, perhaps the information on how the preview was generated (particularly position and angle) could be stored inside the metadata of the Scene on the moment the thumbnail needs to be generated. This way, the preview will still remain (relatively) consistent across the same project in different systems, and could automatically update based on changes while still keeping the same position, without bloating the project with the raw image thumbnails.

[Wokarol]

@Mickeon , that sounds wonderful. Although it's a good point to rethink how and when Godot renders previews. As currently it's less that ideal and usually you have to open and save the scene for it to generate a thumbnail. Maybe caching it in temporary folder would be beneficial, then the metadata would only store the version of the file and if that changes, the thumbnail would be regenerated the first time asset is shown in UI anywhere

[Mickeon]

And I believed the thumbnail, once generated, was already cached somewhere, but I suppose I was entirely wrong? Either way, caching the image for each user would be expected for a system like this.

[Wokarol]

And I believed the thumbnail, once generated, was already cached somewhere, but I suppose I was entirely wrong? Either way, caching the image for each user would be expected for a system like this.

I'm pretty sure that is/was not the case as my project had thumbnails cleared after every editor restart

[ztc0611]

I honestly wouldn't mind the preposed thumbnail node for fine tuning, but at this point I'd take basically any fix for thumbnails. They're practically useless in their current iteration and seem more bugged than anything else. (See godotengine/godot#57321 mentioned in the OG post in which I actually thought I was experiencing a bug with them...) It's kind of a shame that they won't get fixed until 4.1 at the earliest.

[Wokarol]

@ztc0611 , I would even risk saying that it not only does not help, it actively harms by workflow

[ztc0611]

@Wokarol I definitely disagree, I believe a version that functions more coherently would be an incredible improvement in the UI of Godot. Sure, I know where my files are, but my eyes are always going to be drawn more to a picture of my game's protagonist than "Protag.tscn"

[Wokarol]

@ztc0611, due to the nature of my games. Most of my thumbnails either don't show anything or show something useless. And just having a name would be way simpler to work with

[Zireael07]

Same experience as @Wokarol: 99% of the thumbnails show nothing or something useless.

[Gnumaru]

What about, instead of automatically generating a thumbnail when saving the scene, we turn the thumbnail generation an explicit menu item or gui button? The logic for the thumbnail generation would still be the same, but instead of generating them automatically, the thumbnails would only be generated and updated when the user itself positions the editor viewport in a way he likes it and then presses a "save thumbnail" button or menu item.

[Calinou]

What about, instead of automatically generating a thumbnail when saving the scene, we turn the thumbnail generation an explicit menu item or gui button? The logic for the thumbnail generation would still be the same, but instead of generating them automatically, the thumbnails would only be generated and updated when the user itself positions the editor viewport in a way he likes it and then presses a "save thumbnail" button or menu item.

Unfortunately, this would make thumbnails non-deterministic across different users on the same project. We should avoid saving thumbnails in version control as it'd bloat it with additional binary files (which don't version well in Git).

[Deozaan]

Unfortunately, this would make thumbnails non-deterministic across different users on the same project.

Isn't the current behavior of generating thumbnails every time the scene is saved also non-deterministic across different users on the same project?

At least if it was an explicit action you would only need to position the camera and generate the thumbnail once to get a decent (local) image instead of having to always do it (which, as you said, is tiresome) or more likely just accept having garbage thumbnails from entirely different scenes.

[Calinou]

Isn't the current behavior of generating thumbnails every time the scene is saved also non-deterministic across different users on the same project?

Indeed, I consider it to be a problem we should resolve in the long run 🙂

[JoNax97]

I'd like to try and make an implementation based on the comments above. Should I open a new proposal describing the details?

[Calinou]

I'd like to try and make an implementation based on the comments above. Should I open a new proposal describing the details?

If your proposal varies significantly from mine, I suggest opening a separate proposal indeed.

[eddieataberk]

any updates on this?

[Calinou]

any updates on this?

To my knowledge, nobody is currently working on implementing this. That said, #7232 is likely a better solution to the original problem, so I'll close this proposal in favor of #7232.