New slots system in render view

Here is my complete proposal, with two different designs, please let me know if you find something weird or if you have other ideas.

This proposal is aiming to improve the Render Slots System in Blender 2.8, by creating a more standard and practicle frame buffer.

WHY ?
The current system works fine but it has a few limitations :

  • It has a limit of 10 Slots
  • You have to change the Slots you want to render to before actually rendering
    Also the render view is missing a few features, like being able to easily compare two of your renders and being able to quickly adjust the exposure of the render. (maybe this has to be part of another proposal ?)



PROPOSAL
The idea is to implement a frame buffer that resize dynamically :
Each time you render an image, it overwrites the previous one if you do nothing.
While the rendered image is displayed, you can at any time click a button to add it to the frame buffer. The list of images in the frame buffer would expand automatically so you can have as many images as you want.
An option is available in the user preferences (or in the render view) to put automatically every render in the frame buffer.

At any time, it is possible to walk through all the images stored in the frame buffer.


If one of the images of the frame buffer is displayed in the render view, you can click a button to set is as background, so that you can put any other image on top in order to compare the two.
Then, you can choose the comparison mode in a list (alpha over, slider, substraction …).
In the frame buffer list, icons inform you of which image is set as background, and which one is displayed.


To adjust the exposure, a slider is available in the header of the render view, with a button to switch between the original value and and the modified value.

DESIGN (comparison between images and exposure tweaks do not appear here)

