Render Queue #88624

New Issue

Colin Marmond · 2021-05-27T12:17:18+02:00

Colin Marmond commented

2021-05-27 12:17:18 +02:00

The renderqueue panel is a new panel to organise and plan shots to render.

Why ?

Case 1 :
The sampling can be high, to have a good quality, but at cost of render time. When an artist have differents view to render with differents objects shown; it takes a lot of time to render first view, wait for render to finish, then render another view (eventually hide/show some objects, change frame), etc.

In this case, it is useful to have all the renders doing one by one automatically.

Case 2 :
The artist rendered at low samples different views, with different compositions. Then, the client want a specific composition. The artist have to manually hide/show the objects to change the composition, change the world...

In this case, it is useful to have a list of overridden settings ( view layer, frame, camera, etc ) to easily recover a view/composition.

Who will need it ?

As described previously, it will benefits to every artists. A huge benefit for artists working with cycles or other path tracing render engine.

A proposed solution

Internally

The data of each shot is stored into a new type structure.
That structure is overriding some scene settings and render settings.
The proposed settings are :

frame
camera (object & settings)
- exposure
- focus distance
resolution and ratio
viewlayer

User Experience

The renderqueue list is located in a new panel inside properties editor. It is a list of shots, that have each a different name.
The user can then select some settings to override, and modify them.
The user can then render all the shots automatically or just some.
All the renders are then automatically saved using the shot name.

Pros

This system makes it easy to add new overridable settings, and offer a large choice of possibilities.

Cons

This override system is not easy to do, because of the complexity of view layers(visibility, etc), and require a lot of work.

Alternative solutions

Shot by camera

Each camera can contain overrides of some scene and render settings (sampling, exposure, resolution, viewlayer, etc).

Pros :
This is a bit simpler on the user side.
Cons :
This is restrictive, because the user can only define one shot per camera.

Shot by viewlayer

Each viewlayer can contain overrides of some scene and render settings (sampling, exposure, resolution, camera, etc).

Pros :
This is easier to implement, because all the viewlayer side is already done in blender.
Cons :
This gives too much viewlayers in the blender file. The user may not want to override the viewlayer.

The strategy for the proposed method

Create a new structure type : RenderQueue.
This structure will first contain two of the elemental elements : the camera and the frame.
Each element has a flag associated, to define if it is used; ex : USE_CUSTOM_FRAME
Each element is shown in its category, in the RenderQueue property panel.
Once this little design is done, we should be able to think about layer overriding.

Mockups

The renderqueue panel is a new panel to organise and plan shots to render. ___ Why ? ## - Case 1 : The sampling can be high, to have a good quality, but at cost of render time. When an artist have differents view to render with differents objects shown; it takes a lot of time to render first view, wait for render to finish, then render another view (eventually hide/show some objects, change frame), etc. In this case, it is useful to have all the renders doing one by one automatically. - Case 2 : The artist rendered at low samples different views, with different compositions. Then, the client want a specific composition. The artist have to manually hide/show the objects to change the composition, change the world... In this case, it is useful to have a list of overridden settings ( view layer, frame, camera, etc ) to easily recover a view/composition. Who will need it ? ## As described previously, it will benefits to every artists. A huge benefit for artists working with cycles or other path tracing render engine. ___ A proposed solution ## Internally ------ The data of each shot is stored into a new type structure. That structure is overriding some scene settings and render settings. The proposed settings are : * frame * camera (object & settings) - exposure - focus distance * resolution and ratio * viewlayer User Experience ------ The renderqueue list is located in a new panel inside properties editor. It is a list of shots, that have each a different name. The user can then select some settings to override, and modify them. The user can then render all the shots automatically or just some. All the renders are then automatically saved using the shot name. Pros ------ This system makes it easy to add new overridable settings, and offer a large choice of possibilities. Cons ------ This override system is not easy to do, because of the complexity of view layers(visibility, etc), and require a lot of work. ___ Alternative solutions ## Shot by camera ------ Each camera can contain overrides of some scene and render settings (sampling, exposure, resolution, viewlayer, etc). - Pros : This is a bit simpler on the user side. - Cons : This is restrictive, because the user can only define one shot per camera. Shot by viewlayer ------ Each viewlayer can contain overrides of some scene and render settings (sampling, exposure, resolution, camera, etc). - Pros : This is easier to implement, because all the viewlayer side is already done in blender. - Cons : This gives too much viewlayers in the blender file. The user may not want to override the viewlayer. ___ The strategy for the proposed method ## Create a new structure type : RenderQueue. This structure will first contain two of the elemental elements : the camera and the frame. Each element has a flag associated, to define if it is used; ex : USE_CUSTOM_FRAME Each element is shown in its category, in the RenderQueue property panel. Once this little design is done, we should be able to think about layer overriding. ___ Mockups ------ ![Screenshot_20210527_130757.png](https://archive.blender.org/developer/F10144821/Screenshot_20210527_130757.png)

