2012-04-30 14:24:11 +00:00
|
|
|
/*
|
2012-01-05 17:50:09 +00:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
2018-06-01 18:19:39 +02:00
|
|
|
* of the License, or (at your option) any later version.
|
2012-01-05 17:50:09 +00:00
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2006 Blender Foundation.
|
|
|
|
* All rights reserved.
|
|
|
|
*/
|
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
* \ingroup render
|
2012-01-05 17:50:09 +00:00
|
|
|
*/
|
|
|
|
|
2020-03-19 09:33:03 +01:00
|
|
|
#include <errno.h>
|
2012-01-05 17:50:09 +00:00
|
|
|
#include <stdio.h>
|
2012-09-04 18:27:47 +00:00
|
|
|
#include <stdlib.h>
|
2012-01-05 17:50:09 +00:00
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
2019-05-19 21:51:18 +02:00
|
|
|
#include "BLI_ghash.h"
|
2014-11-14 11:00:10 +01:00
|
|
|
#include "BLI_hash_md5.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLI_listbase.h"
|
2012-01-05 17:50:09 +00:00
|
|
|
#include "BLI_path_util.h"
|
2012-08-20 15:29:02 +00:00
|
|
|
#include "BLI_rect.h"
|
2012-01-05 17:50:09 +00:00
|
|
|
#include "BLI_string.h"
|
2020-03-04 15:12:36 +11:00
|
|
|
#include "BLI_string_utils.h"
|
2012-01-05 17:50:09 +00:00
|
|
|
#include "BLI_threads.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLI_utildefines.h"
|
2012-01-05 17:50:09 +00:00
|
|
|
|
2017-11-14 17:23:40 +11:00
|
|
|
#include "BKE_appdir.h"
|
2018-11-07 15:37:31 +01:00
|
|
|
#include "BKE_camera.h"
|
2013-01-10 16:37:48 +00:00
|
|
|
#include "BKE_global.h"
|
2018-11-07 15:37:31 +01:00
|
|
|
#include "BKE_image.h"
|
2013-01-10 16:37:48 +00:00
|
|
|
#include "BKE_report.h"
|
2015-04-06 10:40:12 -03:00
|
|
|
#include "BKE_scene.h"
|
2013-01-10 16:37:48 +00:00
|
|
|
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "IMB_colormanagement.h"
|
2012-01-05 17:50:09 +00:00
|
|
|
#include "IMB_imbuf.h"
|
|
|
|
#include "IMB_imbuf_types.h"
|
|
|
|
|
|
|
|
#include "intern/openexr/openexr_multi.h"
|
|
|
|
|
Fix T56799: Custom render passes missing when using Save Buffers
The problem here was that when a render result is allocated, the standard render passes are added according to the
pass bitfield. Then, when the render engine sets the result, it adds the additional passes which are then merged
into the main render result.
However, when using Save Buffers, the EXR is created before the actual render starts, so it's missing all those
additional passes.
To fix that, we need to query the render engine for a list of additional passes so they can be added before the EXR
is created. Luckily, there already is a function to do that for the node editor.
The same needs to be done when the EXR is loaded back.
Due to how that is implemented though (Render API calls into engine, engine calls back for each pass), if we have
multiple places that call this function there needs to be a way to tell which one the call came from in the pass
registration callback. Therefore, the original caller now provides a callback that is called for each pass.
2019-01-18 00:45:21 +01:00
|
|
|
#include "RE_engine.h"
|
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
#include "render_result.h"
|
|
|
|
#include "render_types.h"
|
|
|
|
|
|
|
|
/********************************** Free *************************************/
|
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
static void render_result_views_free(RenderResult *rr)
|
2015-04-06 10:40:12 -03:00
|
|
|
{
|
2020-09-04 20:59:13 +02:00
|
|
|
while (rr->views.first) {
|
|
|
|
RenderView *rv = rr->views.first;
|
|
|
|
BLI_remlink(&rr->views, rv);
|
2015-04-06 10:40:12 -03:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (rv->rect32) {
|
2015-04-06 10:40:12 -03:00
|
|
|
MEM_freeN(rv->rect32);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (rv->rectz) {
|
2015-04-06 10:40:12 -03:00
|
|
|
MEM_freeN(rv->rectz);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (rv->rectf) {
|
2015-04-06 10:40:12 -03:00
|
|
|
MEM_freeN(rv->rectf);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
|
|
|
|
MEM_freeN(rv);
|
|
|
|
}
|
2018-01-25 14:07:51 +01:00
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
rr->have_combined = false;
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
void render_result_free(RenderResult *rr)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2020-09-04 20:59:13 +02:00
|
|
|
if (rr == NULL) {
|
2012-06-13 17:23:44 +00:00
|
|
|
return;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
while (rr->layers.first) {
|
|
|
|
RenderLayer *rl = rr->layers.first;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-24 06:38:07 +00:00
|
|
|
while (rl->passes.first) {
|
2012-06-13 17:23:44 +00:00
|
|
|
RenderPass *rpass = rl->passes.first;
|
2019-04-22 09:08:06 +10:00
|
|
|
if (rpass->rect) {
|
2012-03-24 06:38:07 +00:00
|
|
|
MEM_freeN(rpass->rect);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
BLI_remlink(&rl->passes, rpass);
|
|
|
|
MEM_freeN(rpass);
|
|
|
|
}
|
2020-09-04 20:59:13 +02:00
|
|
|
BLI_remlink(&rr->layers, rl);
|
2012-01-05 17:50:09 +00:00
|
|
|
MEM_freeN(rl);
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
render_result_views_free(rr);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
if (rr->rect32) {
|
|
|
|
MEM_freeN(rr->rect32);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2020-09-04 20:59:13 +02:00
|
|
|
if (rr->rectz) {
|
|
|
|
MEM_freeN(rr->rectz);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2020-09-04 20:59:13 +02:00
|
|
|
if (rr->rectf) {
|
|
|
|
MEM_freeN(rr->rectf);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2020-09-04 20:59:13 +02:00
|
|
|
if (rr->text) {
|
|
|
|
MEM_freeN(rr->text);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2020-09-04 20:59:13 +02:00
|
|
|
if (rr->error) {
|
|
|
|
MEM_freeN(rr->error);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
BKE_stamp_data_free(rr->stamp_data);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
MEM_freeN(rr);
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
|
2021-04-08 16:20:22 +10:00
|
|
|
/** Version that's compatible with full-sample buffers. */
|
2012-01-05 17:50:09 +00:00
|
|
|
void render_result_free_list(ListBase *lb, RenderResult *rr)
|
|
|
|
{
|
|
|
|
RenderResult *rrnext;
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
for (; rr; rr = rrnext) {
|
|
|
|
rrnext = rr->next;
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (lb && lb->first) {
|
2012-01-05 17:50:09 +00:00
|
|
|
BLI_remlink(lb, rr);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
render_result_free(rr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
/********************************* multiview *************************************/
|
2012-01-05 17:50:09 +00:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
/* create a new views Listbase in rr without duplicating the memory pointers */
|
|
|
|
void render_result_views_shallowcopy(RenderResult *dst, RenderResult *src)
|
|
|
|
{
|
|
|
|
RenderView *rview;
|
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (dst == NULL || src == NULL) {
|
2015-04-06 10:40:12 -03:00
|
|
|
return;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
|
|
|
|
for (rview = src->views.first; rview; rview = rview->next) {
|
|
|
|
RenderView *rv;
|
|
|
|
|
|
|
|
rv = MEM_mallocN(sizeof(RenderView), "new render view");
|
|
|
|
BLI_addtail(&dst->views, rv);
|
|
|
|
|
|
|
|
BLI_strncpy(rv->name, rview->name, sizeof(rv->name));
|
|
|
|
rv->rectf = rview->rectf;
|
|
|
|
rv->rectz = rview->rectz;
|
|
|
|
rv->rect32 = rview->rect32;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* free the views created temporarily */
|
|
|
|
void render_result_views_shallowdelete(RenderResult *rr)
|
|
|
|
{
|
2019-04-22 09:08:06 +10:00
|
|
|
if (rr == NULL) {
|
2015-04-06 10:40:12 -03:00
|
|
|
return;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
while (rr->views.first) {
|
|
|
|
RenderView *rv = rr->views.first;
|
|
|
|
BLI_remlink(&rr->views, rv);
|
|
|
|
MEM_freeN(rv);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-03-25 11:42:28 +11:00
|
|
|
static char *set_pass_name(char *outname, const char *name, int channel, const char *chan_id)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2020-03-04 15:12:36 +11:00
|
|
|
const char *strings[2];
|
|
|
|
int strings_len = 0;
|
|
|
|
strings[strings_len++] = name;
|
|
|
|
char token[2];
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
if (channel >= 0) {
|
2020-03-04 15:12:36 +11:00
|
|
|
ARRAY_SET_ITEMS(token, chan_id[channel], '\0');
|
|
|
|
strings[strings_len++] = token;
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
}
|
2020-03-04 15:12:36 +11:00
|
|
|
BLI_string_join_array_by_sep_char(outname, EXR_PASS_MAXNAME, '.', strings, strings_len);
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
return outname;
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
static void set_pass_full_name(
|
|
|
|
char *fullname, const char *name, int channel, const char *view, const char *chan_id)
|
2015-04-06 10:40:12 -03:00
|
|
|
{
|
2020-03-04 15:12:36 +11:00
|
|
|
const char *strings[3];
|
|
|
|
int strings_len = 0;
|
|
|
|
strings[strings_len++] = name;
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
if (view && view[0]) {
|
2020-03-04 15:12:36 +11:00
|
|
|
strings[strings_len++] = view;
|
2015-06-26 19:41:51 +02:00
|
|
|
}
|
2020-03-04 15:12:36 +11:00
|
|
|
char token[2];
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
if (channel >= 0) {
|
2020-03-04 15:12:36 +11:00
|
|
|
ARRAY_SET_ITEMS(token, chan_id[channel], '\0');
|
|
|
|
strings[strings_len++] = token;
|
2015-06-26 19:41:51 +02:00
|
|
|
}
|
2020-03-04 15:12:36 +11:00
|
|
|
BLI_string_join_array_by_sep_char(fullname, EXR_PASS_MAXNAME, '.', strings, strings_len);
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/********************************** New **************************************/
|
|
|
|
|
Cycles: code refactor to bake using regular render session and tiles
There should be no user visible change from this, except that tile size
now affects performance. The goal here is to simplify bake denoising in
D3099, letting it reuse more denoising tiles and pass code.
A lot of code is now shared with regular rendering, with the two main
differences being that we read some render result passes from the bake API
when starting to render a tile, and call the bake kernel instead of the
path trace kernel.
With this kind of design where Cycles asks for tiles from the bake API,
it should eventually be easier to reduce memory usage, show tiles as
they are baked, or bake multiple passes at once, though there's still
quite some work needed for that.
Reviewers: #cycles
Subscribers: monio, wmatyjewicz, lukasstockner97, michaelknubben
Differential Revision: https://developer.blender.org/D3108
2019-05-10 21:39:58 +02:00
|
|
|
RenderPass *render_layer_add_pass(RenderResult *rr,
|
|
|
|
RenderLayer *rl,
|
|
|
|
int channels,
|
|
|
|
const char *name,
|
|
|
|
const char *viewname,
|
|
|
|
const char *chan_id)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2015-10-24 01:01:10 +11:00
|
|
|
const int view_id = BLI_findstringindex(&rr->views, viewname, offsetof(RenderView, name));
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RenderPass *rpass = MEM_callocN(sizeof(RenderPass), name);
|
2015-04-30 12:10:58 +02:00
|
|
|
size_t rectsize = ((size_t)rr->rectx) * rr->recty * channels;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
rpass->channels = channels;
|
|
|
|
rpass->rectx = rl->rectx;
|
|
|
|
rpass->recty = rl->recty;
|
2015-04-06 10:40:12 -03:00
|
|
|
rpass->view_id = view_id;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
BLI_strncpy(rpass->name, name, sizeof(rpass->name));
|
|
|
|
BLI_strncpy(rpass->chan_id, chan_id, sizeof(rpass->chan_id));
|
2015-04-06 10:40:12 -03:00
|
|
|
BLI_strncpy(rpass->view, viewname, sizeof(rpass->view));
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
set_pass_full_name(rpass->fullname, rpass->name, -1, rpass->view, rpass->chan_id);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-09-04 13:29:07 +00:00
|
|
|
if (rl->exrhandle) {
|
2012-01-05 17:50:09 +00:00
|
|
|
int a;
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
for (a = 0; a < channels; a++) {
|
|
|
|
char passname[EXR_PASS_MAXNAME];
|
|
|
|
IMB_exr_add_channel(rl->exrhandle,
|
|
|
|
rl->name,
|
|
|
|
set_pass_name(passname, rpass->name, a, rpass->chan_id),
|
|
|
|
viewname,
|
|
|
|
0,
|
|
|
|
0,
|
|
|
|
NULL,
|
|
|
|
false);
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2019-06-18 12:47:16 +02:00
|
|
|
|
|
|
|
/* Always allocate combined for display, in case of save buffers
|
|
|
|
* other passes are not allocated and only saved to the EXR file. */
|
|
|
|
if (rl->exrhandle == NULL || STREQ(rpass->name, RE_PASSNAME_COMBINED)) {
|
2012-01-05 17:50:09 +00:00
|
|
|
float *rect;
|
|
|
|
int x;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-05-20 00:24:26 +02:00
|
|
|
rpass->rect = MEM_callocN(sizeof(float) * rectsize, name);
|
2016-03-03 13:21:04 +05:00
|
|
|
if (rpass->rect == NULL) {
|
|
|
|
MEM_freeN(rpass);
|
|
|
|
return NULL;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
if (STREQ(rpass->name, RE_PASSNAME_VECTOR)) {
|
2012-01-05 17:50:09 +00:00
|
|
|
/* initialize to max speed */
|
2012-06-13 17:23:44 +00:00
|
|
|
rect = rpass->rect;
|
2019-04-22 09:08:06 +10:00
|
|
|
for (x = rectsize - 1; x >= 0; x--) {
|
2012-06-13 17:23:44 +00:00
|
|
|
rect[x] = PASS_VECTOR_MAX;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
else if (STREQ(rpass->name, RE_PASSNAME_Z)) {
|
2012-06-13 17:23:44 +00:00
|
|
|
rect = rpass->rect;
|
2019-04-22 09:08:06 +10:00
|
|
|
for (x = rectsize - 1; x >= 0; x--) {
|
2012-06-13 17:23:44 +00:00
|
|
|
rect[x] = 10e10;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
2016-03-03 13:21:04 +05:00
|
|
|
BLI_addtail(&rl->passes, rpass);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-10-04 19:00:26 +06:00
|
|
|
return rpass;
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* called by main render as well for parts */
|
|
|
|
/* will read info from Render *re to define layers */
|
|
|
|
/* called in threads */
|
|
|
|
/* re->winx,winy is coordinate space of entire image, partrct the part within */
|
2020-12-16 16:16:50 +01:00
|
|
|
RenderResult *render_result_new(
|
|
|
|
Render *re, rcti *partrct, int savebuffers, const char *layername, const char *viewname)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
|
|
|
RenderResult *rr;
|
|
|
|
RenderLayer *rl;
|
2015-04-06 10:40:12 -03:00
|
|
|
RenderView *rv;
|
|
|
|
int rectx, recty;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-09-23 18:50:56 +00:00
|
|
|
rectx = BLI_rcti_size_x(partrct);
|
|
|
|
recty = BLI_rcti_size_y(partrct);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (rectx <= 0 || recty <= 0) {
|
2012-01-05 17:50:09 +00:00
|
|
|
return NULL;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
rr = MEM_callocN(sizeof(RenderResult), "new render result");
|
|
|
|
rr->rectx = rectx;
|
|
|
|
rr->recty = recty;
|
|
|
|
rr->renrect.xmin = 0;
|
2020-12-16 16:16:50 +01:00
|
|
|
rr->renrect.xmax = rectx;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/* tilerect is relative coordinates within render disprect. do not subtract crop yet */
|
2012-03-24 02:51:46 +00:00
|
|
|
rr->tilerect.xmin = partrct->xmin - re->disprect.xmin;
|
2012-09-04 13:29:07 +00:00
|
|
|
rr->tilerect.xmax = partrct->xmax - re->disprect.xmin;
|
2012-03-24 02:51:46 +00:00
|
|
|
rr->tilerect.ymin = partrct->ymin - re->disprect.ymin;
|
2012-09-04 13:29:07 +00:00
|
|
|
rr->tilerect.ymax = partrct->ymax - re->disprect.ymin;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-24 06:38:07 +00:00
|
|
|
if (savebuffers) {
|
2014-04-01 11:34:00 +11:00
|
|
|
rr->do_exr_tile = true;
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
render_result_views_new(rr, &re->r);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/* check renderdata for amount of layers */
|
2018-02-28 10:05:38 +11:00
|
|
|
FOREACH_VIEW_LAYER_TO_RENDER_BEGIN (re, view_layer) {
|
2018-02-20 12:55:02 -03:00
|
|
|
if (layername && layername[0]) {
|
|
|
|
if (!STREQ(view_layer->name, layername)) {
|
2014-04-30 15:29:03 +09:00
|
|
|
continue;
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2017-11-16 13:39:25 -02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
rl = MEM_callocN(sizeof(RenderLayer), "new render layer");
|
2012-01-05 17:50:09 +00:00
|
|
|
BLI_addtail(&rr->layers, rl);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-11-22 10:52:39 -02:00
|
|
|
BLI_strncpy(rl->name, view_layer->name, sizeof(rl->name));
|
|
|
|
rl->layflag = view_layer->layflag;
|
2019-07-02 22:17:22 +10:00
|
|
|
|
|
|
|
/* for debugging: view_layer->passflag | SCE_PASS_RAYHITS; */
|
|
|
|
rl->passflag = view_layer->passflag;
|
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
rl->rectx = rectx;
|
|
|
|
rl->recty = recty;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-09-04 13:29:07 +00:00
|
|
|
if (rr->do_exr_tile) {
|
|
|
|
rl->exrhandle = IMB_exr_get_handle();
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
for (rv = rr->views.first; rv; rv = rv->next) {
|
|
|
|
const char *view = rv->name;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (viewname && viewname[0]) {
|
|
|
|
if (!STREQ(view, viewname)) {
|
2015-04-06 10:40:12 -03:00
|
|
|
continue;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (rr->do_exr_tile) {
|
2015-04-06 10:40:12 -03:00
|
|
|
IMB_exr_add_view(rl->exrhandle, view);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
#define RENDER_LAYER_ADD_PASS_SAFE(rr, rl, channels, name, viewname, chan_id) \
|
2019-03-25 11:55:36 +11:00
|
|
|
do { \
|
|
|
|
if (render_layer_add_pass(rr, rl, channels, name, viewname, chan_id) == NULL) { \
|
|
|
|
render_result_free(rr); \
|
|
|
|
return NULL; \
|
|
|
|
} \
|
|
|
|
} while (false)
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
/* a renderlayer should always have a Combined pass*/
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
render_layer_add_pass(rr, rl, 4, "Combined", view, "RGBA");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (view_layer->passflag & SCE_PASS_Z) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 1, RE_PASSNAME_Z, view, "Z");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_VECTOR) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 4, RE_PASSNAME_VECTOR, view, "XYZW");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_NORMAL) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_NORMAL, view, "XYZ");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_UV) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_UV, view, "UVA");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_EMIT) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_EMIT, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_AO) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_AO, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_ENVIRONMENT) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_ENVIRONMENT, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_SHADOW) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_SHADOW, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_INDEXOB) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 1, RE_PASSNAME_INDEXOB, view, "X");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_INDEXMA) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 1, RE_PASSNAME_INDEXMA, view, "X");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_MIST) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 1, RE_PASSNAME_MIST, view, "Z");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (rl->passflag & SCE_PASS_RAYHITS) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 4, RE_PASSNAME_RAYHITS, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_DIFFUSE_DIRECT) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_DIFFUSE_DIRECT, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_DIFFUSE_INDIRECT) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_DIFFUSE_INDIRECT, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_DIFFUSE_COLOR) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_DIFFUSE_COLOR, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_GLOSSY_DIRECT) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_GLOSSY_DIRECT, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_GLOSSY_INDIRECT) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_GLOSSY_INDIRECT, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_GLOSSY_COLOR) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_GLOSSY_COLOR, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_TRANSM_DIRECT) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_TRANSM_DIRECT, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_TRANSM_INDIRECT) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_TRANSM_INDIRECT, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_TRANSM_COLOR) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_TRANSM_COLOR, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_SUBSURFACE_DIRECT) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_SUBSURFACE_DIRECT, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_SUBSURFACE_INDIRECT) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_SUBSURFACE_INDIRECT, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (view_layer->passflag & SCE_PASS_SUBSURFACE_COLOR) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RENDER_LAYER_ADD_PASS_SAFE(rr, rl, 3, RE_PASSNAME_SUBSURFACE_COLOR, view, "RGB");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2016-03-03 13:21:04 +05:00
|
|
|
#undef RENDER_LAYER_ADD_PASS_SAFE
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
2018-03-09 11:44:42 +11:00
|
|
|
FOREACH_VIEW_LAYER_TO_RENDER_END;
|
2018-02-20 12:55:02 -03:00
|
|
|
|
2021-02-05 16:23:34 +11:00
|
|
|
/* Preview-render doesn't do layers, so we make a default one. */
|
2014-02-08 06:07:10 +11:00
|
|
|
if (BLI_listbase_is_empty(&rr->layers) && !(layername && layername[0])) {
|
2012-06-13 17:23:44 +00:00
|
|
|
rl = MEM_callocN(sizeof(RenderLayer), "new render layer");
|
2012-01-05 17:50:09 +00:00
|
|
|
BLI_addtail(&rr->layers, rl);
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
rl->rectx = rectx;
|
|
|
|
rl->recty = recty;
|
2012-01-05 17:50:09 +00:00
|
|
|
|
|
|
|
/* duplicate code... */
|
2012-09-04 13:29:07 +00:00
|
|
|
if (rr->do_exr_tile) {
|
|
|
|
rl->exrhandle = IMB_exr_get_handle();
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
|
|
|
|
for (rv = rr->views.first; rv; rv = rv->next) {
|
|
|
|
const char *view = rv->name;
|
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (viewname && viewname[0]) {
|
2020-08-08 12:14:52 +10:00
|
|
|
if (!STREQ(view, viewname)) {
|
2015-04-06 10:40:12 -03:00
|
|
|
continue;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (rr->do_exr_tile) {
|
2015-04-06 10:40:12 -03:00
|
|
|
IMB_exr_add_view(rl->exrhandle, view);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
|
2015-05-12 11:36:52 -03:00
|
|
|
/* a renderlayer should always have a Combined pass */
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
render_layer_add_pass(rr, rl, 4, RE_PASSNAME_COMBINED, view, "RGBA");
|
2012-09-04 18:27:47 +00:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/* note, this has to be in sync with scene.c */
|
2012-06-13 17:23:44 +00:00
|
|
|
rl->layflag = 0x7FFF; /* solid ztra halo strand */
|
|
|
|
rl->passflag = SCE_PASS_COMBINED;
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2017-11-22 10:52:39 -02:00
|
|
|
re->active_view_layer = 0;
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/* border render; calculate offset for use in compositor. compo is centralized coords */
|
Blender Internal Render in viewport
Because of our release soon, feature has been added behind the Debug Menu.
CTRL+ALT+D and set it to -1. Or commandline --debug-value -1.
When debug set to -1, you can put the viewport to 'render' mode, just like
for Cycles. Notes for testers: (and please no bugs in tracker for this :)
- It renders without AA, MBlur, Panorama, Sequence, Composite
- Only active render layer gets rendered. Select another layer will re-render.
- But yes: it works for FreeStyle renders!
- Also does great for local view.
- BI is not well suited for incremental renders on view changes. This only
works for non-raytrace scenes, or zoom in ortho or camera mode, or for
Material changes. In most cases a full re-render is being done.
- ESC works to stop the preview render.
- Borders render as well. (CTRL+B)
- Force a refresh with arrow key left/right. A lot of settings don't trigger
re-render yet.
Tech notes:
- FreeStyle is adding a lot of temp objects/meshes in the Main database. This
caused DepsGraph to trigger changes (and redraws). I've prepended the names
for these temp objects with char number 27 (ESC), and made these names be
ignored for tag update checking.
- Fixed some bugs that were noticable with such excessive re-renders, like
for opening file window, quit during renders.
2013-04-16 17:39:20 +00:00
|
|
|
/* XXX obsolete? I now use it for drawing border render offset (ton) */
|
2012-09-23 18:50:56 +00:00
|
|
|
rr->xof = re->disprect.xmin + BLI_rcti_cent_x(&re->disprect) - (re->winx / 2);
|
|
|
|
rr->yof = re->disprect.ymin + BLI_rcti_cent_y(&re->disprect) - (re->winy / 2);
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
return rr;
|
|
|
|
}
|
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
void render_result_clone_passes(Render *re, RenderResult *rr, const char *viewname)
|
|
|
|
{
|
|
|
|
RenderLayer *rl;
|
|
|
|
RenderPass *main_rp;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
for (rl = rr->layers.first; rl; rl = rl->next) {
|
|
|
|
RenderLayer *main_rl = BLI_findstring(
|
|
|
|
&re->result->layers, rl->name, offsetof(RenderLayer, name));
|
|
|
|
if (!main_rl) {
|
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
for (main_rp = main_rl->passes.first; main_rp; main_rp = main_rp->next) {
|
|
|
|
if (viewname && viewname[0] && !STREQ(main_rp->view, viewname)) {
|
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
/* Compare fullname to make sure that the view also is equal. */
|
|
|
|
RenderPass *rp = BLI_findstring(
|
|
|
|
&rl->passes, main_rp->fullname, offsetof(RenderPass, fullname));
|
|
|
|
if (!rp) {
|
|
|
|
render_layer_add_pass(
|
|
|
|
rr, rl, main_rp->channels, main_rp->name, main_rp->view, main_rp->chan_id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-02-13 01:29:30 +01:00
|
|
|
void RE_create_render_pass(RenderResult *rr,
|
|
|
|
const char *name,
|
|
|
|
int channels,
|
|
|
|
const char *chan_id,
|
|
|
|
const char *layername,
|
|
|
|
const char *viewname)
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
{
|
|
|
|
RenderLayer *rl;
|
|
|
|
RenderPass *rp;
|
|
|
|
RenderView *rv;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
for (rl = rr->layers.first; rl; rl = rl->next) {
|
|
|
|
if (layername && layername[0] && !STREQ(rl->name, layername)) {
|
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
for (rv = rr->views.first; rv; rv = rv->next) {
|
|
|
|
const char *view = rv->name;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (viewname && viewname[0] && !STREQ(view, viewname)) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
continue;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
/* Ensure that the pass doesn't exist yet. */
|
|
|
|
for (rp = rl->passes.first; rp; rp = rp->next) {
|
2019-04-22 09:08:06 +10:00
|
|
|
if (!STREQ(rp->name, name)) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
continue;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (!STREQ(rp->view, view)) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
continue;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-01-18 00:40:05 +01:00
|
|
|
break;
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
if (!rp) {
|
|
|
|
render_layer_add_pass(rr, rl, channels, name, view, chan_id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int passtype_from_name(const char *name)
|
|
|
|
{
|
|
|
|
const char delim[] = {'.', '\0'};
|
|
|
|
const char *sep, *suf;
|
|
|
|
int len = BLI_str_partition(name, delim, &sep, &suf);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
#define CHECK_PASS(NAME) \
|
2020-09-19 16:01:32 +10:00
|
|
|
if (STREQLEN(name, RE_PASSNAME_##NAME, len)) { \
|
|
|
|
return SCE_PASS_##NAME; \
|
|
|
|
} \
|
|
|
|
((void)0)
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
CHECK_PASS(COMBINED);
|
|
|
|
CHECK_PASS(Z);
|
|
|
|
CHECK_PASS(VECTOR);
|
|
|
|
CHECK_PASS(NORMAL);
|
|
|
|
CHECK_PASS(UV);
|
|
|
|
CHECK_PASS(EMIT);
|
|
|
|
CHECK_PASS(SHADOW);
|
|
|
|
CHECK_PASS(AO);
|
|
|
|
CHECK_PASS(ENVIRONMENT);
|
|
|
|
CHECK_PASS(INDEXOB);
|
|
|
|
CHECK_PASS(INDEXMA);
|
|
|
|
CHECK_PASS(MIST);
|
|
|
|
CHECK_PASS(RAYHITS);
|
|
|
|
CHECK_PASS(DIFFUSE_DIRECT);
|
|
|
|
CHECK_PASS(DIFFUSE_INDIRECT);
|
|
|
|
CHECK_PASS(DIFFUSE_COLOR);
|
|
|
|
CHECK_PASS(GLOSSY_DIRECT);
|
|
|
|
CHECK_PASS(GLOSSY_INDIRECT);
|
|
|
|
CHECK_PASS(GLOSSY_COLOR);
|
|
|
|
CHECK_PASS(TRANSM_DIRECT);
|
|
|
|
CHECK_PASS(TRANSM_INDIRECT);
|
|
|
|
CHECK_PASS(TRANSM_COLOR);
|
|
|
|
CHECK_PASS(SUBSURFACE_DIRECT);
|
|
|
|
CHECK_PASS(SUBSURFACE_INDIRECT);
|
|
|
|
CHECK_PASS(SUBSURFACE_COLOR);
|
|
|
|
|
|
|
|
#undef CHECK_PASS
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/* callbacks for render_result_new_from_exr */
|
2012-07-08 00:04:41 +00:00
|
|
|
static void *ml_addlayer_cb(void *base, const char *str)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2012-06-13 17:23:44 +00:00
|
|
|
RenderResult *rr = base;
|
2012-01-05 17:50:09 +00:00
|
|
|
RenderLayer *rl;
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
rl = MEM_callocN(sizeof(RenderLayer), "new render layer");
|
2012-01-05 17:50:09 +00:00
|
|
|
BLI_addtail(&rr->layers, rl);
|
2017-10-20 15:18:26 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
BLI_strncpy(rl->name, str, EXR_LAY_MAXNAME);
|
|
|
|
return rl;
|
|
|
|
}
|
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
static void ml_addpass_cb(void *base,
|
|
|
|
void *lay,
|
|
|
|
const char *name,
|
|
|
|
float *rect,
|
|
|
|
int totchan,
|
|
|
|
const char *chan_id,
|
|
|
|
const char *view)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2015-04-06 10:40:12 -03:00
|
|
|
RenderResult *rr = base;
|
2012-06-13 17:23:44 +00:00
|
|
|
RenderLayer *rl = lay;
|
|
|
|
RenderPass *rpass = MEM_callocN(sizeof(RenderPass), "loaded pass");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
BLI_addtail(&rl->passes, rpass);
|
2012-06-13 17:23:44 +00:00
|
|
|
rpass->channels = totchan;
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
rl->passflag |= passtype_from_name(name);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/* channel id chars */
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
BLI_strncpy(rpass->chan_id, chan_id, sizeof(rpass->chan_id));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
rpass->rect = rect;
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
BLI_strncpy(rpass->name, name, EXR_PASS_MAXNAME);
|
|
|
|
BLI_strncpy(rpass->view, view, sizeof(rpass->view));
|
|
|
|
set_pass_full_name(rpass->fullname, name, -1, view, rpass->chan_id);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
if (view[0] != '\0') {
|
|
|
|
rpass->view_id = BLI_findstringindex(&rr->views, view, offsetof(RenderView, name));
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
rpass->view_id = 0;
|
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
static void *ml_addview_cb(void *base, const char *str)
|
|
|
|
{
|
|
|
|
RenderResult *rr = base;
|
|
|
|
RenderView *rv;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
rv = MEM_callocN(sizeof(RenderView), "new render view");
|
|
|
|
BLI_strncpy(rv->name, str, EXR_VIEW_MAXNAME);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
/* For stereo drawing we need to ensure:
|
|
|
|
* STEREO_LEFT_NAME == STEREO_LEFT_ID and
|
|
|
|
* STEREO_RIGHT_NAME == STEREO_RIGHT_ID */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
if (STREQ(str, STEREO_LEFT_NAME)) {
|
|
|
|
BLI_addhead(&rr->views, rv);
|
|
|
|
}
|
|
|
|
else if (STREQ(str, STEREO_RIGHT_NAME)) {
|
|
|
|
RenderView *left_rv = BLI_findstring(&rr->views, STEREO_LEFT_NAME, offsetof(RenderView, name));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
if (left_rv == NULL) {
|
|
|
|
BLI_addhead(&rr->views, rv);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
BLI_insertlinkafter(&rr->views, left_rv, rv);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
BLI_addtail(&rr->views, rv);
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int order_render_passes(const void *a, const void *b)
|
|
|
|
{
|
|
|
|
// 1 if a is after b
|
2019-03-25 11:55:36 +11:00
|
|
|
RenderPass *rpa = (RenderPass *)a;
|
|
|
|
RenderPass *rpb = (RenderPass *)b;
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
unsigned int passtype_a = passtype_from_name(rpa->name);
|
|
|
|
unsigned int passtype_b = passtype_from_name(rpb->name);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
/* Render passes with default type always go first. */
|
2019-04-22 09:08:06 +10:00
|
|
|
if (passtype_b && !passtype_a) {
|
2015-04-06 10:40:12 -03:00
|
|
|
return 1;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (passtype_a && !passtype_b) {
|
2015-04-06 10:40:12 -03:00
|
|
|
return 0;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
if (passtype_a && passtype_b) {
|
2019-04-22 09:08:06 +10:00
|
|
|
if (passtype_a > passtype_b) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
return 1;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2020-08-07 13:37:22 +02:00
|
|
|
if (passtype_a < passtype_b) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
return 0;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
int cmp = strncmp(rpa->name, rpb->name, EXR_PASS_MAXNAME);
|
2019-04-22 09:08:06 +10:00
|
|
|
if (cmp > 0) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
return 1;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
if (cmp < 0) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
return 0;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
/* they have the same type */
|
|
|
|
/* left first */
|
2019-04-22 09:08:06 +10:00
|
|
|
if (STREQ(rpa->view, STEREO_LEFT_NAME)) {
|
2015-04-06 10:40:12 -03:00
|
|
|
return 0;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2020-08-07 13:37:22 +02:00
|
|
|
if (STREQ(rpb->view, STEREO_LEFT_NAME)) {
|
2015-04-06 10:40:12 -03:00
|
|
|
return 1;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
/* right second */
|
2019-04-22 09:08:06 +10:00
|
|
|
if (STREQ(rpa->view, STEREO_RIGHT_NAME)) {
|
2015-04-06 10:40:12 -03:00
|
|
|
return 0;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2020-08-07 13:37:22 +02:00
|
|
|
if (STREQ(rpb->view, STEREO_RIGHT_NAME)) {
|
2015-04-06 10:40:12 -03:00
|
|
|
return 1;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
/* remaining in ascending id order */
|
|
|
|
return (rpa->view_id < rpb->view_id);
|
|
|
|
}
|
|
|
|
|
2020-11-16 16:48:41 +11:00
|
|
|
/**
|
|
|
|
* From imbuf, if a handle was returned and
|
|
|
|
* it's not a single-layer multi-view we convert this to render result.
|
|
|
|
*/
|
2014-04-01 11:34:00 +11:00
|
|
|
RenderResult *render_result_new_from_exr(
|
|
|
|
void *exrhandle, const char *colorspace, bool predivide, int rectx, int recty)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2012-07-08 00:04:41 +00:00
|
|
|
RenderResult *rr = MEM_callocN(sizeof(RenderResult), __func__);
|
2012-01-05 17:50:09 +00:00
|
|
|
RenderLayer *rl;
|
|
|
|
RenderPass *rpass;
|
2012-09-23 18:50:56 +00:00
|
|
|
const char *to_colorspace = IMB_colormanagement_role_colorspace_name_get(
|
|
|
|
COLOR_ROLE_SCENE_LINEAR);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
rr->rectx = rectx;
|
|
|
|
rr->recty = recty;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
IMB_exr_multilayer_convert(exrhandle, rr, ml_addview_cb, ml_addlayer_cb, ml_addpass_cb);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
for (rl = rr->layers.first; rl; rl = rl->next) {
|
|
|
|
rl->rectx = rectx;
|
|
|
|
rl->recty = recty;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
BLI_listbase_sort(&rl->passes, order_render_passes);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
for (rpass = rl->passes.first; rpass; rpass = rpass->next) {
|
|
|
|
rpass->rectx = rectx;
|
|
|
|
rpass->recty = recty;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-09-23 18:50:56 +00:00
|
|
|
if (rpass->channels >= 3) {
|
|
|
|
IMB_colormanagement_transform(rpass->rect,
|
|
|
|
rpass->rectx,
|
|
|
|
rpass->recty,
|
|
|
|
rpass->channels,
|
|
|
|
colorspace,
|
|
|
|
to_colorspace,
|
|
|
|
predivide);
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
return rr;
|
|
|
|
}
|
|
|
|
|
2015-04-28 17:36:44 -03:00
|
|
|
void render_result_view_new(RenderResult *rr, const char *viewname)
|
|
|
|
{
|
|
|
|
RenderView *rv = MEM_callocN(sizeof(RenderView), "new render view");
|
|
|
|
BLI_addtail(&rr->views, rv);
|
|
|
|
BLI_strncpy(rv->name, viewname, sizeof(rv->name));
|
|
|
|
}
|
|
|
|
|
2020-03-13 17:27:11 +11:00
|
|
|
void render_result_views_new(RenderResult *rr, const RenderData *rd)
|
2015-04-06 10:40:12 -03:00
|
|
|
{
|
|
|
|
SceneRenderView *srv;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
/* clear previously existing views - for sequencer */
|
|
|
|
render_result_views_free(rr);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
/* check renderdata for amount of views */
|
|
|
|
if ((rd->scemode & R_MULTIVIEW)) {
|
|
|
|
for (srv = rd->views.first; srv; srv = srv->next) {
|
2019-04-22 09:08:06 +10:00
|
|
|
if (BKE_scene_multiview_is_render_view_active(rd, srv) == false) {
|
2015-04-28 17:36:44 -03:00
|
|
|
continue;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2015-04-28 17:36:44 -03:00
|
|
|
render_result_view_new(rr, srv->name);
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
/* we always need at least one view */
|
2018-04-03 17:05:21 +02:00
|
|
|
if (BLI_listbase_count_at_most(&rr->views, 1) == 0) {
|
2015-04-29 16:35:19 -03:00
|
|
|
render_result_view_new(rr, "");
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
bool render_result_has_views(RenderResult *rr)
|
|
|
|
{
|
|
|
|
RenderView *rv = rr->views.first;
|
|
|
|
return (rv && (rv->next || rv->name[0]));
|
|
|
|
}
|
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/*********************************** Merge ***********************************/
|
|
|
|
|
|
|
|
static void do_merge_tile(
|
|
|
|
RenderResult *rr, RenderResult *rrpart, float *target, float *tile, int pixsize)
|
|
|
|
{
|
2015-04-30 12:10:58 +02:00
|
|
|
int y, tilex, tiley;
|
|
|
|
size_t ofs, copylen;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
copylen = tilex = rrpart->rectx;
|
|
|
|
tiley = rrpart->recty;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-12-16 16:16:50 +01:00
|
|
|
ofs = (((size_t)rrpart->tilerect.ymin) * rr->rectx + rrpart->tilerect.xmin);
|
|
|
|
target += pixsize * ofs;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
copylen *= sizeof(float) * pixsize;
|
2012-01-05 17:50:09 +00:00
|
|
|
tilex *= pixsize;
|
2012-06-13 17:23:44 +00:00
|
|
|
ofs = pixsize * rr->rectx;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
for (y = 0; y < tiley; y++) {
|
2012-01-05 17:50:09 +00:00
|
|
|
memcpy(target, tile, copylen);
|
2012-06-13 17:23:44 +00:00
|
|
|
target += ofs;
|
|
|
|
tile += tilex;
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* used when rendering to a full buffer, or when reading the exr part-layer-pass file */
|
|
|
|
/* no test happens here if it fits... we also assume layers are in sync */
|
|
|
|
/* is used within threads */
|
|
|
|
void render_result_merge(RenderResult *rr, RenderResult *rrpart)
|
|
|
|
{
|
|
|
|
RenderLayer *rl, *rlp;
|
|
|
|
RenderPass *rpass, *rpassp;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-09-04 13:29:07 +00:00
|
|
|
for (rl = rr->layers.first; rl; rl = rl->next) {
|
2012-09-04 18:27:47 +00:00
|
|
|
rlp = RE_GetRenderLayer(rrpart, rl->name);
|
|
|
|
if (rlp) {
|
2019-06-18 12:47:16 +02:00
|
|
|
/* Passes are allocated in sync. */
|
2012-09-04 18:27:47 +00:00
|
|
|
for (rpass = rl->passes.first, rpassp = rlp->passes.first; rpass && rpassp;
|
2015-04-06 10:40:12 -03:00
|
|
|
rpass = rpass->next) {
|
2019-06-18 12:47:16 +02:00
|
|
|
/* For save buffers, skip any passes that are only saved to disk. */
|
|
|
|
if (rpass->rect == NULL || rpassp->rect == NULL) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
/* Renderresult have all passes, renderpart only the active view's passes. */
|
2020-08-08 12:14:52 +10:00
|
|
|
if (!STREQ(rpassp->fullname, rpass->fullname)) {
|
2015-04-06 10:40:12 -03:00
|
|
|
continue;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-09-04 18:27:47 +00:00
|
|
|
do_merge_tile(rr, rrpart, rpass->rect, rpassp->rect, rpass->channels);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
/* manually get next render pass */
|
|
|
|
rpassp = rpassp->next;
|
2012-09-04 13:29:07 +00:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
/* Called from the UI and render pipeline, to save multilayer and multiview
|
|
|
|
* images, optionally isolating a specific, view, layer or RGBA/Z pass. */
|
|
|
|
bool RE_WriteRenderResult(ReportList *reports,
|
|
|
|
RenderResult *rr,
|
|
|
|
const char *filename,
|
|
|
|
ImageFormatData *imf,
|
|
|
|
const char *view,
|
|
|
|
int layer)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2012-06-13 17:23:44 +00:00
|
|
|
void *exrhandle = IMB_exr_get_handle();
|
2017-10-20 15:18:26 +02:00
|
|
|
const bool half_float = (imf && imf->depth == R_IMF_CHAN_DEPTH_16);
|
|
|
|
const bool multi_layer = !(imf && imf->imtype == R_IMF_IMTYPE_OPENEXR);
|
|
|
|
const bool write_z = !multi_layer && (imf && (imf->flag & R_IMF_FLAG_ZBUF));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
/* Write first layer if not multilayer and no layer was specified. */
|
|
|
|
if (!multi_layer && layer == -1) {
|
|
|
|
layer = 0;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
/* First add views since IMB_exr_add_channel checks number of views. */
|
|
|
|
if (render_result_has_views(rr)) {
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (RenderView *, rview, &rr->views) {
|
2017-10-20 15:18:26 +02:00
|
|
|
if (!view || STREQ(view, rview->name)) {
|
|
|
|
IMB_exr_add_view(exrhandle, rview->name);
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
/* Compositing result. */
|
|
|
|
if (rr->have_combined) {
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (RenderView *, rview, &rr->views) {
|
2017-10-20 15:18:26 +02:00
|
|
|
if (!rview->rectf) {
|
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
const char *viewname = rview->name;
|
|
|
|
if (view) {
|
|
|
|
if (!STREQ(view, viewname)) {
|
2015-04-06 10:40:12 -03:00
|
|
|
continue;
|
|
|
|
}
|
2020-08-07 13:37:22 +02:00
|
|
|
|
|
|
|
viewname = "";
|
2017-10-20 15:18:26 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
/* Skip compositing if only a single other layer is requested. */
|
|
|
|
if (!multi_layer && layer != 0) {
|
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
for (int a = 0; a < 4; a++) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
char passname[EXR_PASS_MAXNAME];
|
2017-10-20 15:18:26 +02:00
|
|
|
char layname[EXR_PASS_MAXNAME];
|
|
|
|
const char *chan_id = "RGBA";
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
if (multi_layer) {
|
|
|
|
set_pass_name(passname, "Combined", a, chan_id);
|
|
|
|
BLI_strncpy(layname, "Composite", sizeof(layname));
|
2015-06-19 13:00:18 +02:00
|
|
|
}
|
2017-10-20 15:18:26 +02:00
|
|
|
else {
|
|
|
|
passname[0] = chan_id[a];
|
|
|
|
passname[1] = '\0';
|
|
|
|
layname[0] = '\0';
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
IMB_exr_add_channel(exrhandle,
|
|
|
|
layname,
|
|
|
|
passname,
|
|
|
|
viewname,
|
|
|
|
4,
|
|
|
|
4 * rr->rectx,
|
|
|
|
rview->rectf + a,
|
|
|
|
half_float);
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
if (write_z && rview->rectz) {
|
2019-03-25 11:55:36 +11:00
|
|
|
const char *layname = (multi_layer) ? "Composite" : "";
|
2017-10-20 15:18:26 +02:00
|
|
|
IMB_exr_add_channel(exrhandle, layname, "Z", viewname, 1, rr->rectx, rview->rectz, false);
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
/* Other render layers. */
|
2019-03-25 11:55:36 +11:00
|
|
|
int nr = (rr->have_combined) ? 1 : 0;
|
2017-10-20 15:18:26 +02:00
|
|
|
for (RenderLayer *rl = rr->layers.first; rl; rl = rl->next, nr++) {
|
|
|
|
/* Skip other render layers if requested. */
|
|
|
|
if (!multi_layer && nr != layer) {
|
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (RenderPass *, rp, &rl->passes) {
|
2017-10-20 15:18:26 +02:00
|
|
|
/* Skip non-RGBA and Z passes if not using multi layer. */
|
|
|
|
if (!multi_layer && !(STREQ(rp->name, RE_PASSNAME_COMBINED) || STREQ(rp->name, "") ||
|
2018-08-30 01:31:20 +10:00
|
|
|
(STREQ(rp->name, RE_PASSNAME_Z) && write_z))) {
|
2017-10-20 15:18:26 +02:00
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
/* Skip pass if it does not match the requested view(s). */
|
|
|
|
const char *viewname = rp->view;
|
|
|
|
if (view) {
|
|
|
|
if (!STREQ(view, viewname)) {
|
|
|
|
continue;
|
2012-09-04 18:27:47 +00:00
|
|
|
}
|
2020-08-07 13:37:22 +02:00
|
|
|
|
|
|
|
viewname = "";
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-11-23 16:27:22 +01:00
|
|
|
/* We only store RGBA passes as half float, for
|
|
|
|
* others precision loss can be problematic. */
|
|
|
|
bool pass_half_float = half_float &&
|
2020-11-06 15:29:25 +11:00
|
|
|
(STR_ELEM(rp->chan_id, "RGB", "RGBA", "R", "G", "B", "A"));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
for (int a = 0; a < rp->channels; a++) {
|
|
|
|
/* Save Combined as RGBA if single layer save. */
|
|
|
|
char passname[EXR_PASS_MAXNAME];
|
|
|
|
char layname[EXR_PASS_MAXNAME];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
if (multi_layer) {
|
|
|
|
set_pass_name(passname, rp->name, a, rp->chan_id);
|
|
|
|
BLI_strncpy(layname, rl->name, sizeof(layname));
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
passname[0] = rp->chan_id[a];
|
|
|
|
passname[1] = '\0';
|
|
|
|
layname[0] = '\0';
|
2012-09-04 18:27:47 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
IMB_exr_add_channel(exrhandle,
|
|
|
|
layname,
|
|
|
|
passname,
|
|
|
|
viewname,
|
|
|
|
rp->channels,
|
|
|
|
rp->channels * rr->rectx,
|
|
|
|
rp->rect + a,
|
2017-11-23 16:27:22 +01:00
|
|
|
pass_half_float);
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-01-11 12:32:29 +11:00
|
|
|
errno = 0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
BLI_make_existing_file(filename);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
int compress = (imf ? imf->exr_codec : 0);
|
|
|
|
bool success = IMB_exr_begin_write(
|
|
|
|
exrhandle, filename, rr->rectx, rr->recty, compress, rr->stamp_data);
|
|
|
|
if (success) {
|
2012-01-05 17:50:09 +00:00
|
|
|
IMB_exr_write_channels(exrhandle);
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
/* TODO, get the error from openexr's exception */
|
2016-01-11 12:32:29 +11:00
|
|
|
BKE_reportf(
|
|
|
|
reports, RPT_ERROR, "Error writing render result, %s (see console)", strerror(errno));
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
IMB_exr_close(exrhandle);
|
2012-01-05 17:50:09 +00:00
|
|
|
return success;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**************************** Single Layer Rendering *************************/
|
|
|
|
|
|
|
|
void render_result_single_layer_begin(Render *re)
|
|
|
|
{
|
|
|
|
/* all layers except the active one get temporally pushed away */
|
|
|
|
|
|
|
|
/* officially pushed result should be NULL... error can happen with do_seq */
|
|
|
|
RE_FreeRenderResult(re->pushedresult);
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
re->pushedresult = re->result;
|
|
|
|
re->result = NULL;
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* if scemode is R_SINGLE_LAYER, at end of rendering, merge the both render results */
|
|
|
|
void render_result_single_layer_end(Render *re)
|
|
|
|
{
|
2017-11-22 10:52:39 -02:00
|
|
|
ViewLayer *view_layer;
|
2012-01-05 17:50:09 +00:00
|
|
|
RenderLayer *rlpush;
|
|
|
|
RenderLayer *rl;
|
|
|
|
int nr;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
if (re->result == NULL) {
|
2012-01-05 17:50:09 +00:00
|
|
|
printf("pop render result error; no current result!\n");
|
|
|
|
return;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (!re->pushedresult) {
|
2012-01-05 17:50:09 +00:00
|
|
|
return;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
if (re->pushedresult->rectx == re->result->rectx &&
|
|
|
|
re->pushedresult->recty == re->result->recty) {
|
2012-01-05 17:50:09 +00:00
|
|
|
/* find which layer in re->pushedresult should be replaced */
|
2012-06-13 17:23:44 +00:00
|
|
|
rl = re->result->layers.first;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/* render result should be empty after this */
|
|
|
|
BLI_remlink(&re->result->layers, rl);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/* reconstruct render result layers */
|
2017-11-22 10:52:39 -02:00
|
|
|
for (nr = 0, view_layer = re->view_layers.first; view_layer;
|
|
|
|
view_layer = view_layer->next, nr++) {
|
|
|
|
if (nr == re->active_view_layer) {
|
2012-01-05 17:50:09 +00:00
|
|
|
BLI_addtail(&re->result->layers, rl);
|
2012-09-04 18:27:47 +00:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
else {
|
2017-11-22 10:52:39 -02:00
|
|
|
rlpush = RE_GetRenderLayer(re->pushedresult, view_layer->name);
|
2012-03-24 06:38:07 +00:00
|
|
|
if (rlpush) {
|
2012-01-05 17:50:09 +00:00
|
|
|
BLI_remlink(&re->pushedresult->layers, rlpush);
|
|
|
|
BLI_addtail(&re->result->layers, rlpush);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
RE_FreeRenderResult(re->pushedresult);
|
2012-06-13 17:23:44 +00:00
|
|
|
re->pushedresult = NULL;
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/************************* EXR Tile File Rendering ***************************/
|
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
static void save_render_result_tile(RenderResult *rr, RenderResult *rrpart, const char *viewname)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2012-09-04 13:29:07 +00:00
|
|
|
RenderLayer *rlp, *rl;
|
2012-01-05 17:50:09 +00:00
|
|
|
RenderPass *rpassp;
|
2020-12-16 16:16:50 +01:00
|
|
|
int partx, party;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-02-16 01:13:46 +11:00
|
|
|
BLI_thread_lock(LOCK_IMAGE);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
for (rlp = rrpart->layers.first; rlp; rlp = rlp->next) {
|
2012-09-04 18:27:47 +00:00
|
|
|
rl = RE_GetRenderLayer(rr, rlp->name);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-09-04 18:27:47 +00:00
|
|
|
/* should never happen but prevents crash if it does */
|
|
|
|
BLI_assert(rl);
|
|
|
|
if (UNLIKELY(rl == NULL)) {
|
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/* passes are allocated in sync */
|
2012-06-13 17:23:44 +00:00
|
|
|
for (rpassp = rlp->passes.first; rpassp; rpassp = rpassp->next) {
|
2015-04-06 10:40:12 -03:00
|
|
|
const int xstride = rpassp->channels;
|
|
|
|
int a;
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
char fullname[EXR_PASS_MAXNAME];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-09-04 18:27:47 +00:00
|
|
|
for (a = 0; a < xstride; a++) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
set_pass_full_name(fullname, rpassp->name, a, viewname, rpassp->chan_id);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
IMB_exr_set_channel(rl->exrhandle,
|
|
|
|
rlp->name,
|
|
|
|
fullname,
|
2012-06-13 17:23:44 +00:00
|
|
|
xstride,
|
|
|
|
xstride * rrpart->rectx,
|
2020-12-16 16:16:50 +01:00
|
|
|
rpassp->rect + a);
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
2020-12-16 16:16:50 +01:00
|
|
|
party = rrpart->tilerect.ymin;
|
|
|
|
partx = rrpart->tilerect.xmin;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-09-04 13:29:07 +00:00
|
|
|
for (rlp = rrpart->layers.first; rlp; rlp = rlp->next) {
|
2012-09-04 18:27:47 +00:00
|
|
|
rl = RE_GetRenderLayer(rr, rlp->name);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-09-04 18:27:47 +00:00
|
|
|
/* should never happen but prevents crash if it does */
|
|
|
|
BLI_assert(rl);
|
|
|
|
if (UNLIKELY(rl == NULL)) {
|
|
|
|
continue;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-01-12 23:47:24 +01:00
|
|
|
IMB_exrtile_write_channels(rl->exrhandle, partx, party, 0, viewname, false);
|
2012-09-04 13:29:07 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-02-16 01:13:46 +11:00
|
|
|
BLI_thread_unlock(LOCK_IMAGE);
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
|
2015-06-17 17:48:15 +02:00
|
|
|
void render_result_save_empty_result_tiles(Render *re)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
|
|
|
RenderResult *rr;
|
2012-09-04 13:29:07 +00:00
|
|
|
RenderLayer *rl;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
for (rr = re->result; rr; rr = rr->next) {
|
2012-09-04 13:29:07 +00:00
|
|
|
for (rl = rr->layers.first; rl; rl = rl->next) {
|
2019-05-19 21:51:18 +02:00
|
|
|
GHashIterator pa_iter;
|
|
|
|
GHASH_ITER (pa_iter, re->parts) {
|
|
|
|
RenderPart *pa = BLI_ghashIterator_getValue(&pa_iter);
|
2017-11-02 14:29:42 +01:00
|
|
|
if (pa->status != PART_STATUS_MERGED) {
|
Remove Blender Internal and legacy viewport from Blender 2.8.
Brecht authored this commit, but he gave me the honours to actually
do it. Here it goes; Blender Internal. Bye bye, you did great!
* Point density, voxel data, ocean, environment map textures were removed,
as these only worked within BI rendering. Note that the ocean modifier
and the Cycles point density shader node continue to work.
* Dynamic paint using material shading was removed, as this only worked
with BI. If we ever wanted to support this again probably it should go
through the baking API.
* GPU shader export through the Python API was removed. This only worked
for the old BI GLSL shaders, which no longer exists. Doing something
similar for Eevee would be significantly more complicated because it
uses a lot of multiplass rendering and logic outside the shader, it's
probably impractical.
* Collada material import / export code is mostly gone, as it only worked
for BI materials. We need to add Cycles / Eevee material support at some
point.
* The mesh noise operator was removed since it only worked with BI
material texture slots. A displacement modifier can be used instead.
* The delete texture paint slot operator was removed since it only worked
for BI material texture slots. Could be added back with node support.
* Not all legacy viewport features are supported in the new viewport, but
their code was removed. If we need to bring anything back we can look at
older git revisions.
* There is some legacy viewport code that I could not remove yet, and some
that I probably missed.
* Shader node execution code was left mostly intact, even though it is not
used anywhere now. We may eventually use this to replace the texture
nodes with Cycles / Eevee shader nodes.
* The Cycles Bake panel now includes settings for baking multires normal
and displacement maps. The underlying code needs to be merged properly,
and we plan to add back support for multires AO baking and add support
to Cycles baking for features like vertex color, displacement, and other
missing baking features.
* This commit removes DNA and the Python API for BI material, lamp, world
and scene settings. This breaks a lot of addons.
* There is more DNA that can be removed or renamed, where Cycles or Eevee
are reusing some old BI properties but the names are not really correct
anymore.
* Texture slots for materials, lamps and world were removed. They remain
for brushes, particles and freestyle linestyles.
* 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and
other renderers use this to find all panels to show, minus a few panels
that they have their own replacement for.
2018-04-19 17:34:44 +02:00
|
|
|
int party = pa->disprect.ymin - re->disprect.ymin;
|
|
|
|
int partx = pa->disprect.xmin - re->disprect.xmin;
|
2018-01-12 23:47:24 +01:00
|
|
|
IMB_exrtile_write_channels(rl->exrhandle, partx, party, 0, re->viewname, true);
|
2012-09-04 13:29:07 +00:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-03-01 19:09:17 +01:00
|
|
|
/* Compute list of passes needed by render engine. */
|
2019-03-01 19:29:26 +01:00
|
|
|
static void templates_register_pass_cb(void *userdata,
|
|
|
|
Scene *UNUSED(scene),
|
|
|
|
ViewLayer *UNUSED(view_layer),
|
2019-03-01 19:09:17 +01:00
|
|
|
const char *name,
|
|
|
|
int channels,
|
|
|
|
const char *chan_id,
|
2020-03-17 13:45:35 -06:00
|
|
|
eNodeSocketDatatype UNUSED(type))
|
Fix T56799: Custom render passes missing when using Save Buffers
The problem here was that when a render result is allocated, the standard render passes are added according to the
pass bitfield. Then, when the render engine sets the result, it adds the additional passes which are then merged
into the main render result.
However, when using Save Buffers, the EXR is created before the actual render starts, so it's missing all those
additional passes.
To fix that, we need to query the render engine for a list of additional passes so they can be added before the EXR
is created. Luckily, there already is a function to do that for the node editor.
The same needs to be done when the EXR is loaded back.
Due to how that is implemented though (Render API calls into engine, engine calls back for each pass), if we have
multiple places that call this function there needs to be a way to tell which one the call came from in the pass
registration callback. Therefore, the original caller now provides a callback that is called for each pass.
2019-01-18 00:45:21 +01:00
|
|
|
{
|
2019-03-01 19:09:17 +01:00
|
|
|
ListBase *templates = userdata;
|
|
|
|
RenderPass *pass = MEM_callocN(sizeof(RenderPass), "RenderPassTemplate");
|
|
|
|
|
|
|
|
pass->channels = channels;
|
|
|
|
BLI_strncpy(pass->name, name, sizeof(pass->name));
|
|
|
|
BLI_strncpy(pass->chan_id, chan_id, sizeof(pass->chan_id));
|
|
|
|
|
|
|
|
BLI_addtail(templates, pass);
|
Fix T56799: Custom render passes missing when using Save Buffers
The problem here was that when a render result is allocated, the standard render passes are added according to the
pass bitfield. Then, when the render engine sets the result, it adds the additional passes which are then merged
into the main render result.
However, when using Save Buffers, the EXR is created before the actual render starts, so it's missing all those
additional passes.
To fix that, we need to query the render engine for a list of additional passes so they can be added before the EXR
is created. Luckily, there already is a function to do that for the node editor.
The same needs to be done when the EXR is loaded back.
Due to how that is implemented though (Render API calls into engine, engine calls back for each pass), if we have
multiple places that call this function there needs to be a way to tell which one the call came from in the pass
registration callback. Therefore, the original caller now provides a callback that is called for each pass.
2019-01-18 00:45:21 +01:00
|
|
|
}
|
|
|
|
|
2019-03-01 19:09:17 +01:00
|
|
|
static void render_result_get_pass_templates(RenderEngine *engine,
|
|
|
|
Render *re,
|
|
|
|
RenderLayer *rl,
|
|
|
|
ListBase *templates)
|
Fix T56799: Custom render passes missing when using Save Buffers
The problem here was that when a render result is allocated, the standard render passes are added according to the
pass bitfield. Then, when the render engine sets the result, it adds the additional passes which are then merged
into the main render result.
However, when using Save Buffers, the EXR is created before the actual render starts, so it's missing all those
additional passes.
To fix that, we need to query the render engine for a list of additional passes so they can be added before the EXR
is created. Luckily, there already is a function to do that for the node editor.
The same needs to be done when the EXR is loaded back.
Due to how that is implemented though (Render API calls into engine, engine calls back for each pass), if we have
multiple places that call this function there needs to be a way to tell which one the call came from in the pass
registration callback. Therefore, the original caller now provides a callback that is called for each pass.
2019-01-18 00:45:21 +01:00
|
|
|
{
|
2019-03-01 19:09:17 +01:00
|
|
|
BLI_listbase_clear(templates);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Fix T56799: Custom render passes missing when using Save Buffers
The problem here was that when a render result is allocated, the standard render passes are added according to the
pass bitfield. Then, when the render engine sets the result, it adds the additional passes which are then merged
into the main render result.
However, when using Save Buffers, the EXR is created before the actual render starts, so it's missing all those
additional passes.
To fix that, we need to query the render engine for a list of additional passes so they can be added before the EXR
is created. Luckily, there already is a function to do that for the node editor.
The same needs to be done when the EXR is loaded back.
Due to how that is implemented though (Render API calls into engine, engine calls back for each pass), if we have
multiple places that call this function there needs to be a way to tell which one the call came from in the pass
registration callback. Therefore, the original caller now provides a callback that is called for each pass.
2019-01-18 00:45:21 +01:00
|
|
|
if (engine && engine->type->update_render_passes) {
|
2019-03-01 19:29:26 +01:00
|
|
|
ViewLayer *view_layer = BLI_findstring(&re->view_layers, rl->name, offsetof(ViewLayer, name));
|
2019-01-18 01:47:32 +01:00
|
|
|
if (view_layer) {
|
2019-03-01 19:29:26 +01:00
|
|
|
RE_engine_update_render_passes(
|
|
|
|
engine, re->scene, view_layer, templates_register_pass_cb, templates);
|
Fix T56799: Custom render passes missing when using Save Buffers
The problem here was that when a render result is allocated, the standard render passes are added according to the
pass bitfield. Then, when the render engine sets the result, it adds the additional passes which are then merged
into the main render result.
However, when using Save Buffers, the EXR is created before the actual render starts, so it's missing all those
additional passes.
To fix that, we need to query the render engine for a list of additional passes so they can be added before the EXR
is created. Luckily, there already is a function to do that for the node editor.
The same needs to be done when the EXR is loaded back.
Due to how that is implemented though (Render API calls into engine, engine calls back for each pass), if we have
multiple places that call this function there needs to be a way to tell which one the call came from in the pass
registration callback. Therefore, the original caller now provides a callback that is called for each pass.
2019-01-18 00:45:21 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/* begin write of exr tile file */
|
Fix T56799: Custom render passes missing when using Save Buffers
The problem here was that when a render result is allocated, the standard render passes are added according to the
pass bitfield. Then, when the render engine sets the result, it adds the additional passes which are then merged
into the main render result.
However, when using Save Buffers, the EXR is created before the actual render starts, so it's missing all those
additional passes.
To fix that, we need to query the render engine for a list of additional passes so they can be added before the EXR
is created. Luckily, there already is a function to do that for the node editor.
The same needs to be done when the EXR is loaded back.
Due to how that is implemented though (Render API calls into engine, engine calls back for each pass), if we have
multiple places that call this function there needs to be a way to tell which one the call came from in the pass
registration callback. Therefore, the original caller now provides a callback that is called for each pass.
2019-01-18 00:45:21 +01:00
|
|
|
void render_result_exr_file_begin(Render *re, RenderEngine *engine)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
|
|
|
char str[FILE_MAX];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-01 19:09:17 +01:00
|
|
|
for (RenderResult *rr = re->result; rr; rr = rr->next) {
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (RenderLayer *, rl, &rr->layers) {
|
2019-03-01 19:09:17 +01:00
|
|
|
/* Get passes needed by engine. Normally we would wait for the
|
|
|
|
* engine to create them, but for EXR file we need to know in
|
|
|
|
* advance. */
|
|
|
|
ListBase templates;
|
|
|
|
render_result_get_pass_templates(engine, re, rl, &templates);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-01 19:09:17 +01:00
|
|
|
/* Create render passes requested by engine. Only this part is
|
|
|
|
* mutex locked to avoid deadlock with Python GIL. */
|
|
|
|
BLI_rw_mutex_lock(&re->resultmutex, THREAD_LOCK_WRITE);
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (RenderPass *, pass, &templates) {
|
2020-02-13 01:29:30 +01:00
|
|
|
RE_create_render_pass(
|
2019-03-01 19:09:17 +01:00
|
|
|
re->result, pass->name, pass->channels, pass->chan_id, rl->name, NULL);
|
|
|
|
}
|
|
|
|
BLI_rw_mutex_unlock(&re->resultmutex);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-01 19:09:17 +01:00
|
|
|
BLI_freelistN(&templates);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-01 19:09:17 +01:00
|
|
|
/* Open EXR file for writing. */
|
2012-09-04 13:29:07 +00:00
|
|
|
render_result_exr_file_path(re->scene, rl->name, rr->sample_nr, str);
|
|
|
|
printf("write exr tmp file, %dx%d, %s\n", rr->rectx, rr->recty, str);
|
|
|
|
IMB_exrtile_begin_write(rl->exrhandle, str, 0, rr->rectx, rr->recty, re->partx, re->party);
|
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* end write of exr tile file, read back first sample */
|
Fix T56799: Custom render passes missing when using Save Buffers
The problem here was that when a render result is allocated, the standard render passes are added according to the
pass bitfield. Then, when the render engine sets the result, it adds the additional passes which are then merged
into the main render result.
However, when using Save Buffers, the EXR is created before the actual render starts, so it's missing all those
additional passes.
To fix that, we need to query the render engine for a list of additional passes so they can be added before the EXR
is created. Luckily, there already is a function to do that for the node editor.
The same needs to be done when the EXR is loaded back.
Due to how that is implemented though (Render API calls into engine, engine calls back for each pass), if we have
multiple places that call this function there needs to be a way to tell which one the call came from in the pass
registration callback. Therefore, the original caller now provides a callback that is called for each pass.
2019-01-18 00:45:21 +01:00
|
|
|
void render_result_exr_file_end(Render *re, RenderEngine *engine)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2021-01-20 13:27:27 +01:00
|
|
|
/* Preserve stamp data. */
|
|
|
|
struct StampData *stamp_data = re->result->stamp_data;
|
|
|
|
re->result->stamp_data = NULL;
|
|
|
|
|
2019-03-01 19:09:17 +01:00
|
|
|
/* Close EXR files. */
|
|
|
|
for (RenderResult *rr = re->result; rr; rr = rr->next) {
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (RenderLayer *, rl, &rr->layers) {
|
2012-09-04 13:29:07 +00:00
|
|
|
IMB_exr_close(rl->exrhandle);
|
|
|
|
rl->exrhandle = NULL;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-04-01 11:34:00 +11:00
|
|
|
rr->do_exr_tile = false;
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-01 19:09:17 +01:00
|
|
|
/* Create new render result in memory instead of on disk. */
|
|
|
|
BLI_rw_mutex_lock(&re->resultmutex, THREAD_LOCK_WRITE);
|
2012-01-05 17:50:09 +00:00
|
|
|
render_result_free_list(&re->fullresult, re->result);
|
2020-12-16 16:16:50 +01:00
|
|
|
re->result = render_result_new(re, &re->disprect, RR_USE_MEM, RR_ALL_LAYERS, RR_ALL_VIEWS);
|
2021-01-20 13:27:27 +01:00
|
|
|
re->result->stamp_data = stamp_data;
|
2019-03-01 19:09:17 +01:00
|
|
|
BLI_rw_mutex_unlock(&re->resultmutex);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (RenderLayer *, rl, &re->result->layers) {
|
2019-03-01 19:09:17 +01:00
|
|
|
/* Get passes needed by engine. */
|
|
|
|
ListBase templates;
|
|
|
|
render_result_get_pass_templates(engine, re, rl, &templates);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-01 19:09:17 +01:00
|
|
|
/* Create render passes requested by engine. Only this part is
|
|
|
|
* mutex locked to avoid deadlock with Python GIL. */
|
|
|
|
BLI_rw_mutex_lock(&re->resultmutex, THREAD_LOCK_WRITE);
|
2020-04-03 19:15:01 +02:00
|
|
|
LISTBASE_FOREACH (RenderPass *, pass, &templates) {
|
2020-02-13 01:29:30 +01:00
|
|
|
RE_create_render_pass(re->result, pass->name, pass->channels, pass->chan_id, rl->name, NULL);
|
2019-03-01 19:09:17 +01:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-01 19:09:17 +01:00
|
|
|
BLI_freelistN(&templates);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-01 19:09:17 +01:00
|
|
|
/* Render passes contents from file. */
|
|
|
|
char str[FILE_MAXFILE + MAX_ID_NAME + MAX_ID_NAME + 100] = "";
|
|
|
|
render_result_exr_file_path(re->scene, rl->name, 0, str);
|
|
|
|
printf("read exr tmp file: %s\n", str);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-03-01 19:09:17 +01:00
|
|
|
if (!render_result_exr_file_read_path(re->result, rl, str)) {
|
|
|
|
printf("cannot read: %s\n", str);
|
|
|
|
}
|
|
|
|
BLI_rw_mutex_unlock(&re->resultmutex);
|
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* save part into exr file */
|
2015-04-06 10:40:12 -03:00
|
|
|
void render_result_exr_file_merge(RenderResult *rr, RenderResult *rrpart, const char *viewname)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2019-04-22 09:08:06 +10:00
|
|
|
for (; rr && rrpart; rr = rr->next, rrpart = rrpart->next) {
|
2015-04-06 10:40:12 -03:00
|
|
|
save_render_result_tile(rr, rrpart, viewname);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* path to temporary exr file */
|
2012-09-04 13:29:07 +00:00
|
|
|
void render_result_exr_file_path(Scene *scene, const char *layname, int sample, char *filepath)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2015-07-14 09:34:53 +10:00
|
|
|
char name[FILE_MAXFILE + MAX_ID_NAME + MAX_ID_NAME + 100];
|
2018-06-05 15:10:33 +02:00
|
|
|
const char *fi = BLI_path_basename(BKE_main_blendfile_path_from_global());
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2014-04-02 11:57:10 +02:00
|
|
|
if (sample == 0) {
|
T39690: Modifications to Blender's 'temp dir' system.
Current temporary data of Blender suffers one major issue - default 'temp' dir on Windows is never
automatically cleaned up, and can end being quite big when used by Blender, especially when we have
to store per-process data (using getpid() in file names).
To address this, this patch:
* Divides tempdir paths in two, one for 'base' temp dir (the same as previous unique tempdir path),
the other is a mkdtemp-generated sub-dir, specific to each Blender instance.
* Only uses base tempdir when we need some shallow persistance accross Blender sessions - and we always
reuse the same filename (quit.blend...) or generate small file (crash reports...).
* Uses temp sub-dir for heavy files like pointcache or renderEXRs (Save Buffer option).
* Erases temp sub-dir on quit or crash.
To get this working it also adds a working 'recursive delete' to BLI_delete() under Windows.
Note that, as in current code, the 'recover render result' hack-feature that was possible
with SaveBuffer option is still removed. A real renderresult cache feature will be added
soon, though.
Reviewers: campbellbarton, brecht, sergey
Reviewed By: campbellbarton, sergey
CC: sergey
Differential Revision: https://developer.blender.org/D531
2014-06-23 13:42:19 +02:00
|
|
|
BLI_snprintf(name, sizeof(name), "%s_%s_%s.exr", fi, scene->id.name + 2, layname);
|
2014-04-02 11:57:10 +02:00
|
|
|
}
|
|
|
|
else {
|
T39690: Modifications to Blender's 'temp dir' system.
Current temporary data of Blender suffers one major issue - default 'temp' dir on Windows is never
automatically cleaned up, and can end being quite big when used by Blender, especially when we have
to store per-process data (using getpid() in file names).
To address this, this patch:
* Divides tempdir paths in two, one for 'base' temp dir (the same as previous unique tempdir path),
the other is a mkdtemp-generated sub-dir, specific to each Blender instance.
* Only uses base tempdir when we need some shallow persistance accross Blender sessions - and we always
reuse the same filename (quit.blend...) or generate small file (crash reports...).
* Uses temp sub-dir for heavy files like pointcache or renderEXRs (Save Buffer option).
* Erases temp sub-dir on quit or crash.
To get this working it also adds a working 'recursive delete' to BLI_delete() under Windows.
Note that, as in current code, the 'recover render result' hack-feature that was possible
with SaveBuffer option is still removed. A real renderresult cache feature will be added
soon, though.
Reviewers: campbellbarton, brecht, sergey
Reviewed By: campbellbarton, sergey
CC: sergey
Differential Revision: https://developer.blender.org/D531
2014-06-23 13:42:19 +02:00
|
|
|
BLI_snprintf(name, sizeof(name), "%s_%s_%s%d.exr", fi, scene->id.name + 2, layname, sample);
|
2014-04-02 11:57:10 +02:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
|
2015-01-16 18:48:59 +01:00
|
|
|
/* Make name safe for paths, see T43275. */
|
|
|
|
BLI_filename_make_safe(name);
|
|
|
|
|
2020-03-07 13:23:26 +11:00
|
|
|
BLI_join_dirfile(filepath, FILE_MAX, BKE_tempdir_session(), name);
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* called for reading temp files, and for external engines */
|
2012-09-04 13:29:07 +00:00
|
|
|
int render_result_exr_file_read_path(RenderResult *rr,
|
|
|
|
RenderLayer *rl_single,
|
|
|
|
const char *filepath)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
|
|
|
RenderLayer *rl;
|
|
|
|
RenderPass *rpass;
|
2012-06-13 17:23:44 +00:00
|
|
|
void *exrhandle = IMB_exr_get_handle();
|
2012-01-05 17:50:09 +00:00
|
|
|
int rectx, recty;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
if (IMB_exr_begin_read(exrhandle, filepath, &rectx, &recty) == 0) {
|
2012-01-05 17:50:09 +00:00
|
|
|
printf("failed being read %s\n", filepath);
|
|
|
|
IMB_exr_close(exrhandle);
|
|
|
|
return 0;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
if (rr == NULL || rectx != rr->rectx || recty != rr->recty) {
|
2019-04-22 09:08:06 +10:00
|
|
|
if (rr) {
|
2012-01-05 17:50:09 +00:00
|
|
|
printf("error in reading render result: dimensions don't match\n");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
else {
|
2012-01-05 17:50:09 +00:00
|
|
|
printf("error in reading render result: NULL result pointer\n");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
IMB_exr_close(exrhandle);
|
|
|
|
return 0;
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-13 17:23:44 +00:00
|
|
|
for (rl = rr->layers.first; rl; rl = rl->next) {
|
2019-04-22 09:08:06 +10:00
|
|
|
if (rl_single && rl_single != rl) {
|
2012-09-04 13:29:07 +00:00
|
|
|
continue;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/* passes are allocated in sync */
|
2012-06-13 17:23:44 +00:00
|
|
|
for (rpass = rl->passes.first; rpass; rpass = rpass->next) {
|
2015-04-06 10:40:12 -03:00
|
|
|
const int xstride = rpass->channels;
|
|
|
|
int a;
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
char fullname[EXR_PASS_MAXNAME];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
for (a = 0; a < xstride; a++) {
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
set_pass_full_name(fullname, rpass->name, a, rpass->view, rpass->chan_id);
|
|
|
|
IMB_exr_set_channel(
|
2012-06-13 17:23:44 +00:00
|
|
|
exrhandle, rl->name, fullname, xstride, xstride * rectx, rpass->rect + a);
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
set_pass_full_name(rpass->fullname, rpass->name, -1, rpass->view, rpass->chan_id);
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
IMB_exr_read_channels(exrhandle);
|
|
|
|
IMB_exr_close(exrhandle);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2014-06-28 19:13:54 +02:00
|
|
|
static void render_result_exr_file_cache_path(Scene *sce, const char *root, char *r_path)
|
|
|
|
{
|
|
|
|
char filename_full[FILE_MAX + MAX_ID_NAME + 100], filename[FILE_MAXFILE], dirname[FILE_MAXDIR];
|
|
|
|
char path_digest[16] = {0};
|
|
|
|
char path_hexdigest[33];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-06-28 19:13:54 +02:00
|
|
|
/* If root is relative, use either current .blend file dir, or temp one if not saved. */
|
2018-06-05 15:10:33 +02:00
|
|
|
const char *blendfile_path = BKE_main_blendfile_path_from_global();
|
|
|
|
if (blendfile_path[0] != '\0') {
|
|
|
|
BLI_split_dirfile(blendfile_path, dirname, filename, sizeof(dirname), sizeof(filename));
|
2018-06-17 16:13:24 +02:00
|
|
|
BLI_path_extension_replace(filename, sizeof(filename), ""); /* strip '.blend' */
|
2018-06-05 15:10:33 +02:00
|
|
|
BLI_hash_md5_buffer(blendfile_path, strlen(blendfile_path), path_digest);
|
2014-06-28 19:13:54 +02:00
|
|
|
}
|
|
|
|
else {
|
2014-11-23 15:54:29 +01:00
|
|
|
BLI_strncpy(dirname, BKE_tempdir_base(), sizeof(dirname));
|
2014-06-28 19:13:54 +02:00
|
|
|
BLI_strncpy(filename, "UNSAVED", sizeof(filename));
|
|
|
|
}
|
2014-11-14 11:53:27 +01:00
|
|
|
BLI_hash_md5_to_hexdigest(path_digest, path_hexdigest);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-06-28 19:13:54 +02:00
|
|
|
/* Default to *non-volatile* tmp dir. */
|
|
|
|
if (*root == '\0') {
|
2014-11-23 15:54:29 +01:00
|
|
|
root = BKE_tempdir_base();
|
2014-06-28 19:13:54 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-06-28 19:13:54 +02:00
|
|
|
BLI_snprintf(filename_full,
|
|
|
|
sizeof(filename_full),
|
|
|
|
"cached_RR_%s_%s_%s.exr",
|
|
|
|
filename,
|
|
|
|
sce->id.name + 2,
|
|
|
|
path_hexdigest);
|
|
|
|
BLI_make_file_string(dirname, r_path, root, filename_full);
|
|
|
|
}
|
|
|
|
|
|
|
|
void render_result_exr_file_cache_write(Render *re)
|
|
|
|
{
|
|
|
|
RenderResult *rr = re->result;
|
|
|
|
char str[FILE_MAXFILE + FILE_MAXFILE + MAX_ID_NAME + 100];
|
|
|
|
char *root = U.render_cachedir;
|
|
|
|
|
|
|
|
render_result_exr_file_cache_path(re->scene, root, str);
|
|
|
|
printf("Caching exr file, %dx%d, %s\n", rr->rectx, rr->recty, str);
|
2015-04-06 10:40:12 -03:00
|
|
|
|
2017-10-20 15:18:26 +02:00
|
|
|
RE_WriteRenderResult(NULL, rr, str, NULL, NULL, -1);
|
2014-06-28 19:13:54 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* For cache, makes exact copy of render result */
|
|
|
|
bool render_result_exr_file_cache_read(Render *re)
|
|
|
|
{
|
|
|
|
char str[FILE_MAXFILE + MAX_ID_NAME + MAX_ID_NAME + 100] = "";
|
|
|
|
char *root = U.render_cachedir;
|
|
|
|
|
|
|
|
RE_FreeRenderResult(re->result);
|
2020-12-16 16:16:50 +01:00
|
|
|
re->result = render_result_new(re, &re->disprect, RR_USE_MEM, RR_ALL_LAYERS, RR_ALL_VIEWS);
|
2014-06-28 19:13:54 +02:00
|
|
|
|
|
|
|
/* First try cache. */
|
|
|
|
render_result_exr_file_cache_path(re->scene, root, str);
|
|
|
|
|
|
|
|
printf("read exr cache file: %s\n", str);
|
|
|
|
if (!render_result_exr_file_read_path(re->result, NULL, str)) {
|
|
|
|
printf("cannot read: %s\n", str);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/*************************** Combined Pixel Rect *****************************/
|
|
|
|
|
2020-03-13 17:27:11 +11:00
|
|
|
ImBuf *render_result_rect_to_ibuf(RenderResult *rr, const RenderData *rd, const int view_id)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2012-12-31 13:52:13 +00:00
|
|
|
ImBuf *ibuf = IMB_allocImBuf(rr->rectx, rr->recty, rd->im_format.planes, 0);
|
2015-04-29 11:26:30 -03:00
|
|
|
RenderView *rv = RE_RenderViewGetById(rr, view_id);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-05-05 16:03:57 +00:00
|
|
|
/* if not exists, BKE_imbuf_write makes one */
|
2019-03-25 11:55:36 +11:00
|
|
|
ibuf->rect = (unsigned int *)rv->rect32;
|
2015-04-29 11:26:30 -03:00
|
|
|
ibuf->rect_float = rv->rectf;
|
|
|
|
ibuf->zbuf_float = rv->rectz;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/* float factor for random dither, imbuf takes care of it */
|
2012-06-13 17:23:44 +00:00
|
|
|
ibuf->dither = rd->dither_intensity;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Color Management, Stage 2: Switch color pipeline to use OpenColorIO
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
2012-09-15 10:05:07 +00:00
|
|
|
/* prepare to gamma correct to sRGB color space
|
|
|
|
* note that sequence editor can generate 8bpc render buffers
|
|
|
|
*/
|
|
|
|
if (ibuf->rect) {
|
|
|
|
if (BKE_imtype_valid_depths(rd->im_format.imtype) &
|
|
|
|
(R_IMF_CHAN_DEPTH_12 | R_IMF_CHAN_DEPTH_16 | R_IMF_CHAN_DEPTH_24 | R_IMF_CHAN_DEPTH_32)) {
|
2013-11-22 16:48:08 +06:00
|
|
|
if (rd->im_format.depth == R_IMF_CHAN_DEPTH_8) {
|
|
|
|
/* Higher depth bits are supported but not needed for current file output. */
|
|
|
|
ibuf->rect_float = NULL;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
IMB_float_from_rect(ibuf);
|
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
2013-03-24 12:13:13 +00:00
|
|
|
else {
|
2013-02-10 09:27:25 +00:00
|
|
|
/* ensure no float buffer remained from previous frame */
|
|
|
|
ibuf->rect_float = NULL;
|
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-07-03 19:09:07 +00:00
|
|
|
/* color -> grayscale */
|
2012-01-05 17:50:09 +00:00
|
|
|
/* editing directly would alter the render view */
|
2012-03-24 06:38:07 +00:00
|
|
|
if (rd->im_format.planes == R_IMF_PLANES_BW) {
|
2012-06-13 17:23:44 +00:00
|
|
|
ImBuf *ibuf_bw = IMB_dupImBuf(ibuf);
|
2012-01-05 17:50:09 +00:00
|
|
|
IMB_color_to_bw(ibuf_bw);
|
|
|
|
IMB_freeImBuf(ibuf);
|
2012-06-13 17:23:44 +00:00
|
|
|
ibuf = ibuf_bw;
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
return ibuf;
|
|
|
|
}
|
|
|
|
|
2015-11-16 18:20:41 +05:00
|
|
|
void RE_render_result_rect_from_ibuf(RenderResult *rr,
|
|
|
|
RenderData *UNUSED(rd),
|
|
|
|
ImBuf *ibuf,
|
|
|
|
const int view_id)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2015-04-29 11:18:18 -03:00
|
|
|
RenderView *rv = RE_RenderViewGetById(rr, view_id);
|
2015-04-06 10:40:12 -03:00
|
|
|
|
2012-03-24 06:38:07 +00:00
|
|
|
if (ibuf->rect_float) {
|
2018-01-25 14:07:51 +01:00
|
|
|
rr->have_combined = true;
|
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (!rv->rectf) {
|
2020-08-08 13:29:21 +10:00
|
|
|
rv->rectf = MEM_mallocN(sizeof(float[4]) * rr->rectx * rr->recty, "render_seq rectf");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2020-08-08 13:29:21 +10:00
|
|
|
memcpy(rv->rectf, ibuf->rect_float, sizeof(float[4]) * rr->rectx * rr->recty);
|
Color Management, Stage 2: Switch color pipeline to use OpenColorIO
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
2012-09-15 10:05:07 +00:00
|
|
|
|
2012-01-05 17:50:09 +00:00
|
|
|
/* TSK! Since sequence render doesn't free the *rr render result, the old rect32
|
2012-03-09 18:28:30 +00:00
|
|
|
* can hang around when sequence render has rendered a 32 bits one before */
|
2015-04-09 17:19:50 +10:00
|
|
|
MEM_SAFE_FREE(rv->rect32);
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
2012-03-24 06:38:07 +00:00
|
|
|
else if (ibuf->rect) {
|
2018-01-25 14:07:51 +01:00
|
|
|
rr->have_combined = true;
|
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (!rv->rect32) {
|
2015-04-06 10:40:12 -03:00
|
|
|
rv->rect32 = MEM_mallocN(sizeof(int) * rr->rectx * rr->recty, "render_seq rect");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
memcpy(rv->rect32, ibuf->rect, 4 * rr->rectx * rr->recty);
|
2012-01-05 17:50:09 +00:00
|
|
|
|
|
|
|
/* Same things as above, old rectf can hang around from previous render. */
|
2015-04-09 17:19:50 +10:00
|
|
|
MEM_SAFE_FREE(rv->rectf);
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
void render_result_rect_fill_zero(RenderResult *rr, const int view_id)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2015-04-29 11:18:18 -03:00
|
|
|
RenderView *rv = RE_RenderViewGetById(rr, view_id);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (rv->rectf) {
|
2020-08-08 13:29:21 +10:00
|
|
|
memset(rv->rectf, 0, sizeof(float[4]) * rr->rectx * rr->recty);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
else if (rv->rect32) {
|
2015-04-06 10:40:12 -03:00
|
|
|
memset(rv->rect32, 0, 4 * rr->rectx * rr->recty);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
else {
|
2015-04-06 10:40:12 -03:00
|
|
|
rv->rect32 = MEM_callocN(sizeof(int) * rr->rectx * rr->recty, "render_seq rect");
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
|
2012-12-31 13:52:13 +00:00
|
|
|
void render_result_rect_get_pixels(RenderResult *rr,
|
|
|
|
unsigned int *rect,
|
|
|
|
int rectx,
|
|
|
|
int recty,
|
2015-04-06 10:40:12 -03:00
|
|
|
const ColorManagedViewSettings *view_settings,
|
|
|
|
const ColorManagedDisplaySettings *display_settings,
|
|
|
|
const int view_id)
|
2012-01-05 17:50:09 +00:00
|
|
|
{
|
2015-04-29 11:26:30 -03:00
|
|
|
RenderView *rv = RE_RenderViewGetById(rr, view_id);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-01-20 11:30:19 +01:00
|
|
|
if (rv && rv->rect32) {
|
2015-04-29 11:26:30 -03:00
|
|
|
memcpy(rect, rv->rect32, sizeof(int) * rr->rectx * rr->recty);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2020-01-20 11:30:19 +01:00
|
|
|
else if (rv && rv->rectf) {
|
2019-03-25 11:55:36 +11:00
|
|
|
IMB_display_buffer_transform_apply((unsigned char *)rect,
|
|
|
|
rv->rectf,
|
|
|
|
rr->rectx,
|
|
|
|
rr->recty,
|
|
|
|
4,
|
2013-09-05 17:13:43 +00:00
|
|
|
view_settings,
|
|
|
|
display_settings,
|
|
|
|
true);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
else {
|
2012-01-05 17:50:09 +00:00
|
|
|
/* else fill with black */
|
2012-06-13 17:23:44 +00:00
|
|
|
memset(rect, 0, sizeof(int) * rectx * recty);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2012-01-05 17:50:09 +00:00
|
|
|
}
|
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
/*************************** multiview functions *****************************/
|
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
bool RE_HasCombinedLayer(RenderResult *rr)
|
2015-04-06 10:40:12 -03:00
|
|
|
{
|
|
|
|
RenderView *rv;
|
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
if (rr == NULL) {
|
2015-04-06 10:40:12 -03:00
|
|
|
return false;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
rv = rr->views.first;
|
2019-04-22 09:08:06 +10:00
|
|
|
if (rv == NULL) {
|
2015-04-06 10:40:12 -03:00
|
|
|
return false;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
|
|
|
|
return (rv->rect32 || rv->rectf);
|
|
|
|
}
|
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
bool RE_HasFloatPixels(RenderResult *rr)
|
2018-01-24 15:55:54 +01:00
|
|
|
{
|
|
|
|
RenderView *rview;
|
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
for (rview = rr->views.first; rview; rview = rview->next) {
|
2018-01-24 15:55:54 +01:00
|
|
|
if (rview->rect32 && !rview->rectf) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
bool RE_RenderResult_is_stereo(RenderResult *rr)
|
2015-04-06 10:40:12 -03:00
|
|
|
{
|
2020-09-04 20:59:13 +02:00
|
|
|
if (!BLI_findstring(&rr->views, STEREO_LEFT_NAME, offsetof(RenderView, name))) {
|
2015-04-06 10:40:12 -03:00
|
|
|
return false;
|
2019-03-25 11:55:36 +11:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
if (!BLI_findstring(&rr->views, STEREO_RIGHT_NAME, offsetof(RenderView, name))) {
|
2015-04-06 10:40:12 -03:00
|
|
|
return false;
|
2019-03-25 11:55:36 +11:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
RenderView *RE_RenderViewGetById(RenderResult *rr, const int view_id)
|
2015-04-29 11:18:18 -03:00
|
|
|
{
|
2020-09-04 20:59:13 +02:00
|
|
|
RenderView *rv = BLI_findlink(&rr->views, view_id);
|
|
|
|
BLI_assert(rr->views.first);
|
|
|
|
return rv ? rv : rr->views.first;
|
2015-04-29 11:18:18 -03:00
|
|
|
}
|
|
|
|
|
2020-09-04 20:59:13 +02:00
|
|
|
RenderView *RE_RenderViewGetByName(RenderResult *rr, const char *viewname)
|
2015-04-29 11:18:18 -03:00
|
|
|
{
|
2020-09-04 20:59:13 +02:00
|
|
|
RenderView *rv = BLI_findstring(&rr->views, viewname, offsetof(RenderView, name));
|
|
|
|
BLI_assert(rr->views.first);
|
|
|
|
return rv ? rv : rr->views.first;
|
2015-04-29 11:18:18 -03:00
|
|
|
}
|
2016-09-16 10:28:41 +02:00
|
|
|
|
|
|
|
static RenderPass *duplicate_render_pass(RenderPass *rpass)
|
|
|
|
{
|
|
|
|
RenderPass *new_rpass = MEM_mallocN(sizeof(RenderPass), "new render pass");
|
|
|
|
*new_rpass = *rpass;
|
|
|
|
new_rpass->next = new_rpass->prev = NULL;
|
|
|
|
if (new_rpass->rect != NULL) {
|
|
|
|
new_rpass->rect = MEM_dupallocN(new_rpass->rect);
|
|
|
|
}
|
|
|
|
return new_rpass;
|
|
|
|
}
|
|
|
|
|
|
|
|
static RenderLayer *duplicate_render_layer(RenderLayer *rl)
|
|
|
|
{
|
|
|
|
RenderLayer *new_rl = MEM_mallocN(sizeof(RenderLayer), "new render layer");
|
|
|
|
*new_rl = *rl;
|
|
|
|
new_rl->next = new_rl->prev = NULL;
|
|
|
|
new_rl->passes.first = new_rl->passes.last = NULL;
|
|
|
|
new_rl->exrhandle = NULL;
|
|
|
|
for (RenderPass *rpass = rl->passes.first; rpass != NULL; rpass = rpass->next) {
|
|
|
|
RenderPass *new_rpass = duplicate_render_pass(rpass);
|
|
|
|
BLI_addtail(&new_rl->passes, new_rpass);
|
|
|
|
}
|
|
|
|
return new_rl;
|
|
|
|
}
|
|
|
|
|
|
|
|
static RenderView *duplicate_render_view(RenderView *rview)
|
|
|
|
{
|
|
|
|
RenderView *new_rview = MEM_mallocN(sizeof(RenderView), "new render view");
|
|
|
|
*new_rview = *rview;
|
|
|
|
if (new_rview->rectf != NULL) {
|
|
|
|
new_rview->rectf = MEM_dupallocN(new_rview->rectf);
|
|
|
|
}
|
|
|
|
if (new_rview->rectz != NULL) {
|
|
|
|
new_rview->rectz = MEM_dupallocN(new_rview->rectz);
|
|
|
|
}
|
|
|
|
if (new_rview->rect32 != NULL) {
|
|
|
|
new_rview->rect32 = MEM_dupallocN(new_rview->rect32);
|
|
|
|
}
|
|
|
|
return new_rview;
|
|
|
|
}
|
|
|
|
|
|
|
|
RenderResult *RE_DuplicateRenderResult(RenderResult *rr)
|
|
|
|
{
|
2016-10-07 16:06:24 +02:00
|
|
|
RenderResult *new_rr = MEM_mallocN(sizeof(RenderResult), "new duplicated render result");
|
2016-09-16 10:28:41 +02:00
|
|
|
*new_rr = *rr;
|
|
|
|
new_rr->next = new_rr->prev = NULL;
|
|
|
|
new_rr->layers.first = new_rr->layers.last = NULL;
|
|
|
|
new_rr->views.first = new_rr->views.last = NULL;
|
|
|
|
for (RenderLayer *rl = rr->layers.first; rl != NULL; rl = rl->next) {
|
|
|
|
RenderLayer *new_rl = duplicate_render_layer(rl);
|
|
|
|
BLI_addtail(&new_rr->layers, new_rl);
|
|
|
|
}
|
|
|
|
for (RenderView *rview = rr->views.first; rview != NULL; rview = rview->next) {
|
|
|
|
RenderView *new_rview = duplicate_render_view(rview);
|
|
|
|
BLI_addtail(&new_rr->views, new_rview);
|
|
|
|
}
|
|
|
|
if (new_rr->rect32 != NULL) {
|
|
|
|
new_rr->rect32 = MEM_dupallocN(new_rr->rect32);
|
|
|
|
}
|
|
|
|
if (new_rr->rectf != NULL) {
|
|
|
|
new_rr->rectf = MEM_dupallocN(new_rr->rectf);
|
|
|
|
}
|
|
|
|
if (new_rr->rectz != NULL) {
|
|
|
|
new_rr->rectz = MEM_dupallocN(new_rr->rectz);
|
|
|
|
}
|
2019-02-25 19:51:36 +01:00
|
|
|
new_rr->stamp_data = BKE_stamp_data_copy(new_rr->stamp_data);
|
2016-09-16 10:28:41 +02:00
|
|
|
return new_rr;
|
|
|
|
}
|