Addition to the current design :

  • Add button (+) : Enable when the displayed image is not in the frame buffer, allows you to put it in the frame buffer.

  • Delete button (-) : Enable when the displayed image is already in the frame buffer, allows you to delete the displayed image from the frame buffer.
    These two buttons could work like the design of William Reynish maybe ? https://dev-files.blender.org/file/data/bc7rfdyh6y7qb3azutdw/PHID-FILE-enjhhtnnwt6xkm7tpcgr/menus_with_add_delete.gif

  • Set as background button : Enable when the displayed image is already in the frame buffer, sticks the displayed image as a background, after that if you render a new image or change the displayed image by another slot, this one appears in background (can be used for that https://blender.community/c/rightclickselect/7cbbbc/)
    If the displayed image is the one that is set as background, the button can be used to remove the image as background.

If the displayed render is not in the frame buffer, it can be in a temp slot, named explicitly so that we know that it is not in the frame buffer.

The last render putted in the frame buffer has always the highest number (do the slots can be renamed ?)

IDEA 1 :


This first idea keeps the current design. The idea is just to add the buttons in the header.

IDEA 2 :


This design is a bit more practical, it is better if there is a lot of images in the frame buffer, and it is more accessible.

What I’m missing in the design is the efficiency of what we have now. You just press J to render to the other slot, then J to quickly compare. No need to add a slot, clean up old slots to save memory, set a background. It should be possible to keep that quick workflow within a new design, though I’m not immediately sure what the best solution is.

Other points:

  • I think there should be a limit on the number of slots, otherwise memory usage will keep going up. I don’t think users will remember to manually remove renders to save memory, or even want to do this management. The limit could be adjusted in the user preferences if needed. Working with a very high number of slots is probably not a good idea as long as closing the .blend removes all that data? I’m kind of wondering what the practical use cases are for working with more than 2 or 3 slots and how that should influence the design.
  • For comparisons, probably we should just name the operator “compare with” or something more direct like that, instead of “set as background”. I don’t think we need a lot of comparison modes, maybe just a slider and flipping like J key would be ok?
  • It’s not clear to me why exposure is part of this design, assuming that’s the same exposure as found in color management. I can see it would be useful to compare different color management settings, but also not always and there’s more settings than exposure.
  • I guess users will want a panel or region where it shows all the slots with little preview images, so a separate panel in the N key properties may be a good step towards that. If we do that there should still be an indication of which slot is being shown when the panel is not visible though, maybe just in the render info text.
  • Pressing J could be kept to have a quick comparison between the image we are comparing with and the last rendered image (or with the last selected image in the list ?)
  • Yes I agree that it is not necessary to keep a lot of images in memory, so it could be a first in first out type of list, so that after for example 5 images in the frame buffer, the older image would be deleted as you push a new one. No the images are not saved with the .blend.
  • For comparison I agree with the name (I didn’t really find something good haha). For the modes I would suggest four modes :
    • quick mode (switch between the to images)
    • slider mode
    • alpha over ? (to be able the render a region and have the previous image staying behind, but it doesn’t have to be a mode maybe ?)
    • difference mode (absolute(B-A), can be useful for some fx for example to spot easily slight differences, I know it is a comparison mode available in sone other softwares)
  • For the exposure, I think it can be useful just to see some parts of image that are in the dark, or to quickly have a good preview of the Z pass ? Doesn’t have to do with color management. It is not necessary but it can be useful, but maybe if it is something to do, it can be done in an addon.
  • Ok, so should we have the list in the header and the list in N panel ? Or just the list in N panel, and the name of the image in the header ?

It seems Lukas was working on improvements in this area as well, patch here to add/remove slots:
https://developer.blender.org/D3474

Still only a first step towards what is being proposed here though.

Right. If we have only 2 slots by default, I guess the second slot would automatically be selected for comparison and J key would work as before without any slot.

The other thing it allowed you to do is select which slot to render to, but perhaps that can be replaced with a shortcut key to push the last render to the second slot and set if for comparison.

Quick/slider/difference seems ok. For alpha over, I think render a region while keeping the rest is a different feature, not really related to slots, it should work with a single slot too.

Exposure controls in the image editor instead of having to go to the scene properties could be convenient, but seems unrelated to render slots.

Probably it’s fine if we have the list in both the header and N panel.

Great ! Thanks a lot for taking the time to answer my question. I think that I have all the informations I need to a more complete design and start trying some things with the code. Should I publish the design as a task on developer.blender.org or keep it here ?

It’s fine here I think, once you have some code to submit you can put it in the differential revision summary.

1 Like

PROPOSAL UPDATE
The idea is to implement a frame buffer that resize dynamically :
Each time you render an image, it renders on a “Render” slot which you can not delete.
While the rendered image is displayed, you can at any time click a “Push” button to add it to the frame buffer.
An option is available in the user preferences (or in the render view) to put automatically every render in the frame buffer.

At any time, it is possible to walk through all the images stored in the frame buffer.

If one of the images of the frame buffer is displayed in the render view, you can click a toggle to compare this image with any other image of the frame buffer.
Then, you can choose the comparison mode in a list :

In the frame buffer list, icons inform you of which image is compared, and which one is displayed.

By default, the comparison mode will be set on Quick mode, and the Slot 1 (see design below) will have his “Compare With” toggle ON.

DESIGN

Addition to the current design :

  • Push button : When you click, if there is an image in the last slot, it is deleted, all the images of the frame buffer are offset by 1 slot, and a copy of the rendered image is pushed in the first slot of the frame buffer.

  • Compare With toggle : Enable when the displayed image is already in the frame buffer, sticks the displayed image as a background, after that if you render a new image or change the displayed image by another slot, this one appears in background (can be used for that https://blender.community/c/rightclickselect/7cbbbc/)
    If the displayed image is the one that is set as background, the button can be used to remove the image as background.

  • Comparison Mode menu : Choose between the three different comparison mode (quick, slider and difference)

I added thumbnails in the slot list, so we can have a quick preview of what is inside each slot.

7 Likes

It all seems quite reasonable.

I’d put the Compare With setting in the Render Slots panel, doesn’t need to be always visible in the header I think. The push button could be next to the slots menu in the header to make the relation clear, and should probably get an icon.

1 Like

What do you think about having an option to have the slots saved to disk (multilayer EXR of course)? so they could be retrieved also when re-opening the file.
It could work very similar to how caching does in other areas (particles, physics…). A simple “Save to disk” check-mark would enable this. A Clear All button would be the equivalent of Free all bakes.
Or as an alternative: next to each render slot, we may have a selectable harddrive icon, which of course would make that slot written onto disk. edit: anyway it should be clearly readable that files get written on the hard drive, making the user aware, and giving the opportunity to easily erase them.
Folder destination as you wish: automatic as caches, next to file, temp folder (with a hash to know which file each slot belongs to), or just settable.

We need the possibility to see passes directly in the renderview.

image

1 Like

That could be a good idea, I am gonna try to get this first part done before starting anything a bit bigger. But I keep the idea in mind. Brecht already mentioned saving the images on the disk :

It is already available, it is on “Combined” by default but if you enable passes in your renderlayer settings you can access them here.

1 Like

Unless you mean in the rendered viewport, which would be very cool, but not related with this task

@thornydre ok thanks

These ideas are all great. The most useful to me would be automatically creating new slots. I’m always overwriting renders that I intended to keep because I forgot to save or change slots before I pressed F12. Retaining the previous render when rendering with boarder is also great. I missed this feature when switching from Mental Ray to Cycles. It truly is a time saver when rendering complex, high res scenes and you see one small item you want to change. There have been many times I’ve had to restart a 30 minute render just make small changes that only effect one small part of the image - or render boarder and have to composite it back in manually.

I agree with brecht that the slots should be limited, but I think the number should be higher than 3 slots. I think 10 would be more helpful for doing interior stills for clients, but I appreciate that using too many can kill memory usage, so it may be worth considering allowing the user to adjust this to his or her liking.

1 Like

The thing I am trying to do at the moment is that you can (automatically or manually) offset all the images in the slot so that when you render again it saves your render (without having to change the slot before rendering). For the number of slots, you can already choose it in blender 2.8, you can add and delete slots as you wish :slight_smile:

That’s definitely a good start. I’m thinking about two different scenarios where having to manually delete slots may not be good:

  1. new users who don’t know that they need to do this. They spend all day trying different renders in a single file and their memory and/or disk space is filled up with 4k EXRs.
  2. experienced users who spend all day making renders and realize they have to, under a tight deadline, go back and have to manually delete multiple slots to free up memory.

Even experienced users who develop their renders in preview mode may not see some issues with the render until the samples and resolution are pushed way up to final render settings. Will border renders take up new slots? These scenarios add to the memory usage and time required to clean up slots.

I say this understanding that first steps are important. Automatic slot creation will be a great feature.

No the slots won’t be automatically created, at the moment you can already manually create or remove slots, even empty a slot. With my proposal let’s say that you have 5 slots, all the slots have already an image in them. When you press the push button (this can be done automatically when you render a new image), the 5th slot is emptied, then the image of the 4th slot goes into the 5th, the 3rd into the 4th, … , and your render goes into the 1st slot. And the render will always be done in another slot called Render slot. (don’t know if this is clearer haha). So yes now, border renders will be considered like a normal render and will override the entire render slot.

I misunderstood. I thought you were moving away from that idea. Proceed. :slight_smile:

@brecht I have a quick question about how the images and the slots are handled in the code (if it is all right aking about it here ?) :

Does the image in each slot stored in RenderSlot → render ?
If not, is it possible to access each image from Image → renderslots or is there a better way ?

Maybe it is silly questions but I am not sure of how the images and the slots are linked, I style playing with the code to find out, but if you have any clue about it :slight_smile:

There is a RenderResult that stores all the render layers and passes resulting from a render. These are indeed stored in RenderSlot.render, with one exception. The active render is stored elsewhere and owned by the rendering pipeline. It is accessed through RE_AcquireResultImage / RE_ReleaseResultImage for thread safety while the renderer is changing it.

1 Like