Colin Marmond commented

2021-05-27 12:17:18 +02:00

Added subscriber: @Kdaf

kathybowing commented

2021-05-27 13:18:02 +02:00

(Migrated from localhost:3001)

Added subscriber: @kathybowing

Brecht Van Lommel commented

2021-05-27 13:37:18 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2021-05-27 13:37:18 +02:00

This is what view layers were designed for. That system should be improved, and get more powerful support for overrides, rather than adding another mechanism.

The name is also confusing, since in some other 3d apps the "render queue" is a job scheduling system.

Overall, I think this design is not the right direction.

This is what view layers were designed for. That system should be improved, and get more powerful support for overrides, rather than adding another mechanism. The name is also confusing, since in some other 3d apps the "render queue" is a job scheduling system. Overall, I think this design is not the right direction.

Colin Marmond commented

2021-05-27 14:08:09 +02:00

In #88624#1167046, @brecht wrote:
Overall, I think this design is not the right direction.

Alright, no problem, have you got any idea of how a Render/Shot Queue could work ?
I mean, you said viewlayers are made for this. But we cant even change camera by view layer. Is it in this direction that it could go ?
Making a kind of Shot by viewlayer as I mentionned ?

> In #88624#1167046, @brecht wrote: > Overall, I think this design is not the right direction. Alright, no problem, have you got any idea of how a Render/Shot Queue could work ? I mean, you said viewlayers are made for this. But we cant even change camera by view layer. Is it in this direction that it could go ? Making a kind of Shot by viewlayer as I mentionned ?

Brecht Van Lommel commented

2021-05-27 14:21:36 +02:00

Ideally view layers would support a more generic override mechanism, where any scene property can be overridden. But that is rather complicated to implement well.

Adding a few more options to the Overrides panel would be a good step. Currently that only has material and samples, adding a camera override there would make sense.

Ideally view layers would support a more generic override mechanism, where any scene property can be overridden. But that is rather complicated to implement well. Adding a few more options to the Overrides panel would be a good step. Currently that only has material and samples, adding a camera override there would make sense.

Colin Marmond commented

2021-05-27 14:23:11 +02:00

Do you think I could make that ( adding camera override ) ? Or is it part of a larger change ?

kathybowing commented

2021-05-27 14:25:29 +02:00

(Migrated from localhost:3001)

Removed subscriber: @kathybowing

Brecht Van Lommel commented

2021-05-27 15:05:53 +02:00

You could implement that yes.

Colin Marmond commented

2021-05-27 16:40:29 +02:00

Changed status from 'Needs Triage' to: 'Archived'

Colin Marmond closed this issue

2021-05-27 16:40:29 +02:00

Juan Gea commented

2021-05-28 13:19:00 +02:00

Added subscriber: @juang3d

Juan Gea commented

2021-05-28 13:19:00 +02:00

Regarding this @brecht I think there are two perspectives here:

The Per Camera one: that's a good one, because we often need to render several cameras in a scene, imagine a pack shot, or having to render several static cameras of different places in a set, or having a bunch of detail renders of a character, right now there are rudimentary ways to do that, but a camera queue would allow us to avoid all this.
The View Layer perspective: that one would make useless the view layers as a scene separation element, so I kind of agree that this sould not be used in this way.

With that said there is a point regarding the Per Camera idea:

While ViewLayers are defined to be able to generate overrides in the scene, there are scenes with several ViewLayers that have to be rendered from different cameras with different resolutions, picture this structure for example:

ViewLayer: Character
ViewLayer: Set
ViewLayer: Background Set
ViewLayer: VERY High resolution 2D background

All that will be used inside the compositor to assemble the final beauty image.

Now if we need to render a collection of static pictures of that situation we have the two approaches here:

Per Camera: we have the camera lists, each camera will render it's own sets of view layers, the only main override a camera would need would be the resolution, because you often need to render different sizes, vertical/horizontal, with different proportions, etc...
However a samples override per camera could come handy, but if it's too out of scope can be totally discarded
Per ViewLayer: in this situation the queue would be useless, because the previews compositing view layer setup would render useless, it could generate a ton of view layers but we won't be able to use our composite configuration or we will be forced to configure one specific compositing tree per camera, which is a problem too and not efficient at all.

So IMHO the Per Camera approach is the best one, I agree with keeping it as simple as possible, so it can be just a camera queue with a resolution setting per camera, nothing less nothing more.

But the Per ViewLayer approach would make View Layers useless if they have to be used with the compositor or with a scene with several view layers.

Regarding the overrides, this could be a different proposal with a different design that later could be combined with ViewLayers and/or with the Camera Queue :)

Regarding this @brecht I think there are two perspectives here: - The Per Camera one: that's a good one, because we often need to render several cameras in a scene, imagine a pack shot, or having to render several static cameras of different places in a set, or having a bunch of detail renders of a character, right now there are rudimentary ways to do that, but a camera queue would allow us to avoid all this. - The View Layer perspective: that one would make useless the view layers as a scene separation element, so I kind of agree that this sould not be used in this way. With that said there is a point regarding the Per Camera idea: While ViewLayers are defined to be able to generate overrides in the scene, there are scenes with several ViewLayers that have to be rendered from different cameras with different resolutions, picture this structure for example: - ViewLayer: Character - ViewLayer: Set - ViewLayer: Background Set - ViewLayer: VERY High resolution 2D background All that will be used inside the compositor to assemble the final beauty image. Now if we need to render a collection of static pictures of that situation we have the two approaches here: - Per Camera: we have the camera lists, each camera will render it's own sets of view layers, the only main override a camera would need would be the resolution, because you often need to render different sizes, vertical/horizontal, with different proportions, etc... However a samples override per camera could come handy, but if it's too out of scope can be totally discarded - Per ViewLayer: in this situation the queue would be useless, because the previews compositing view layer setup would render useless, it could generate a ton of view layers but we won't be able to use our composite configuration or we will be forced to configure one specific compositing tree per camera, which is a problem too and not efficient at all. So IMHO the Per Camera approach is the best one, I agree with keeping it as simple as possible, so it can be just a camera queue with a resolution setting per camera, nothing less nothing more. But the Per ViewLayer approach would make View Layers useless if they have to be used with the compositor or with a scene with several view layers. Regarding the overrides, this could be a different proposal with a different design that later could be combined with ViewLayers and/or with the Camera Queue :)

daniele mammoli commented

2022-07-21 15:45:36 +02:00

Added subscriber: @Dae_mmm

daniele mammoli commented

2022-07-21 15:45:36 +02:00

layer manager might be the way to handle what he described, but render queue has a different meaning:
with a render queue you can decide to render:
from frame 1 to frame 100
from frame 300 to frame 500
Have a still of frame 1 in 4k
Have a still of frame 300 in 4k
Have from frame 100 to 700 of file "LoremIpsum.blend"
Have a still of frame 150 of file "LoremIpsum.blend"

After setting all up you can click on "start queue" and have everything later

layer manager might be the way to handle what he described, but render queue has a different meaning: with a render queue you can decide to render: from frame 1 to frame 100 from frame 300 to frame 500 Have a still of frame 1 in 4k Have a still of frame 300 in 4k Have from frame 100 to 700 of file "LoremIpsum.blend" Have a still of frame 150 of file "LoremIpsum.blend" After setting all up you can click on "start queue" and have everything later

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Render Queue #88624

Internally

User Experience

Pros

Cons

Shot by camera

Shot by viewlayer

Mockups