2012-04-30 14:24:11 +00:00
|
|
|
/*
|
2011-10-22 16:24:28 +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-03-02 11:09:24 +11:00
|
|
|
* of the License, or (at your option) any later version.
|
2011-10-22 16:24:28 +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
|
2011-10-22 16:24:28 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <stddef.h>
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
2015-08-16 17:32:01 +10:00
|
|
|
#include "BLT_translation.h"
|
2012-03-03 21:42:21 +00:00
|
|
|
|
2019-05-19 21:51:18 +02:00
|
|
|
#include "BLI_ghash.h"
|
2011-10-22 16:24:28 +00:00
|
|
|
#include "BLI_listbase.h"
|
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
|
|
|
#include "BLI_math_bits.h"
|
2019-05-19 21:51:18 +02:00
|
|
|
#include "BLI_rect.h"
|
2011-10-22 16:24:28 +00:00
|
|
|
#include "BLI_string.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLI_utildefines.h"
|
2011-10-22 16:24:28 +00:00
|
|
|
|
2018-02-20 12:55:02 -03:00
|
|
|
#include "DNA_object_types.h"
|
|
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
#include "BKE_camera.h"
|
2015-12-31 14:49:58 +05:00
|
|
|
#include "BKE_colortools.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BKE_global.h"
|
2017-02-07 11:20:15 +01:00
|
|
|
#include "BKE_layer.h"
|
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
|
|
|
#include "BKE_node.h"
|
2011-10-22 16:24:28 +00:00
|
|
|
#include "BKE_report.h"
|
|
|
|
|
#include "BKE_scene.h"
|
|
|
|
|
|
2017-04-25 16:18:24 +02:00
|
|
|
#include "DEG_depsgraph.h"
|
2018-05-02 16:26:12 +02:00
|
|
|
#include "DEG_depsgraph_debug.h"
|
2018-02-20 12:55:02 -03:00
|
|
|
#include "DEG_depsgraph_query.h"
|
2017-04-25 16:18:24 +02:00
|
|
|
|
2013-09-10 20:26:34 +00:00
|
|
|
#include "RNA_access.h"
|
|
|
|
|
|
2011-10-22 17:01:54 +00:00
|
|
|
#ifdef WITH_PYTHON
|
|
|
|
|
# include "BPY_extern.h"
|
|
|
|
|
#endif
|
|
|
|
|
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "RE_bake.h"
|
2011-10-22 16:24:28 +00:00
|
|
|
#include "RE_engine.h"
|
|
|
|
|
#include "RE_pipeline.h"
|
|
|
|
|
|
2017-02-07 11:20:15 +01:00
|
|
|
#include "DRW_engine.h"
|
|
|
|
|
|
2012-09-04 13:29:07 +00:00
|
|
|
#include "initrender.h"
|
2020-11-06 10:43:50 -05:00
|
|
|
#include "pipeline.h"
|
2012-01-05 17:50:09 +00:00
|
|
|
#include "render_result.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "render_types.h"
|
2011-10-22 16:24:28 +00:00
|
|
|
|
2011-10-22 17:01:54 +00:00
|
|
|
/* Render Engine Types */
|
|
|
|
|
|
|
|
|
|
ListBase R_engines = {NULL, NULL};
|
|
|
|
|
|
|
|
|
|
void RE_engines_init(void)
|
|
|
|
|
{
|
2017-03-08 20:00:09 +01:00
|
|
|
DRW_engines_register();
|
2011-10-22 17:01:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void RE_engines_exit(void)
|
|
|
|
|
{
|
|
|
|
|
RenderEngineType *type, *next;
|
|
|
|
|
|
2017-02-07 11:20:15 +01:00
|
|
|
DRW_engines_free();
|
|
|
|
|
|
2012-06-16 16:57:16 +00:00
|
|
|
for (type = R_engines.first; type; type = next) {
|
|
|
|
|
next = type->next;
|
2011-10-22 17:01:54 +00:00
|
|
|
|
|
|
|
|
BLI_remlink(&R_engines, type);
|
|
|
|
|
|
2012-03-24 06:38:07 +00:00
|
|
|
if (!(type->flag & RE_INTERNAL)) {
|
2020-04-03 18:24:08 +02:00
|
|
|
if (type->rna_ext.free) {
|
|
|
|
|
type->rna_ext.free(type->rna_ext.data);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2011-10-22 17:01:54 +00:00
|
|
|
|
|
|
|
|
MEM_freeN(type);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-16 21:40:05 +02:00
|
|
|
void RE_engines_register(RenderEngineType *render_type)
|
2017-02-07 11:20:15 +01:00
|
|
|
{
|
2017-03-08 20:00:09 +01:00
|
|
|
if (render_type->draw_engine) {
|
|
|
|
|
DRW_engine_register(render_type->draw_engine);
|
|
|
|
|
}
|
2017-02-07 11:20:15 +01:00
|
|
|
BLI_addtail(&R_engines, render_type);
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-22 17:01:54 +00:00
|
|
|
RenderEngineType *RE_engines_find(const char *idname)
|
|
|
|
|
{
|
|
|
|
|
RenderEngineType *type;
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2012-06-16 16:57:16 +00:00
|
|
|
type = BLI_findstring(&R_engines, idname, offsetof(RenderEngineType, idname));
|
2019-04-22 09:08:06 +10:00
|
|
|
if (!type) {
|
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
|
|
|
type = BLI_findstring(&R_engines, "BLENDER_EEVEE", offsetof(RenderEngineType, idname));
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2011-10-22 17:01:54 +00:00
|
|
|
return type;
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-13 17:27:11 +11:00
|
|
|
bool RE_engine_is_external(const Render *re)
|
2011-11-26 18:33:31 +00:00
|
|
|
{
|
2018-05-30 14:32:47 +02:00
|
|
|
return (re->engine && re->engine->type && re->engine->type->render);
|
2011-11-26 18:33:31 +00:00
|
|
|
}
|
|
|
|
|
|
2018-01-29 14:56:16 +01:00
|
|
|
bool RE_engine_is_opengl(RenderEngineType *render_type)
|
|
|
|
|
{
|
|
|
|
|
/* TODO refine? Can we have ogl render engine without ogl render pipeline? */
|
|
|
|
|
return (render_type->draw_engine != NULL) && DRW_engine_render_support(render_type->draw_engine);
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-22 17:01:54 +00:00
|
|
|
/* Create, Free */
|
|
|
|
|
|
|
|
|
|
RenderEngine *RE_engine_create(RenderEngineType *type)
|
|
|
|
|
{
|
|
|
|
|
RenderEngine *engine = MEM_callocN(sizeof(RenderEngine), "RenderEngine");
|
2012-06-16 16:57:16 +00:00
|
|
|
engine->type = type;
|
2011-10-22 17:01:54 +00: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
|
|
|
BLI_mutex_init(&engine->update_render_passes_mutex);
|
|
|
|
|
|
2011-10-22 17:01:54 +00:00
|
|
|
return engine;
|
|
|
|
|
}
|
|
|
|
|
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
static void engine_depsgraph_free(RenderEngine *engine)
|
|
|
|
|
{
|
|
|
|
|
if (engine->depsgraph) {
|
2021-04-22 15:12:16 +02:00
|
|
|
/* Need GPU context since this might free GPU buffers. */
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
const bool use_gpu_context = (engine->type->flag & RE_USE_GPU_CONTEXT);
|
|
|
|
|
if (use_gpu_context) {
|
|
|
|
|
DRW_render_context_enable(engine->re);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
DEG_graph_free(engine->depsgraph);
|
|
|
|
|
engine->depsgraph = NULL;
|
|
|
|
|
|
|
|
|
|
if (use_gpu_context) {
|
|
|
|
|
DRW_render_context_disable(engine->re);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-22 17:01:54 +00:00
|
|
|
void RE_engine_free(RenderEngine *engine)
|
|
|
|
|
{
|
2011-11-02 14:33:14 +00:00
|
|
|
#ifdef WITH_PYTHON
|
2012-03-24 06:38:07 +00:00
|
|
|
if (engine->py_instance) {
|
2012-10-26 10:54:02 +00:00
|
|
|
BPY_DECREF_RNA_INVALIDATE(engine->py_instance);
|
2011-11-02 14:33:14 +00:00
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
engine_depsgraph_free(engine);
|
|
|
|
|
|
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
|
|
|
BLI_mutex_end(&engine->update_render_passes_mutex);
|
|
|
|
|
|
2011-10-22 17:01:54 +00:00
|
|
|
MEM_freeN(engine);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/* Bake Render Results */
|
|
|
|
|
|
|
|
|
|
static RenderResult *render_result_from_bake(RenderEngine *engine, int x, int y, int w, int h)
|
|
|
|
|
{
|
|
|
|
|
/* Create render result with specified size. */
|
|
|
|
|
RenderResult *rr = MEM_callocN(sizeof(RenderResult), __func__);
|
|
|
|
|
|
|
|
|
|
rr->rectx = w;
|
|
|
|
|
rr->recty = h;
|
|
|
|
|
rr->tilerect.xmin = x;
|
|
|
|
|
rr->tilerect.ymin = y;
|
|
|
|
|
rr->tilerect.xmax = x + w;
|
|
|
|
|
rr->tilerect.ymax = y + h;
|
|
|
|
|
|
|
|
|
|
/* Add single baking render layer. */
|
|
|
|
|
RenderLayer *rl = MEM_callocN(sizeof(RenderLayer), "bake render layer");
|
|
|
|
|
rl->rectx = w;
|
|
|
|
|
rl->recty = h;
|
|
|
|
|
BLI_addtail(&rr->layers, rl);
|
|
|
|
|
|
|
|
|
|
/* Add render passes. */
|
2020-08-10 22:47:12 +02:00
|
|
|
RenderPass *result_pass = render_layer_add_pass(
|
|
|
|
|
rr, rl, engine->bake.depth, RE_PASSNAME_COMBINED, "", "RGBA");
|
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 *primitive_pass = render_layer_add_pass(rr, rl, 4, "BakePrimitive", "", "RGBA");
|
|
|
|
|
RenderPass *differential_pass = render_layer_add_pass(rr, rl, 4, "BakeDifferential", "", "RGBA");
|
|
|
|
|
|
|
|
|
|
/* Fill render passes from bake pixel array, to be read by the render engine. */
|
|
|
|
|
for (int ty = 0; ty < h; ty++) {
|
|
|
|
|
size_t offset = ty * w * 4;
|
|
|
|
|
float *primitive = primitive_pass->rect + offset;
|
|
|
|
|
float *differential = differential_pass->rect + offset;
|
|
|
|
|
|
|
|
|
|
size_t bake_offset = (y + ty) * engine->bake.width + x;
|
|
|
|
|
const BakePixel *bake_pixel = engine->bake.pixels + bake_offset;
|
|
|
|
|
|
|
|
|
|
for (int tx = 0; tx < w; tx++) {
|
|
|
|
|
if (bake_pixel->object_id != engine->bake.object_id) {
|
|
|
|
|
primitive[0] = int_as_float(-1);
|
|
|
|
|
primitive[1] = int_as_float(-1);
|
|
|
|
|
}
|
|
|
|
|
else {
|
2021-02-11 18:48:21 +01:00
|
|
|
primitive[0] = int_as_float(bake_pixel->seed);
|
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
|
|
|
primitive[1] = int_as_float(bake_pixel->primitive_id);
|
|
|
|
|
primitive[2] = bake_pixel->uv[0];
|
|
|
|
|
primitive[3] = bake_pixel->uv[1];
|
|
|
|
|
|
|
|
|
|
differential[0] = bake_pixel->du_dx;
|
|
|
|
|
differential[1] = bake_pixel->du_dy;
|
|
|
|
|
differential[2] = bake_pixel->dv_dx;
|
|
|
|
|
differential[3] = bake_pixel->dv_dy;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
primitive += 4;
|
|
|
|
|
differential += 4;
|
|
|
|
|
bake_pixel++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-10 22:47:12 +02:00
|
|
|
/* Initialize tile render result from full image bake result. */
|
|
|
|
|
for (int ty = 0; ty < h; ty++) {
|
|
|
|
|
size_t offset = ty * w * engine->bake.depth;
|
|
|
|
|
size_t bake_offset = ((y + ty) * engine->bake.width + x) * engine->bake.depth;
|
|
|
|
|
size_t size = w * engine->bake.depth * sizeof(float);
|
|
|
|
|
|
|
|
|
|
memcpy(result_pass->rect + offset, engine->bake.result + bake_offset, size);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
return rr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void render_result_to_bake(RenderEngine *engine, RenderResult *rr)
|
|
|
|
|
{
|
|
|
|
|
RenderPass *rpass = RE_pass_find_by_name(rr->layers.first, RE_PASSNAME_COMBINED, "");
|
|
|
|
|
|
|
|
|
|
if (!rpass) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Copy from tile render result to full image bake result. */
|
|
|
|
|
int x = rr->tilerect.xmin;
|
|
|
|
|
int y = rr->tilerect.ymin;
|
|
|
|
|
int w = rr->tilerect.xmax - rr->tilerect.xmin;
|
|
|
|
|
int h = rr->tilerect.ymax - rr->tilerect.ymin;
|
|
|
|
|
|
|
|
|
|
for (int ty = 0; ty < h; ty++) {
|
|
|
|
|
size_t offset = ty * w * engine->bake.depth;
|
|
|
|
|
size_t bake_offset = ((y + ty) * engine->bake.width + x) * engine->bake.depth;
|
|
|
|
|
size_t size = w * engine->bake.depth * sizeof(float);
|
|
|
|
|
|
|
|
|
|
memcpy(engine->bake.result + bake_offset, rpass->rect + offset, size);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-22 17:01:54 +00:00
|
|
|
/* Render Results */
|
2011-10-22 16:24:28 +00:00
|
|
|
|
2013-01-01 16:15:13 +00:00
|
|
|
static RenderPart *get_part_from_result(Render *re, RenderResult *result)
|
|
|
|
|
{
|
2019-05-19 21:51:18 +02:00
|
|
|
rcti key = result->tilerect;
|
|
|
|
|
BLI_rcti_translate(&key, re->disprect.xmin, re->disprect.ymin);
|
2013-01-01 16:15:13 +00:00
|
|
|
|
2019-05-19 21:51:18 +02:00
|
|
|
return BLI_ghash_lookup(re->parts, &key);
|
2013-01-01 16:15:13 +00:00
|
|
|
}
|
|
|
|
|
|
2017-04-24 12:41:54 +02:00
|
|
|
RenderResult *RE_engine_begin_result(
|
|
|
|
|
RenderEngine *engine, int x, int y, int w, int h, const char *layername, const char *viewname)
|
2011-10-22 16:24:28 +00:00
|
|
|
{
|
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
|
|
|
if (engine->bake.pixels) {
|
|
|
|
|
RenderResult *result = render_result_from_bake(engine, x, y, w, h);
|
|
|
|
|
BLI_addtail(&engine->fullresult, result);
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-16 16:57:16 +00:00
|
|
|
Render *re = engine->re;
|
2011-10-22 16:24:28 +00:00
|
|
|
RenderResult *result;
|
|
|
|
|
rcti disprect;
|
|
|
|
|
|
|
|
|
|
/* ensure the coordinates are within the right limits */
|
|
|
|
|
CLAMP(x, 0, re->result->rectx);
|
|
|
|
|
CLAMP(y, 0, re->result->recty);
|
|
|
|
|
CLAMP(w, 0, re->result->rectx);
|
|
|
|
|
CLAMP(h, 0, re->result->recty);
|
|
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (x + w > re->result->rectx) {
|
2012-06-16 16:57:16 +00:00
|
|
|
w = re->result->rectx - x;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
|
if (y + h > re->result->recty) {
|
2012-06-16 16:57:16 +00:00
|
|
|
h = re->result->recty - y;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2011-10-22 16:24:28 +00:00
|
|
|
|
|
|
|
|
/* allocate a render result */
|
2012-03-24 02:51:46 +00:00
|
|
|
disprect.xmin = x;
|
2012-06-16 16:57:16 +00:00
|
|
|
disprect.xmax = x + w;
|
2012-03-24 02:51:46 +00:00
|
|
|
disprect.ymin = y;
|
2012-06-16 16:57:16 +00:00
|
|
|
disprect.ymax = y + h;
|
2011-10-22 16:24:28 +00:00
|
|
|
|
2020-12-16 16:16:50 +01:00
|
|
|
result = render_result_new(re, &disprect, RR_USE_MEM, layername, viewname);
|
2012-09-04 13:29:07 +00:00
|
|
|
|
|
|
|
|
/* todo: make this thread safe */
|
2012-07-06 14:24:41 +00:00
|
|
|
|
|
|
|
|
/* can be NULL if we CLAMP the width or height to 0 */
|
|
|
|
|
if (result) {
|
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_result_clone_passes(re, result, viewname);
|
|
|
|
|
|
2013-01-01 16:15:13 +00:00
|
|
|
RenderPart *pa;
|
|
|
|
|
|
2014-01-08 15:43:49 +11:00
|
|
|
/* Copy EXR tile settings, so pipeline knows whether this is a result
|
|
|
|
|
* for Save Buffers enabled rendering.
|
|
|
|
|
*/
|
|
|
|
|
result->do_exr_tile = re->result->do_exr_tile;
|
|
|
|
|
|
2012-07-06 14:24:41 +00:00
|
|
|
BLI_addtail(&engine->fullresult, result);
|
|
|
|
|
|
|
|
|
|
result->tilerect.xmin += re->disprect.xmin;
|
|
|
|
|
result->tilerect.xmax += re->disprect.xmin;
|
|
|
|
|
result->tilerect.ymin += re->disprect.ymin;
|
|
|
|
|
result->tilerect.ymax += re->disprect.ymin;
|
2013-01-01 16:15:13 +00:00
|
|
|
|
|
|
|
|
pa = get_part_from_result(re, result);
|
|
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (pa) {
|
2013-01-01 16:15:13 +00:00
|
|
|
pa->status = PART_STATUS_IN_PROGRESS;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2012-07-06 14:24:41 +00:00
|
|
|
}
|
2011-10-22 16:24:28 +00:00
|
|
|
|
|
|
|
|
return result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void RE_engine_update_result(RenderEngine *engine, RenderResult *result)
|
|
|
|
|
{
|
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
|
|
|
if (engine->bake.pixels) {
|
|
|
|
|
/* No interactive baking updates for now. */
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-16 16:57:16 +00:00
|
|
|
Render *re = engine->re;
|
2011-10-22 16:24:28 +00:00
|
|
|
|
2012-03-24 06:38:07 +00:00
|
|
|
if (result) {
|
2019-06-18 13:53:50 +02:00
|
|
|
render_result_merge(re->result, result);
|
2012-07-07 22:51:57 +00:00
|
|
|
result->renlay = result->layers.first; /* weak, draws first layer always */
|
2013-12-17 23:42:38 +06:00
|
|
|
re->display_update(re->duh, result, NULL);
|
2011-10-22 16:24:28 +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
|
|
|
void RE_engine_add_pass(RenderEngine *engine,
|
|
|
|
|
const char *name,
|
|
|
|
|
int channels,
|
|
|
|
|
const char *chan_id,
|
|
|
|
|
const char *layername)
|
|
|
|
|
{
|
|
|
|
|
Render *re = engine->re;
|
|
|
|
|
|
|
|
|
|
if (!re || !re->result) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-13 01:29:30 +01:00
|
|
|
RE_create_render_pass(re->result, name, channels, chan_id, layername, NULL);
|
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
|
|
|
}
|
|
|
|
|
|
2018-07-01 15:47:09 +02:00
|
|
|
void RE_engine_end_result(
|
|
|
|
|
RenderEngine *engine, RenderResult *result, bool cancel, bool highlight, bool merge_results)
|
2011-10-22 16:24:28 +00:00
|
|
|
{
|
2012-06-16 16:57:16 +00:00
|
|
|
Render *re = engine->re;
|
2011-10-22 16:24:28 +00:00
|
|
|
|
2012-09-04 18:27:47 +00:00
|
|
|
if (!result) {
|
2011-10-22 16:24:28 +00:00
|
|
|
return;
|
2012-09-04 18:27:47 +00:00
|
|
|
}
|
2011-10-22 16:24:28 +00:00
|
|
|
|
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
|
|
|
if (engine->bake.pixels) {
|
|
|
|
|
render_result_to_bake(engine, result);
|
|
|
|
|
BLI_remlink(&engine->fullresult, result);
|
|
|
|
|
render_result_free(result);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-22 16:24:28 +00:00
|
|
|
/* merge. on break, don't merge in result for preview renders, looks nicer */
|
2017-05-07 14:40:58 +02:00
|
|
|
if (!highlight) {
|
2012-09-04 13:29:07 +00:00
|
|
|
/* for exr tile render, detect tiles that are done */
|
2013-01-01 16:15:13 +00:00
|
|
|
RenderPart *pa = get_part_from_result(re, result);
|
|
|
|
|
|
2013-07-11 12:22:29 +00:00
|
|
|
if (pa) {
|
2019-03-25 11:55:36 +11:00
|
|
|
pa->status = (!cancel && merge_results) ? PART_STATUS_MERGED : PART_STATUS_RENDERED;
|
2013-07-11 12:22:29 +00:00
|
|
|
}
|
|
|
|
|
else if (re->result->do_exr_tile) {
|
2020-11-16 16:48:41 +11:00
|
|
|
/* If written result does not match any tile and we are using save
|
|
|
|
|
* buffers, we are going to get OpenEXR save errors. */
|
2013-07-11 12:22:29 +00:00
|
|
|
fprintf(stderr, "RenderEngine.end_result: dimensions do not match any OpenEXR tile.\n");
|
|
|
|
|
}
|
2013-12-17 23:42:38 +06:00
|
|
|
}
|
2011-10-22 16:24:28 +00:00
|
|
|
|
2013-12-17 23:42:38 +06:00
|
|
|
if (!cancel || merge_results) {
|
2014-01-01 16:59:38 +06:00
|
|
|
if (re->result->do_exr_tile) {
|
2017-11-02 14:29:42 +01:00
|
|
|
if (!cancel && merge_results) {
|
2015-04-06 10:40:12 -03:00
|
|
|
render_result_exr_file_merge(re->result, result, re->viewname);
|
2019-06-18 12:47:16 +02:00
|
|
|
render_result_merge(re->result, result);
|
2014-01-01 16:59:38 +06:00
|
|
|
}
|
|
|
|
|
}
|
2019-04-22 09:08:06 +10:00
|
|
|
else if (!(re->test_break(re->tbh) && (re->r.scemode & R_BUTS_PREVIEW))) {
|
2012-09-04 13:29:07 +00:00
|
|
|
render_result_merge(re->result, result);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2012-09-04 13:29:07 +00:00
|
|
|
|
|
|
|
|
/* draw */
|
|
|
|
|
if (!re->test_break(re->tbh)) {
|
|
|
|
|
result->renlay = result->layers.first; /* weak, draws first layer always */
|
2013-12-17 23:42:38 +06:00
|
|
|
re->display_update(re->duh, result, NULL);
|
2012-09-04 13:29:07 +00:00
|
|
|
}
|
2011-10-22 16:24:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* free */
|
2012-09-04 13:29:07 +00:00
|
|
|
BLI_remlink(&engine->fullresult, result);
|
|
|
|
|
render_result_free(result);
|
2011-10-22 16:24:28 +00:00
|
|
|
}
|
|
|
|
|
|
2017-02-06 17:23:02 +01:00
|
|
|
RenderResult *RE_engine_get_result(RenderEngine *engine)
|
|
|
|
|
{
|
|
|
|
|
return engine->re->result;
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-22 16:24:28 +00:00
|
|
|
/* Cancel */
|
|
|
|
|
|
2018-07-01 15:47:09 +02:00
|
|
|
bool RE_engine_test_break(RenderEngine *engine)
|
2011-10-22 16:24:28 +00:00
|
|
|
{
|
2012-06-16 16:57:16 +00:00
|
|
|
Render *re = engine->re;
|
2011-10-22 16:24:28 +00:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (re) {
|
2011-10-22 16:24:28 +00:00
|
|
|
return re->test_break(re->tbh);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2011-10-22 16:24:28 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Statistics */
|
|
|
|
|
|
|
|
|
|
void RE_engine_update_stats(RenderEngine *engine, const char *stats, const char *info)
|
|
|
|
|
{
|
2012-06-16 16:57:16 +00:00
|
|
|
Render *re = engine->re;
|
2011-10-22 16:24:28 +00:00
|
|
|
|
2011-10-22 17:01:54 +00:00
|
|
|
/* stats draw callback */
|
2012-03-24 06:38:07 +00:00
|
|
|
if (re) {
|
2012-06-16 16:57:16 +00:00
|
|
|
re->i.statstr = stats;
|
|
|
|
|
re->i.infostr = info;
|
2011-10-22 17:01:54 +00:00
|
|
|
re->stats_draw(re->sdh, &re->i);
|
2012-06-16 16:57:16 +00:00
|
|
|
re->i.infostr = NULL;
|
|
|
|
|
re->i.statstr = NULL;
|
2011-10-22 17:01:54 +00:00
|
|
|
}
|
2011-11-02 14:33:14 +00:00
|
|
|
|
|
|
|
|
/* set engine text */
|
2013-07-12 20:31:30 +00:00
|
|
|
engine->text[0] = '\0';
|
2011-11-02 14:33:14 +00:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (stats && stats[0] && info && info[0]) {
|
2013-07-12 20:31:30 +00:00
|
|
|
BLI_snprintf(engine->text, sizeof(engine->text), "%s | %s", stats, info);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
|
else if (info && info[0]) {
|
2013-07-12 20:31:30 +00:00
|
|
|
BLI_strncpy(engine->text, info, sizeof(engine->text));
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
|
else if (stats && stats[0]) {
|
2013-07-26 10:11:18 +00:00
|
|
|
BLI_strncpy(engine->text, stats, sizeof(engine->text));
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2011-10-22 17:01:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void RE_engine_update_progress(RenderEngine *engine, float progress)
|
|
|
|
|
{
|
2012-06-16 16:57:16 +00:00
|
|
|
Render *re = engine->re;
|
2011-10-22 17:01:54 +00:00
|
|
|
|
2012-03-24 06:38:07 +00:00
|
|
|
if (re) {
|
2011-10-22 17:01:54 +00:00
|
|
|
CLAMP(progress, 0.0f, 1.0f);
|
|
|
|
|
re->progress(re->prh, progress);
|
|
|
|
|
}
|
2011-10-22 16:24:28 +00:00
|
|
|
}
|
|
|
|
|
|
2012-11-05 08:04:57 +00:00
|
|
|
void RE_engine_update_memory_stats(RenderEngine *engine, float mem_used, float mem_peak)
|
|
|
|
|
{
|
|
|
|
|
Render *re = engine->re;
|
|
|
|
|
|
|
|
|
|
if (re) {
|
|
|
|
|
re->i.mem_used = mem_used;
|
|
|
|
|
re->i.mem_peak = mem_peak;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-22 16:24:28 +00:00
|
|
|
void RE_engine_report(RenderEngine *engine, int type, const char *msg)
|
|
|
|
|
{
|
2012-11-03 14:32:26 +00:00
|
|
|
Render *re = engine->re;
|
|
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (re) {
|
2012-11-03 14:32:26 +00:00
|
|
|
BKE_report(engine->re->reports, type, msg);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
|
else if (engine->reports) {
|
2012-11-03 14:32:26 +00:00
|
|
|
BKE_report(engine->reports, type, msg);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2011-10-22 16:24:28 +00:00
|
|
|
}
|
|
|
|
|
|
2014-12-05 21:56:29 +05:00
|
|
|
void RE_engine_set_error_message(RenderEngine *engine, const char *msg)
|
|
|
|
|
{
|
|
|
|
|
Render *re = engine->re;
|
|
|
|
|
if (re != NULL) {
|
|
|
|
|
RenderResult *rr = RE_AcquireResultRead(re);
|
2015-09-23 00:28:53 +02:00
|
|
|
if (rr) {
|
|
|
|
|
if (rr->error != NULL) {
|
|
|
|
|
MEM_freeN(rr->error);
|
|
|
|
|
}
|
|
|
|
|
rr->error = BLI_strdup(msg);
|
2014-12-05 21:56:29 +05:00
|
|
|
}
|
|
|
|
|
RE_ReleaseResult(re);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Multi-View: Cycles - Spherical Stereo support (VR Panoramas)
This is a new option for panorama cameras to render
stereo that can be used in virtual reality devices
The option is available under the camera panel when Multi-View is enabled (Views option in the Render Layers panel)
Known limitations:
------------------
* Parallel convergence is not supported (you need to set a convergence distance really high to simulate this effect).
* Pivot was not supposed to affect the render but it does, this has to be looked at, but for now set it to CENTER
* Derivatives in perspective camera need to be pre-computed or we shuld get rid of kcam->dx/dy (Sergey words, I don't fully grasp the implication shere)
* This works in perspective mode and in panorama mode. However, for fully benefit from this effect in perspective mode you need to render a cube map. (there is an addon for this, developed separately, perhaps we could include it in master).
* We have no support for "neck distance" at the moment. This is supposed to help with objects at short distances.
* We have no support to rotate the "Up Axis" of the stereo plane. Meaning, we hardcode 0,0,1 as UP, and create the stereo pair related to that. (although we could take the camera local UP when rendering panoramas, this wouldn't work for perspective cameras.
* We have no support for interocular distance attenuation based on the proximity of the poles (which helps to reduce the pole rotation effect/artifact).
THIS NEEDS DOCS - both in 2.78 release log and the Blender manual.
Meanwhile you can read about it here: http://code.blender.org/2015/03/1451
This patch specifically dates from March 2015, as you can see in the code.blender.org post. Many thanks to all the reviewers, testers and minor sponsors who helped me maintain spherical-stereo for 1 year.
All that said, have fun with this. This feature was what got me started with Multi-View development (at the time what I was looking for was Fulldome stereo support, but the implementation is the same). In order to make this into Blender I had to make it aiming at a less-specic user-case Thus Multi-View started. (this was December 2012, during Siggraph Asia and a chat I had with Paul Bourke during the conference). I don't have the original patch anymore, but you can find a re-based version of it from March 2013, right before I start with the Multi-View project https://developer.blender.org/P332
Reviewers: sergey, dingto
Subscribers: #cycles
Differential Revision: https://developer.blender.org/D1223
2016-03-10 09:28:29 -03:00
|
|
|
const char *RE_engine_active_view_get(RenderEngine *engine)
|
|
|
|
|
{
|
|
|
|
|
Render *re = engine->re;
|
|
|
|
|
return RE_GetActiveRenderView(re);
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
void RE_engine_active_view_set(RenderEngine *engine, const char *viewname)
|
|
|
|
|
{
|
|
|
|
|
Render *re = engine->re;
|
|
|
|
|
RE_SetActiveRenderView(re, viewname);
|
|
|
|
|
}
|
|
|
|
|
|
2018-07-01 15:47:09 +02:00
|
|
|
float RE_engine_get_camera_shift_x(RenderEngine *engine, Object *camera, bool use_spherical_stereo)
|
2015-04-06 10:40:12 -03:00
|
|
|
{
|
2019-04-22 03:05:53 +10:00
|
|
|
/* When using spherical stereo, get camera shift without multiview,
|
|
|
|
|
* leaving stereo to be handled by the engine. */
|
2020-08-14 13:42:33 +02:00
|
|
|
Render *re = engine->re;
|
|
|
|
|
if (use_spherical_stereo || re == NULL) {
|
|
|
|
|
return BKE_camera_multiview_shift_x(NULL, camera, NULL);
|
|
|
|
|
}
|
2020-08-17 14:00:42 -04:00
|
|
|
|
|
|
|
|
return BKE_camera_multiview_shift_x(&re->r, camera, re->viewname);
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
|
|
|
|
|
2017-04-24 12:41:54 +02:00
|
|
|
void RE_engine_get_camera_model_matrix(RenderEngine *engine,
|
2018-07-01 16:22:06 +02:00
|
|
|
Object *camera,
|
|
|
|
|
bool use_spherical_stereo,
|
|
|
|
|
float *r_modelmat)
|
2015-04-06 10:40:12 -03:00
|
|
|
{
|
2019-04-22 03:05:53 +10:00
|
|
|
/* When using spherical stereo, get model matrix without multiview,
|
|
|
|
|
* leaving stereo to be handled by the engine. */
|
2020-08-14 13:42:33 +02:00
|
|
|
Render *re = engine->re;
|
|
|
|
|
if (use_spherical_stereo || re == NULL) {
|
|
|
|
|
BKE_camera_multiview_model_matrix(NULL, camera, NULL, (float(*)[4])r_modelmat);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
BKE_camera_multiview_model_matrix(&re->r, camera, re->viewname, (float(*)[4])r_modelmat);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
|
|
|
|
|
2018-07-01 15:47:09 +02:00
|
|
|
bool RE_engine_get_spherical_stereo(RenderEngine *engine, Object *camera)
|
Multi-View: Cycles - Spherical Stereo support (VR Panoramas)
This is a new option for panorama cameras to render
stereo that can be used in virtual reality devices
The option is available under the camera panel when Multi-View is enabled (Views option in the Render Layers panel)
Known limitations:
------------------
* Parallel convergence is not supported (you need to set a convergence distance really high to simulate this effect).
* Pivot was not supposed to affect the render but it does, this has to be looked at, but for now set it to CENTER
* Derivatives in perspective camera need to be pre-computed or we shuld get rid of kcam->dx/dy (Sergey words, I don't fully grasp the implication shere)
* This works in perspective mode and in panorama mode. However, for fully benefit from this effect in perspective mode you need to render a cube map. (there is an addon for this, developed separately, perhaps we could include it in master).
* We have no support for "neck distance" at the moment. This is supposed to help with objects at short distances.
* We have no support to rotate the "Up Axis" of the stereo plane. Meaning, we hardcode 0,0,1 as UP, and create the stereo pair related to that. (although we could take the camera local UP when rendering panoramas, this wouldn't work for perspective cameras.
* We have no support for interocular distance attenuation based on the proximity of the poles (which helps to reduce the pole rotation effect/artifact).
THIS NEEDS DOCS - both in 2.78 release log and the Blender manual.
Meanwhile you can read about it here: http://code.blender.org/2015/03/1451
This patch specifically dates from March 2015, as you can see in the code.blender.org post. Many thanks to all the reviewers, testers and minor sponsors who helped me maintain spherical-stereo for 1 year.
All that said, have fun with this. This feature was what got me started with Multi-View development (at the time what I was looking for was Fulldome stereo support, but the implementation is the same). In order to make this into Blender I had to make it aiming at a less-specic user-case Thus Multi-View started. (this was December 2012, during Siggraph Asia and a chat I had with Paul Bourke during the conference). I don't have the original patch anymore, but you can find a re-based version of it from March 2013, right before I start with the Multi-View project https://developer.blender.org/P332
Reviewers: sergey, dingto
Subscribers: #cycles
Differential Revision: https://developer.blender.org/D1223
2016-03-10 09:28:29 -03:00
|
|
|
{
|
|
|
|
|
Render *re = engine->re;
|
|
|
|
|
return BKE_camera_multiview_spherical_stereo(re ? &re->r : NULL, camera) ? 1 : 0;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-25 11:42:28 +11:00
|
|
|
rcti *RE_engine_get_current_tiles(Render *re, int *r_total_tiles, bool *r_needs_free)
|
2013-01-01 16:15:13 +00:00
|
|
|
{
|
2015-03-20 19:56:09 +05:00
|
|
|
static rcti tiles_static[BLENDER_MAX_THREADS];
|
|
|
|
|
const int allocation_step = BLENDER_MAX_THREADS;
|
2013-01-01 16:15:13 +00:00
|
|
|
int total_tiles = 0;
|
2015-03-20 19:56:09 +05:00
|
|
|
rcti *tiles = tiles_static;
|
|
|
|
|
int allocation_size = BLENDER_MAX_THREADS;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-03-20 17:48:45 +05:00
|
|
|
BLI_rw_mutex_lock(&re->partsmutex, THREAD_LOCK_READ);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-03-20 21:09:52 +05:00
|
|
|
*r_needs_free = false;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-05-19 21:51:18 +02:00
|
|
|
if (!re->parts || (re->engine && (re->engine->flag & RE_ENGINE_HIGHLIGHT_TILES) == 0)) {
|
2015-03-24 19:20:33 +05:00
|
|
|
*r_total_tiles = 0;
|
2015-03-20 17:48:45 +05:00
|
|
|
BLI_rw_mutex_unlock(&re->partsmutex);
|
2015-03-20 19:56:09 +05:00
|
|
|
return NULL;
|
2013-01-01 16:15:13 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-05-19 21:51:18 +02:00
|
|
|
GHashIterator pa_iter;
|
|
|
|
|
GHASH_ITER (pa_iter, re->parts) {
|
|
|
|
|
RenderPart *pa = BLI_ghashIterator_getValue(&pa_iter);
|
2013-01-01 16:15:13 +00:00
|
|
|
if (pa->status == PART_STATUS_IN_PROGRESS) {
|
|
|
|
|
if (total_tiles >= allocation_size) {
|
2015-03-20 19:56:09 +05:00
|
|
|
/* Just in case we're using crazy network rendering with more
|
2018-09-12 11:00:38 +02:00
|
|
|
* workers than BLENDER_MAX_THREADS.
|
2015-03-20 19:56:09 +05:00
|
|
|
*/
|
2013-01-01 16:15:13 +00:00
|
|
|
allocation_size += allocation_step;
|
2016-01-24 01:31:36 +05:00
|
|
|
if (tiles == tiles_static) {
|
|
|
|
|
/* Can not realloc yet, tiles are pointing to a
|
|
|
|
|
* stack memory.
|
|
|
|
|
*/
|
|
|
|
|
tiles = MEM_mallocN(allocation_size * sizeof(rcti), "current engine tiles");
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
tiles = MEM_reallocN(tiles, allocation_size * sizeof(rcti));
|
|
|
|
|
}
|
2015-03-20 21:09:52 +05:00
|
|
|
*r_needs_free = true;
|
2013-01-01 16:15:13 +00:00
|
|
|
}
|
|
|
|
|
tiles[total_tiles] = pa->disprect;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-01-01 16:15:13 +00:00
|
|
|
total_tiles++;
|
|
|
|
|
}
|
|
|
|
|
}
|
2015-03-20 17:48:45 +05:00
|
|
|
BLI_rw_mutex_unlock(&re->partsmutex);
|
2015-03-24 19:20:33 +05:00
|
|
|
*r_total_tiles = total_tiles;
|
2015-03-20 19:56:09 +05:00
|
|
|
return tiles;
|
2013-01-01 16:15:13 +00:00
|
|
|
}
|
|
|
|
|
|
2013-03-14 07:38:37 +00:00
|
|
|
RenderData *RE_engine_get_render_data(Render *re)
|
|
|
|
|
{
|
|
|
|
|
return &re->r;
|
|
|
|
|
}
|
|
|
|
|
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
bool RE_engine_use_persistent_data(RenderEngine *engine)
|
|
|
|
|
{
|
2021-04-22 15:12:16 +02:00
|
|
|
/* Re-rendering is not supported with GPU contexts, since the GPU context
|
|
|
|
|
* is destroyed when the render thread exists. */
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
return (engine->re->r.mode & R_PERSISTENT_DATA) && !(engine->type->flag & RE_USE_GPU_CONTEXT);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool engine_keep_depsgraph(RenderEngine *engine)
|
|
|
|
|
{
|
|
|
|
|
/* For persistent data or GPU engines like Eevee, reuse the depsgraph between
|
|
|
|
|
* view layers and animation frames. For renderers like Cycles that create
|
|
|
|
|
* their own copy of the scene, persistent data must be explicitly enabled to
|
|
|
|
|
* keep memory usage low by default. */
|
|
|
|
|
return (engine->re->r.mode & R_PERSISTENT_DATA) || (engine->type->flag & RE_USE_GPU_CONTEXT);
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-04 13:51:39 +02:00
|
|
|
/* Depsgraph */
|
|
|
|
|
static void engine_depsgraph_init(RenderEngine *engine, ViewLayer *view_layer)
|
|
|
|
|
{
|
2018-04-06 09:17:53 +02:00
|
|
|
Main *bmain = engine->re->main;
|
|
|
|
|
Scene *scene = engine->re->scene;
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
bool reuse_depsgraph = false;
|
|
|
|
|
|
|
|
|
|
/* Reuse depsgraph from persistent data if possible. */
|
|
|
|
|
if (engine->depsgraph) {
|
|
|
|
|
if (DEG_get_bmain(engine->depsgraph) != bmain ||
|
|
|
|
|
DEG_get_input_scene(engine->depsgraph) != scene) {
|
|
|
|
|
/* If bmain or scene changes, we need a completely new graph. */
|
|
|
|
|
engine_depsgraph_free(engine);
|
|
|
|
|
}
|
|
|
|
|
else if (DEG_get_input_view_layer(engine->depsgraph) != view_layer) {
|
|
|
|
|
/* If only view layer changed, reuse depsgraph in the hope of reusing
|
|
|
|
|
* objects shared between view layers. */
|
|
|
|
|
DEG_graph_replace_owners(engine->depsgraph, bmain, scene, view_layer);
|
|
|
|
|
DEG_graph_tag_relations_update(engine->depsgraph);
|
|
|
|
|
}
|
2018-04-06 09:17:53 +02:00
|
|
|
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
reuse_depsgraph = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!engine->depsgraph) {
|
|
|
|
|
/* Ensure we only use persistent data for one scene / view layer at a time,
|
|
|
|
|
* to avoid excessive memory usage. */
|
|
|
|
|
RE_FreePersistentData(NULL);
|
|
|
|
|
|
|
|
|
|
/* Create new depsgraph if not cached with persistent data. */
|
|
|
|
|
engine->depsgraph = DEG_graph_new(bmain, scene, view_layer, DAG_EVAL_RENDER);
|
|
|
|
|
DEG_debug_name_set(engine->depsgraph, "RENDER");
|
|
|
|
|
}
|
2018-04-04 13:51:39 +02:00
|
|
|
|
2019-06-12 17:50:58 +02:00
|
|
|
if (engine->re->r.scemode & R_BUTS_PREVIEW) {
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
/* Update for preview render. */
|
2019-06-12 17:50:58 +02:00
|
|
|
Depsgraph *depsgraph = engine->depsgraph;
|
2020-08-18 15:51:32 +02:00
|
|
|
DEG_graph_relations_update(depsgraph);
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
|
|
|
|
|
/* Need GPU context since this might free GPU buffers. */
|
|
|
|
|
const bool use_gpu_context = (engine->type->flag & RE_USE_GPU_CONTEXT) && reuse_depsgraph;
|
|
|
|
|
if (use_gpu_context) {
|
|
|
|
|
DRW_render_context_enable(engine->re);
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-18 17:40:45 +02:00
|
|
|
DEG_evaluate_on_framechange(depsgraph, CFRA);
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
|
|
|
|
|
if (use_gpu_context) {
|
|
|
|
|
DRW_render_context_disable(engine->re);
|
|
|
|
|
}
|
2019-06-12 17:50:58 +02:00
|
|
|
}
|
|
|
|
|
else {
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
/* Go through update with full Python callbacks for regular render. */
|
2021-04-19 22:37:39 +02:00
|
|
|
BKE_scene_graph_update_for_newframe_ex(engine->depsgraph, false);
|
2019-06-12 17:50:58 +02:00
|
|
|
}
|
2020-11-09 18:13:03 +01:00
|
|
|
|
|
|
|
|
engine->has_grease_pencil = DRW_render_check_grease_pencil(engine->depsgraph);
|
2018-04-04 13:51:39 +02:00
|
|
|
}
|
|
|
|
|
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
static void engine_depsgraph_exit(RenderEngine *engine)
|
2018-04-04 13:51:39 +02:00
|
|
|
{
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
if (engine->depsgraph) {
|
|
|
|
|
if (engine_keep_depsgraph(engine)) {
|
|
|
|
|
/* Clear recalc flags since the engine should have handled the updates for the currently
|
|
|
|
|
* rendered framed by now. */
|
2021-04-19 19:38:05 +02:00
|
|
|
DEG_ids_clear_recalc(engine->depsgraph, false);
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* Free immediately to save memory. */
|
|
|
|
|
engine_depsgraph_free(engine);
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-04-04 13:51:39 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void RE_engine_frame_set(RenderEngine *engine, int frame, float subframe)
|
|
|
|
|
{
|
2019-03-25 11:55:36 +11:00
|
|
|
if (!engine->depsgraph) {
|
2018-04-04 13:51:39 +02:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-12 19:52:01 +02:00
|
|
|
/* Clear recalc flags before update so engine can detect what changed. */
|
2021-04-19 19:38:05 +02:00
|
|
|
DEG_ids_clear_recalc(engine->depsgraph, false);
|
2021-04-12 19:52:01 +02:00
|
|
|
|
2018-04-04 13:51:39 +02:00
|
|
|
Render *re = engine->re;
|
|
|
|
|
double cfra = (double)frame + (double)subframe;
|
|
|
|
|
|
|
|
|
|
CLAMP(cfra, MINAFRAME, MAXFRAME);
|
|
|
|
|
BKE_scene_frame_set(re->scene, cfra);
|
2021-04-19 22:37:39 +02:00
|
|
|
BKE_scene_graph_update_for_newframe_ex(engine->depsgraph, false);
|
2018-04-04 13:51:39 +02:00
|
|
|
|
2018-06-04 16:51:27 +02:00
|
|
|
BKE_scene_camera_switch_update(re->scene);
|
2018-04-04 13:51:39 +02:00
|
|
|
}
|
|
|
|
|
|
Bake API - bpy.ops.object.bake()
New operator that can calls a bake function to the current render engine when available. This commit provides no feature for the users, but allows external engines to be accessed by the operator and be integrated with the baking api.
The API itself is simple. Blender sends a populated array of BakePixels to the renderer, and gets back an array of floats with the result.
The Blender Internal (and multires) system is still running independent, but we eventually will pipe it through the API as well. Cycles baking will come next as a separated commit
Python Operator:
----------------
The operator can be called with some arguments, or a user interface can be created for it. In that case the arguments can be ommited and the interface can expose the settings from bpy.context.scene.render.bake
bpy.ops.object.bake(type='COMBINED', filepath="", width=512, height=512, margin=16, use_selected_to_active=False, cage_extrusion=0, cage="", normal_space='TANGENT', normal_r='POS_X', normal_g='POS_Y', normal_b='POS_Z', save_mode='INTERNAL', use_clear=False, use_split_materials=False, use_automatic_name=False)
Note: external save mode is currently disabled.
Supported Features:
------------------
* Margin - Baked result is extended this many pixels beyond the border of each UV "island," to soften seams in the texture.
* Selected to Active - bake shading on the surface of selected object to the active object. The rays are cast from the lowpoly object inwards towards the highpoly object. If the highpoly object is not entirely involved by the lowpoly object, you can tweak the rays start point with Cage Extrusion. For even more control of the cage you can use a Cage object.
* Cage Extrusion - distance to use for the inward ray cast when using selected to active
* Custom Cage - object to use as cage (instead of the lowpoly object).
* Normal swizzle - change the axis that gets mapped to RGB
* Normal space - save as tangent or object normal spaces
Supported Passes:
-----------------
Any pass that is supported by Blender renderlayer system. Though it's up to the external engine to provide a valid enum with its supported passes. Normal passes get a special treatment since we post-process them to converted and "swizzled"
Development Notes for External Engines:
---------------------------------------
(read them in bake_api.c)
* For a complete implementation example look at the Cycles Bake commit (next).
Review: D421
Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge
Normal map pipeline "consulting" by Andy Davies (metalliandy)
Original design by Brecht van Lommel.
The entire commit history can be found on the branch: bake-cycles
2014-01-02 19:05:07 -02:00
|
|
|
/* Bake */
|
2018-02-20 12:55:02 -03:00
|
|
|
void RE_bake_engine_set_engine_parameters(Render *re, Main *bmain, Scene *scene)
|
Bake API - bpy.ops.object.bake()
New operator that can calls a bake function to the current render engine when available. This commit provides no feature for the users, but allows external engines to be accessed by the operator and be integrated with the baking api.
The API itself is simple. Blender sends a populated array of BakePixels to the renderer, and gets back an array of floats with the result.
The Blender Internal (and multires) system is still running independent, but we eventually will pipe it through the API as well. Cycles baking will come next as a separated commit
Python Operator:
----------------
The operator can be called with some arguments, or a user interface can be created for it. In that case the arguments can be ommited and the interface can expose the settings from bpy.context.scene.render.bake
bpy.ops.object.bake(type='COMBINED', filepath="", width=512, height=512, margin=16, use_selected_to_active=False, cage_extrusion=0, cage="", normal_space='TANGENT', normal_r='POS_X', normal_g='POS_Y', normal_b='POS_Z', save_mode='INTERNAL', use_clear=False, use_split_materials=False, use_automatic_name=False)
Note: external save mode is currently disabled.
Supported Features:
------------------
* Margin - Baked result is extended this many pixels beyond the border of each UV "island," to soften seams in the texture.
* Selected to Active - bake shading on the surface of selected object to the active object. The rays are cast from the lowpoly object inwards towards the highpoly object. If the highpoly object is not entirely involved by the lowpoly object, you can tweak the rays start point with Cage Extrusion. For even more control of the cage you can use a Cage object.
* Cage Extrusion - distance to use for the inward ray cast when using selected to active
* Custom Cage - object to use as cage (instead of the lowpoly object).
* Normal swizzle - change the axis that gets mapped to RGB
* Normal space - save as tangent or object normal spaces
Supported Passes:
-----------------
Any pass that is supported by Blender renderlayer system. Though it's up to the external engine to provide a valid enum with its supported passes. Normal passes get a special treatment since we post-process them to converted and "swizzled"
Development Notes for External Engines:
---------------------------------------
(read them in bake_api.c)
* For a complete implementation example look at the Cycles Bake commit (next).
Review: D421
Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge
Normal map pipeline "consulting" by Andy Davies (metalliandy)
Original design by Brecht van Lommel.
The entire commit history can be found on the branch: bake-cycles
2014-01-02 19:05:07 -02:00
|
|
|
{
|
|
|
|
|
re->scene = scene;
|
|
|
|
|
re->main = bmain;
|
2016-02-17 22:18:45 +01:00
|
|
|
render_copy_renderdata(&re->r, &scene->r);
|
Bake API - bpy.ops.object.bake()
New operator that can calls a bake function to the current render engine when available. This commit provides no feature for the users, but allows external engines to be accessed by the operator and be integrated with the baking api.
The API itself is simple. Blender sends a populated array of BakePixels to the renderer, and gets back an array of floats with the result.
The Blender Internal (and multires) system is still running independent, but we eventually will pipe it through the API as well. Cycles baking will come next as a separated commit
Python Operator:
----------------
The operator can be called with some arguments, or a user interface can be created for it. In that case the arguments can be ommited and the interface can expose the settings from bpy.context.scene.render.bake
bpy.ops.object.bake(type='COMBINED', filepath="", width=512, height=512, margin=16, use_selected_to_active=False, cage_extrusion=0, cage="", normal_space='TANGENT', normal_r='POS_X', normal_g='POS_Y', normal_b='POS_Z', save_mode='INTERNAL', use_clear=False, use_split_materials=False, use_automatic_name=False)
Note: external save mode is currently disabled.
Supported Features:
------------------
* Margin - Baked result is extended this many pixels beyond the border of each UV "island," to soften seams in the texture.
* Selected to Active - bake shading on the surface of selected object to the active object. The rays are cast from the lowpoly object inwards towards the highpoly object. If the highpoly object is not entirely involved by the lowpoly object, you can tweak the rays start point with Cage Extrusion. For even more control of the cage you can use a Cage object.
* Cage Extrusion - distance to use for the inward ray cast when using selected to active
* Custom Cage - object to use as cage (instead of the lowpoly object).
* Normal swizzle - change the axis that gets mapped to RGB
* Normal space - save as tangent or object normal spaces
Supported Passes:
-----------------
Any pass that is supported by Blender renderlayer system. Though it's up to the external engine to provide a valid enum with its supported passes. Normal passes get a special treatment since we post-process them to converted and "swizzled"
Development Notes for External Engines:
---------------------------------------
(read them in bake_api.c)
* For a complete implementation example look at the Cycles Bake commit (next).
Review: D421
Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge
Normal map pipeline "consulting" by Andy Davies (metalliandy)
Original design by Brecht van Lommel.
The entire commit history can be found on the branch: bake-cycles
2014-01-02 19:05:07 -02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool RE_bake_has_engine(Render *re)
|
|
|
|
|
{
|
2018-04-17 13:35:05 +02:00
|
|
|
RenderEngineType *type = RE_engines_find(re->r.engine);
|
2014-05-23 14:54:12 +10:00
|
|
|
return (type->bake != NULL);
|
Bake API - bpy.ops.object.bake()
New operator that can calls a bake function to the current render engine when available. This commit provides no feature for the users, but allows external engines to be accessed by the operator and be integrated with the baking api.
The API itself is simple. Blender sends a populated array of BakePixels to the renderer, and gets back an array of floats with the result.
The Blender Internal (and multires) system is still running independent, but we eventually will pipe it through the API as well. Cycles baking will come next as a separated commit
Python Operator:
----------------
The operator can be called with some arguments, or a user interface can be created for it. In that case the arguments can be ommited and the interface can expose the settings from bpy.context.scene.render.bake
bpy.ops.object.bake(type='COMBINED', filepath="", width=512, height=512, margin=16, use_selected_to_active=False, cage_extrusion=0, cage="", normal_space='TANGENT', normal_r='POS_X', normal_g='POS_Y', normal_b='POS_Z', save_mode='INTERNAL', use_clear=False, use_split_materials=False, use_automatic_name=False)
Note: external save mode is currently disabled.
Supported Features:
------------------
* Margin - Baked result is extended this many pixels beyond the border of each UV "island," to soften seams in the texture.
* Selected to Active - bake shading on the surface of selected object to the active object. The rays are cast from the lowpoly object inwards towards the highpoly object. If the highpoly object is not entirely involved by the lowpoly object, you can tweak the rays start point with Cage Extrusion. For even more control of the cage you can use a Cage object.
* Cage Extrusion - distance to use for the inward ray cast when using selected to active
* Custom Cage - object to use as cage (instead of the lowpoly object).
* Normal swizzle - change the axis that gets mapped to RGB
* Normal space - save as tangent or object normal spaces
Supported Passes:
-----------------
Any pass that is supported by Blender renderlayer system. Though it's up to the external engine to provide a valid enum with its supported passes. Normal passes get a special treatment since we post-process them to converted and "swizzled"
Development Notes for External Engines:
---------------------------------------
(read them in bake_api.c)
* For a complete implementation example look at the Cycles Bake commit (next).
Review: D421
Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge
Normal map pipeline "consulting" by Andy Davies (metalliandy)
Original design by Brecht van Lommel.
The entire commit history can be found on the branch: bake-cycles
2014-01-02 19:05:07 -02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool RE_bake_engine(Render *re,
|
2018-05-23 12:13:21 +02:00
|
|
|
Depsgraph *depsgraph,
|
|
|
|
|
Object *object,
|
2015-04-17 12:25:37 -03:00
|
|
|
const int object_id,
|
|
|
|
|
const BakePixel pixel_array[],
|
2020-12-23 16:39:36 +01:00
|
|
|
const BakeTargets *targets,
|
2017-10-17 13:43:10 +11:00
|
|
|
const eScenePassType pass_type,
|
|
|
|
|
const int pass_filter,
|
2016-01-15 13:00:56 -02:00
|
|
|
float result[])
|
Bake API - bpy.ops.object.bake()
New operator that can calls a bake function to the current render engine when available. This commit provides no feature for the users, but allows external engines to be accessed by the operator and be integrated with the baking api.
The API itself is simple. Blender sends a populated array of BakePixels to the renderer, and gets back an array of floats with the result.
The Blender Internal (and multires) system is still running independent, but we eventually will pipe it through the API as well. Cycles baking will come next as a separated commit
Python Operator:
----------------
The operator can be called with some arguments, or a user interface can be created for it. In that case the arguments can be ommited and the interface can expose the settings from bpy.context.scene.render.bake
bpy.ops.object.bake(type='COMBINED', filepath="", width=512, height=512, margin=16, use_selected_to_active=False, cage_extrusion=0, cage="", normal_space='TANGENT', normal_r='POS_X', normal_g='POS_Y', normal_b='POS_Z', save_mode='INTERNAL', use_clear=False, use_split_materials=False, use_automatic_name=False)
Note: external save mode is currently disabled.
Supported Features:
------------------
* Margin - Baked result is extended this many pixels beyond the border of each UV "island," to soften seams in the texture.
* Selected to Active - bake shading on the surface of selected object to the active object. The rays are cast from the lowpoly object inwards towards the highpoly object. If the highpoly object is not entirely involved by the lowpoly object, you can tweak the rays start point with Cage Extrusion. For even more control of the cage you can use a Cage object.
* Cage Extrusion - distance to use for the inward ray cast when using selected to active
* Custom Cage - object to use as cage (instead of the lowpoly object).
* Normal swizzle - change the axis that gets mapped to RGB
* Normal space - save as tangent or object normal spaces
Supported Passes:
-----------------
Any pass that is supported by Blender renderlayer system. Though it's up to the external engine to provide a valid enum with its supported passes. Normal passes get a special treatment since we post-process them to converted and "swizzled"
Development Notes for External Engines:
---------------------------------------
(read them in bake_api.c)
* For a complete implementation example look at the Cycles Bake commit (next).
Review: D421
Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge
Normal map pipeline "consulting" by Andy Davies (metalliandy)
Original design by Brecht van Lommel.
The entire commit history can be found on the branch: bake-cycles
2014-01-02 19:05:07 -02:00
|
|
|
{
|
2018-04-17 13:35:05 +02:00
|
|
|
RenderEngineType *type = RE_engines_find(re->r.engine);
|
Bake API - bpy.ops.object.bake()
New operator that can calls a bake function to the current render engine when available. This commit provides no feature for the users, but allows external engines to be accessed by the operator and be integrated with the baking api.
The API itself is simple. Blender sends a populated array of BakePixels to the renderer, and gets back an array of floats with the result.
The Blender Internal (and multires) system is still running independent, but we eventually will pipe it through the API as well. Cycles baking will come next as a separated commit
Python Operator:
----------------
The operator can be called with some arguments, or a user interface can be created for it. In that case the arguments can be ommited and the interface can expose the settings from bpy.context.scene.render.bake
bpy.ops.object.bake(type='COMBINED', filepath="", width=512, height=512, margin=16, use_selected_to_active=False, cage_extrusion=0, cage="", normal_space='TANGENT', normal_r='POS_X', normal_g='POS_Y', normal_b='POS_Z', save_mode='INTERNAL', use_clear=False, use_split_materials=False, use_automatic_name=False)
Note: external save mode is currently disabled.
Supported Features:
------------------
* Margin - Baked result is extended this many pixels beyond the border of each UV "island," to soften seams in the texture.
* Selected to Active - bake shading on the surface of selected object to the active object. The rays are cast from the lowpoly object inwards towards the highpoly object. If the highpoly object is not entirely involved by the lowpoly object, you can tweak the rays start point with Cage Extrusion. For even more control of the cage you can use a Cage object.
* Cage Extrusion - distance to use for the inward ray cast when using selected to active
* Custom Cage - object to use as cage (instead of the lowpoly object).
* Normal swizzle - change the axis that gets mapped to RGB
* Normal space - save as tangent or object normal spaces
Supported Passes:
-----------------
Any pass that is supported by Blender renderlayer system. Though it's up to the external engine to provide a valid enum with its supported passes. Normal passes get a special treatment since we post-process them to converted and "swizzled"
Development Notes for External Engines:
---------------------------------------
(read them in bake_api.c)
* For a complete implementation example look at the Cycles Bake commit (next).
Review: D421
Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge
Normal map pipeline "consulting" by Andy Davies (metalliandy)
Original design by Brecht van Lommel.
The entire commit history can be found on the branch: bake-cycles
2014-01-02 19:05:07 -02:00
|
|
|
RenderEngine *engine;
|
|
|
|
|
|
|
|
|
|
/* set render info */
|
|
|
|
|
re->i.cfra = re->scene->r.cfra;
|
|
|
|
|
BLI_strncpy(re->i.scene_name, re->scene->id.name + 2, sizeof(re->i.scene_name) - 2);
|
|
|
|
|
|
|
|
|
|
/* render */
|
|
|
|
|
engine = re->engine;
|
|
|
|
|
|
|
|
|
|
if (!engine) {
|
|
|
|
|
engine = RE_engine_create(type);
|
|
|
|
|
re->engine = engine;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
engine->flag |= RE_ENGINE_RENDERING;
|
|
|
|
|
|
|
|
|
|
/* TODO: actually link to a parent which shouldn't happen */
|
|
|
|
|
engine->re = re;
|
|
|
|
|
|
|
|
|
|
engine->resolution_x = re->winx;
|
|
|
|
|
engine->resolution_y = re->winy;
|
|
|
|
|
|
2020-05-14 02:13:40 +02:00
|
|
|
BLI_rw_mutex_lock(&re->partsmutex, THREAD_LOCK_WRITE);
|
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
|
|
|
RE_parts_init(re);
|
2014-07-31 20:04:57 -03:00
|
|
|
engine->tile_x = re->r.tilex;
|
|
|
|
|
engine->tile_y = re->r.tiley;
|
2020-05-14 02:13:40 +02:00
|
|
|
BLI_rw_mutex_unlock(&re->partsmutex);
|
Bake API - bpy.ops.object.bake()
New operator that can calls a bake function to the current render engine when available. This commit provides no feature for the users, but allows external engines to be accessed by the operator and be integrated with the baking api.
The API itself is simple. Blender sends a populated array of BakePixels to the renderer, and gets back an array of floats with the result.
The Blender Internal (and multires) system is still running independent, but we eventually will pipe it through the API as well. Cycles baking will come next as a separated commit
Python Operator:
----------------
The operator can be called with some arguments, or a user interface can be created for it. In that case the arguments can be ommited and the interface can expose the settings from bpy.context.scene.render.bake
bpy.ops.object.bake(type='COMBINED', filepath="", width=512, height=512, margin=16, use_selected_to_active=False, cage_extrusion=0, cage="", normal_space='TANGENT', normal_r='POS_X', normal_g='POS_Y', normal_b='POS_Z', save_mode='INTERNAL', use_clear=False, use_split_materials=False, use_automatic_name=False)
Note: external save mode is currently disabled.
Supported Features:
------------------
* Margin - Baked result is extended this many pixels beyond the border of each UV "island," to soften seams in the texture.
* Selected to Active - bake shading on the surface of selected object to the active object. The rays are cast from the lowpoly object inwards towards the highpoly object. If the highpoly object is not entirely involved by the lowpoly object, you can tweak the rays start point with Cage Extrusion. For even more control of the cage you can use a Cage object.
* Cage Extrusion - distance to use for the inward ray cast when using selected to active
* Custom Cage - object to use as cage (instead of the lowpoly object).
* Normal swizzle - change the axis that gets mapped to RGB
* Normal space - save as tangent or object normal spaces
Supported Passes:
-----------------
Any pass that is supported by Blender renderlayer system. Though it's up to the external engine to provide a valid enum with its supported passes. Normal passes get a special treatment since we post-process them to converted and "swizzled"
Development Notes for External Engines:
---------------------------------------
(read them in bake_api.c)
* For a complete implementation example look at the Cycles Bake commit (next).
Review: D421
Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge
Normal map pipeline "consulting" by Andy Davies (metalliandy)
Original design by Brecht van Lommel.
The entire commit history can be found on the branch: bake-cycles
2014-01-02 19:05:07 -02:00
|
|
|
|
2017-04-24 12:41:54 +02:00
|
|
|
if (type->bake) {
|
2018-05-23 12:13:21 +02:00
|
|
|
engine->depsgraph = depsgraph;
|
|
|
|
|
|
|
|
|
|
/* update is only called so we create the engine.session */
|
2019-04-22 09:08:06 +10:00
|
|
|
if (type->update) {
|
2018-05-23 12:13:21 +02:00
|
|
|
type->update(engine, re->main, engine->depsgraph);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2018-02-26 16:46:48 +01:00
|
|
|
|
2020-12-23 16:39:36 +01:00
|
|
|
for (int i = 0; i < targets->num_images; i++) {
|
|
|
|
|
const BakeImage *image = targets->images + i;
|
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
|
|
|
|
|
|
|
|
engine->bake.pixels = pixel_array + image->offset;
|
2020-12-23 16:39:36 +01:00
|
|
|
engine->bake.result = result + image->offset * targets->num_channels;
|
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
|
|
|
engine->bake.width = image->width;
|
|
|
|
|
engine->bake.height = image->height;
|
2020-12-23 16:39:36 +01:00
|
|
|
engine->bake.depth = targets->num_channels;
|
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
|
|
|
engine->bake.object_id = object_id;
|
|
|
|
|
|
|
|
|
|
type->bake(
|
|
|
|
|
engine, engine->depsgraph, object, pass_type, pass_filter, image->width, image->height);
|
|
|
|
|
|
|
|
|
|
memset(&engine->bake, 0, sizeof(engine->bake));
|
|
|
|
|
}
|
2018-02-26 16:46:48 +01:00
|
|
|
|
2018-05-23 12:13:21 +02:00
|
|
|
engine->depsgraph = NULL;
|
2017-04-24 12:41:54 +02:00
|
|
|
}
|
Bake API - bpy.ops.object.bake()
New operator that can calls a bake function to the current render engine when available. This commit provides no feature for the users, but allows external engines to be accessed by the operator and be integrated with the baking api.
The API itself is simple. Blender sends a populated array of BakePixels to the renderer, and gets back an array of floats with the result.
The Blender Internal (and multires) system is still running independent, but we eventually will pipe it through the API as well. Cycles baking will come next as a separated commit
Python Operator:
----------------
The operator can be called with some arguments, or a user interface can be created for it. In that case the arguments can be ommited and the interface can expose the settings from bpy.context.scene.render.bake
bpy.ops.object.bake(type='COMBINED', filepath="", width=512, height=512, margin=16, use_selected_to_active=False, cage_extrusion=0, cage="", normal_space='TANGENT', normal_r='POS_X', normal_g='POS_Y', normal_b='POS_Z', save_mode='INTERNAL', use_clear=False, use_split_materials=False, use_automatic_name=False)
Note: external save mode is currently disabled.
Supported Features:
------------------
* Margin - Baked result is extended this many pixels beyond the border of each UV "island," to soften seams in the texture.
* Selected to Active - bake shading on the surface of selected object to the active object. The rays are cast from the lowpoly object inwards towards the highpoly object. If the highpoly object is not entirely involved by the lowpoly object, you can tweak the rays start point with Cage Extrusion. For even more control of the cage you can use a Cage object.
* Cage Extrusion - distance to use for the inward ray cast when using selected to active
* Custom Cage - object to use as cage (instead of the lowpoly object).
* Normal swizzle - change the axis that gets mapped to RGB
* Normal space - save as tangent or object normal spaces
Supported Passes:
-----------------
Any pass that is supported by Blender renderlayer system. Though it's up to the external engine to provide a valid enum with its supported passes. Normal passes get a special treatment since we post-process them to converted and "swizzled"
Development Notes for External Engines:
---------------------------------------
(read them in bake_api.c)
* For a complete implementation example look at the Cycles Bake commit (next).
Review: D421
Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge
Normal map pipeline "consulting" by Andy Davies (metalliandy)
Original design by Brecht van Lommel.
The entire commit history can be found on the branch: bake-cycles
2014-01-02 19:05:07 -02:00
|
|
|
|
|
|
|
|
engine->tile_x = 0;
|
|
|
|
|
engine->tile_y = 0;
|
|
|
|
|
engine->flag &= ~RE_ENGINE_RENDERING;
|
|
|
|
|
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
/* Free depsgraph outside of parts mutex lock, since this locks OpenGL context
|
|
|
|
|
* while the the UI drawing might also lock the OpenGL context and parts mutex. */
|
|
|
|
|
engine_depsgraph_free(engine);
|
2015-03-20 17:48:45 +05:00
|
|
|
BLI_rw_mutex_lock(&re->partsmutex, THREAD_LOCK_WRITE);
|
|
|
|
|
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
RE_engine_free(engine);
|
|
|
|
|
re->engine = NULL;
|
Bake API - bpy.ops.object.bake()
New operator that can calls a bake function to the current render engine when available. This commit provides no feature for the users, but allows external engines to be accessed by the operator and be integrated with the baking api.
The API itself is simple. Blender sends a populated array of BakePixels to the renderer, and gets back an array of floats with the result.
The Blender Internal (and multires) system is still running independent, but we eventually will pipe it through the API as well. Cycles baking will come next as a separated commit
Python Operator:
----------------
The operator can be called with some arguments, or a user interface can be created for it. In that case the arguments can be ommited and the interface can expose the settings from bpy.context.scene.render.bake
bpy.ops.object.bake(type='COMBINED', filepath="", width=512, height=512, margin=16, use_selected_to_active=False, cage_extrusion=0, cage="", normal_space='TANGENT', normal_r='POS_X', normal_g='POS_Y', normal_b='POS_Z', save_mode='INTERNAL', use_clear=False, use_split_materials=False, use_automatic_name=False)
Note: external save mode is currently disabled.
Supported Features:
------------------
* Margin - Baked result is extended this many pixels beyond the border of each UV "island," to soften seams in the texture.
* Selected to Active - bake shading on the surface of selected object to the active object. The rays are cast from the lowpoly object inwards towards the highpoly object. If the highpoly object is not entirely involved by the lowpoly object, you can tweak the rays start point with Cage Extrusion. For even more control of the cage you can use a Cage object.
* Cage Extrusion - distance to use for the inward ray cast when using selected to active
* Custom Cage - object to use as cage (instead of the lowpoly object).
* Normal swizzle - change the axis that gets mapped to RGB
* Normal space - save as tangent or object normal spaces
Supported Passes:
-----------------
Any pass that is supported by Blender renderlayer system. Though it's up to the external engine to provide a valid enum with its supported passes. Normal passes get a special treatment since we post-process them to converted and "swizzled"
Development Notes for External Engines:
---------------------------------------
(read them in bake_api.c)
* For a complete implementation example look at the Cycles Bake commit (next).
Review: D421
Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge
Normal map pipeline "consulting" by Andy Davies (metalliandy)
Original design by Brecht van Lommel.
The entire commit history can be found on the branch: bake-cycles
2014-01-02 19:05:07 -02:00
|
|
|
|
|
|
|
|
RE_parts_free(re);
|
2015-03-20 17:48:45 +05:00
|
|
|
BLI_rw_mutex_unlock(&re->partsmutex);
|
Bake API - bpy.ops.object.bake()
New operator that can calls a bake function to the current render engine when available. This commit provides no feature for the users, but allows external engines to be accessed by the operator and be integrated with the baking api.
The API itself is simple. Blender sends a populated array of BakePixels to the renderer, and gets back an array of floats with the result.
The Blender Internal (and multires) system is still running independent, but we eventually will pipe it through the API as well. Cycles baking will come next as a separated commit
Python Operator:
----------------
The operator can be called with some arguments, or a user interface can be created for it. In that case the arguments can be ommited and the interface can expose the settings from bpy.context.scene.render.bake
bpy.ops.object.bake(type='COMBINED', filepath="", width=512, height=512, margin=16, use_selected_to_active=False, cage_extrusion=0, cage="", normal_space='TANGENT', normal_r='POS_X', normal_g='POS_Y', normal_b='POS_Z', save_mode='INTERNAL', use_clear=False, use_split_materials=False, use_automatic_name=False)
Note: external save mode is currently disabled.
Supported Features:
------------------
* Margin - Baked result is extended this many pixels beyond the border of each UV "island," to soften seams in the texture.
* Selected to Active - bake shading on the surface of selected object to the active object. The rays are cast from the lowpoly object inwards towards the highpoly object. If the highpoly object is not entirely involved by the lowpoly object, you can tweak the rays start point with Cage Extrusion. For even more control of the cage you can use a Cage object.
* Cage Extrusion - distance to use for the inward ray cast when using selected to active
* Custom Cage - object to use as cage (instead of the lowpoly object).
* Normal swizzle - change the axis that gets mapped to RGB
* Normal space - save as tangent or object normal spaces
Supported Passes:
-----------------
Any pass that is supported by Blender renderlayer system. Though it's up to the external engine to provide a valid enum with its supported passes. Normal passes get a special treatment since we post-process them to converted and "swizzled"
Development Notes for External Engines:
---------------------------------------
(read them in bake_api.c)
* For a complete implementation example look at the Cycles Bake commit (next).
Review: D421
Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge
Normal map pipeline "consulting" by Andy Davies (metalliandy)
Original design by Brecht van Lommel.
The entire commit history can be found on the branch: bake-cycles
2014-01-02 19:05:07 -02:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (BKE_reports_contain(re->reports, RPT_ERROR)) {
|
Bake API - bpy.ops.object.bake()
New operator that can calls a bake function to the current render engine when available. This commit provides no feature for the users, but allows external engines to be accessed by the operator and be integrated with the baking api.
The API itself is simple. Blender sends a populated array of BakePixels to the renderer, and gets back an array of floats with the result.
The Blender Internal (and multires) system is still running independent, but we eventually will pipe it through the API as well. Cycles baking will come next as a separated commit
Python Operator:
----------------
The operator can be called with some arguments, or a user interface can be created for it. In that case the arguments can be ommited and the interface can expose the settings from bpy.context.scene.render.bake
bpy.ops.object.bake(type='COMBINED', filepath="", width=512, height=512, margin=16, use_selected_to_active=False, cage_extrusion=0, cage="", normal_space='TANGENT', normal_r='POS_X', normal_g='POS_Y', normal_b='POS_Z', save_mode='INTERNAL', use_clear=False, use_split_materials=False, use_automatic_name=False)
Note: external save mode is currently disabled.
Supported Features:
------------------
* Margin - Baked result is extended this many pixels beyond the border of each UV "island," to soften seams in the texture.
* Selected to Active - bake shading on the surface of selected object to the active object. The rays are cast from the lowpoly object inwards towards the highpoly object. If the highpoly object is not entirely involved by the lowpoly object, you can tweak the rays start point with Cage Extrusion. For even more control of the cage you can use a Cage object.
* Cage Extrusion - distance to use for the inward ray cast when using selected to active
* Custom Cage - object to use as cage (instead of the lowpoly object).
* Normal swizzle - change the axis that gets mapped to RGB
* Normal space - save as tangent or object normal spaces
Supported Passes:
-----------------
Any pass that is supported by Blender renderlayer system. Though it's up to the external engine to provide a valid enum with its supported passes. Normal passes get a special treatment since we post-process them to converted and "swizzled"
Development Notes for External Engines:
---------------------------------------
(read them in bake_api.c)
* For a complete implementation example look at the Cycles Bake commit (next).
Review: D421
Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge
Normal map pipeline "consulting" by Andy Davies (metalliandy)
Original design by Brecht van Lommel.
The entire commit history can be found on the branch: bake-cycles
2014-01-02 19:05:07 -02:00
|
|
|
G.is_break = true;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
Bake API - bpy.ops.object.bake()
New operator that can calls a bake function to the current render engine when available. This commit provides no feature for the users, but allows external engines to be accessed by the operator and be integrated with the baking api.
The API itself is simple. Blender sends a populated array of BakePixels to the renderer, and gets back an array of floats with the result.
The Blender Internal (and multires) system is still running independent, but we eventually will pipe it through the API as well. Cycles baking will come next as a separated commit
Python Operator:
----------------
The operator can be called with some arguments, or a user interface can be created for it. In that case the arguments can be ommited and the interface can expose the settings from bpy.context.scene.render.bake
bpy.ops.object.bake(type='COMBINED', filepath="", width=512, height=512, margin=16, use_selected_to_active=False, cage_extrusion=0, cage="", normal_space='TANGENT', normal_r='POS_X', normal_g='POS_Y', normal_b='POS_Z', save_mode='INTERNAL', use_clear=False, use_split_materials=False, use_automatic_name=False)
Note: external save mode is currently disabled.
Supported Features:
------------------
* Margin - Baked result is extended this many pixels beyond the border of each UV "island," to soften seams in the texture.
* Selected to Active - bake shading on the surface of selected object to the active object. The rays are cast from the lowpoly object inwards towards the highpoly object. If the highpoly object is not entirely involved by the lowpoly object, you can tweak the rays start point with Cage Extrusion. For even more control of the cage you can use a Cage object.
* Cage Extrusion - distance to use for the inward ray cast when using selected to active
* Custom Cage - object to use as cage (instead of the lowpoly object).
* Normal swizzle - change the axis that gets mapped to RGB
* Normal space - save as tangent or object normal spaces
Supported Passes:
-----------------
Any pass that is supported by Blender renderlayer system. Though it's up to the external engine to provide a valid enum with its supported passes. Normal passes get a special treatment since we post-process them to converted and "swizzled"
Development Notes for External Engines:
---------------------------------------
(read them in bake_api.c)
* For a complete implementation example look at the Cycles Bake commit (next).
Review: D421
Reviewed by: Campbell Barton, Brecht van Lommel, Sergey Sharybin, Thomas Dinge
Normal map pipeline "consulting" by Andy Davies (metalliandy)
Original design by Brecht van Lommel.
The entire commit history can be found on the branch: bake-cycles
2014-01-02 19:05:07 -02:00
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-22 16:24:28 +00:00
|
|
|
/* Render */
|
|
|
|
|
|
2020-11-09 18:13:03 +01:00
|
|
|
static void engine_render_view_layer(Render *re,
|
|
|
|
|
RenderEngine *engine,
|
|
|
|
|
ViewLayer *view_layer_iter,
|
|
|
|
|
const bool use_engine,
|
|
|
|
|
const bool use_grease_pencil)
|
|
|
|
|
{
|
|
|
|
|
/* Lock UI so scene can't be edited while we read from it in this render thread. */
|
|
|
|
|
if (re->draw_lock) {
|
2021-02-26 16:50:36 +11:00
|
|
|
re->draw_lock(re->dlh, true);
|
2020-11-09 18:13:03 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Create depsgraph with scene evaluated at render resolution. */
|
|
|
|
|
ViewLayer *view_layer = BLI_findstring(
|
|
|
|
|
&re->scene->view_layers, view_layer_iter->name, offsetof(ViewLayer, name));
|
|
|
|
|
engine_depsgraph_init(engine, view_layer);
|
|
|
|
|
|
|
|
|
|
/* Sync data to engine, within draw lock so scene data can be accessed safely. */
|
|
|
|
|
if (use_engine) {
|
|
|
|
|
if (engine->type->update) {
|
|
|
|
|
engine->type->update(engine, re->main, engine->depsgraph);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (re->draw_lock) {
|
2021-02-26 16:50:36 +11:00
|
|
|
re->draw_lock(re->dlh, false);
|
2020-11-09 18:13:03 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Perform render with engine. */
|
|
|
|
|
if (use_engine) {
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
const bool use_gpu_context = (engine->type->flag & RE_USE_GPU_CONTEXT);
|
|
|
|
|
if (use_gpu_context) {
|
2020-11-09 18:13:03 +01:00
|
|
|
DRW_render_context_enable(engine->re);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
engine->type->render(engine, engine->depsgraph);
|
|
|
|
|
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
if (use_gpu_context) {
|
2020-11-09 18:13:03 +01:00
|
|
|
DRW_render_context_disable(engine->re);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Optionally composite grease pencil over render result. */
|
|
|
|
|
if (engine->has_grease_pencil && use_grease_pencil && !re->result->do_exr_tile) {
|
|
|
|
|
/* NOTE: External engine might have been requested to free its
|
|
|
|
|
* dependency graph, which is only allowed if there is no grease
|
|
|
|
|
* pencil (pipeline is taking care of that). */
|
|
|
|
|
if (!RE_engine_test_break(engine) && engine->depsgraph != NULL) {
|
|
|
|
|
DRW_render_gpencil(engine, engine->depsgraph);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Free dependency graph, if engine has not done it already. */
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
engine_depsgraph_exit(engine);
|
2020-11-09 18:13:03 +01:00
|
|
|
}
|
|
|
|
|
|
2021-01-09 19:00:05 +11:00
|
|
|
bool RE_engine_render(Render *re, bool do_all)
|
2011-10-22 16:24:28 +00:00
|
|
|
{
|
2018-04-17 13:35:05 +02:00
|
|
|
RenderEngineType *type = RE_engines_find(re->r.engine);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-10-22 17:01:54 +00:00
|
|
|
/* verify if we can render */
|
2019-04-22 09:08:06 +10:00
|
|
|
if (!type->render) {
|
2021-01-09 19:00:05 +11:00
|
|
|
return false;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
|
if ((re->r.scemode & R_BUTS_PREVIEW) && !(type->flag & RE_USE_PREVIEW)) {
|
2021-01-09 19:00:05 +11:00
|
|
|
return false;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
|
if (do_all && !(type->flag & RE_USE_POSTPROCESS)) {
|
2021-01-09 19:00:05 +11:00
|
|
|
return false;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
|
if (!do_all && (type->flag & RE_USE_POSTPROCESS)) {
|
2021-01-09 19:00:05 +11:00
|
|
|
return false;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-12-27 18:52:41 +06:00
|
|
|
/* Lock drawing in UI during data phase. */
|
|
|
|
|
if (re->draw_lock) {
|
2021-02-26 16:50:36 +11:00
|
|
|
re->draw_lock(re->dlh, true);
|
2013-12-27 18:52:41 +06:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-05-16 12:03:21 +00:00
|
|
|
/* update animation here so any render layer animation is applied before
|
|
|
|
|
* creating the render result */
|
2013-06-10 13:53:38 +00:00
|
|
|
if ((re->r.scemode & (R_NO_FRAME_UPDATE | R_BUTS_PREVIEW)) == 0) {
|
2017-11-22 10:52:39 -02:00
|
|
|
render_update_anim_renderdata(re, &re->scene->r, &re->scene->view_layers);
|
2013-06-10 13:53:38 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-10-22 16:24:28 +00:00
|
|
|
/* create render result */
|
|
|
|
|
BLI_rw_mutex_lock(&re->resultmutex, THREAD_LOCK_WRITE);
|
2013-05-15 17:09:45 +00:00
|
|
|
if (re->result == NULL || !(re->r.scemode & R_BUTS_PREVIEW)) {
|
2013-07-11 12:22:29 +00:00
|
|
|
int savebuffers = RR_USE_MEM;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (re->result) {
|
2012-01-05 17:50:09 +00:00
|
|
|
render_result_free(re->result);
|
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 ((type->flag & RE_USE_SAVE_BUFFERS) && (re->r.scemode & R_EXR_TILE_FILE)) {
|
2013-07-11 12:22:29 +00:00
|
|
|
savebuffers = RR_USE_EXR;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2020-12-16 16:16:50 +01:00
|
|
|
re->result = render_result_new(re, &re->disprect, savebuffers, RR_ALL_LAYERS, RR_ALL_VIEWS);
|
2011-10-22 16:24:28 +00:00
|
|
|
}
|
|
|
|
|
BLI_rw_mutex_unlock(&re->resultmutex);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-12-27 18:52:41 +06:00
|
|
|
if (re->result == NULL) {
|
|
|
|
|
/* Clear UI drawing locks. */
|
|
|
|
|
if (re->draw_lock) {
|
2021-02-26 16:50:36 +11:00
|
|
|
re->draw_lock(re->dlh, false);
|
2013-12-27 18:52:41 +06:00
|
|
|
}
|
2016-03-03 13:21:04 +05:00
|
|
|
/* Too small image is handled earlier, here it could only happen if
|
|
|
|
|
* there was no sufficient memory to allocate all passes.
|
|
|
|
|
*/
|
|
|
|
|
BKE_report(re->reports, RPT_ERROR, "Failed allocate render result, out of memory");
|
|
|
|
|
G.is_break = true;
|
2021-01-09 19:00:05 +11:00
|
|
|
return true;
|
2013-12-27 18:52:41 +06:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-11-16 12:47:37 +00:00
|
|
|
/* set render info */
|
2012-06-16 16:57:16 +00:00
|
|
|
re->i.cfra = re->scene->r.cfra;
|
2012-07-08 00:04:41 +00:00
|
|
|
BLI_strncpy(re->i.scene_name, re->scene->id.name + 2, sizeof(re->i.scene_name));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-10-22 17:01:54 +00:00
|
|
|
/* render */
|
2020-11-09 18:13:03 +01:00
|
|
|
RenderEngine *engine = re->engine;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-13 11:00:46 +00:00
|
|
|
if (!engine) {
|
|
|
|
|
engine = RE_engine_create(type);
|
2013-01-01 16:15:13 +00:00
|
|
|
re->engine = engine;
|
2012-11-13 11:00:46 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-13 11:00:46 +00:00
|
|
|
engine->flag |= RE_ENGINE_RENDERING;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-09 08:46:53 +00:00
|
|
|
/* TODO: actually link to a parent which shouldn't happen */
|
2012-06-16 16:57:16 +00:00
|
|
|
engine->re = re;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (re->flag & R_ANIMATION) {
|
2011-11-02 13:36:28 +00:00
|
|
|
engine->flag |= RE_ENGINE_ANIMATION;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
|
|
|
|
if (re->r.scemode & R_BUTS_PREVIEW) {
|
2011-11-02 13:36:28 +00:00
|
|
|
engine->flag |= RE_ENGINE_PREVIEW;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2012-04-13 17:42:03 +00:00
|
|
|
engine->camera_override = re->camera_override;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-09-04 13:29:07 +00:00
|
|
|
engine->resolution_x = re->winx;
|
|
|
|
|
engine->resolution_y = re->winy;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-06-30 14:43:00 +02:00
|
|
|
BLI_rw_mutex_lock(&re->partsmutex, THREAD_LOCK_WRITE);
|
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
|
|
|
RE_parts_init(re);
|
2012-09-04 13:29:07 +00:00
|
|
|
engine->tile_x = re->partx;
|
|
|
|
|
engine->tile_y = re->party;
|
2020-06-30 14:43:00 +02:00
|
|
|
BLI_rw_mutex_unlock(&re->partsmutex);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (re->result->do_exr_tile) {
|
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
|
|
|
render_result_exr_file_begin(re, engine);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-12-27 18:52:41 +06:00
|
|
|
/* Clear UI drawing locks. */
|
|
|
|
|
if (re->draw_lock) {
|
2021-02-26 16:50:36 +11:00
|
|
|
re->draw_lock(re->dlh, false);
|
2013-12-27 18:52:41 +06:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-09 18:13:03 +01:00
|
|
|
/* Render view layers. */
|
|
|
|
|
bool delay_grease_pencil = false;
|
|
|
|
|
|
2018-05-30 14:32:47 +02:00
|
|
|
if (type->render) {
|
2018-02-28 10:05:38 +11:00
|
|
|
FOREACH_VIEW_LAYER_TO_RENDER_BEGIN (re, view_layer_iter) {
|
2020-11-09 18:13:03 +01:00
|
|
|
engine_render_view_layer(re, engine, view_layer_iter, true, true);
|
2020-07-20 13:56:29 +02:00
|
|
|
|
2020-11-09 18:13:03 +01:00
|
|
|
/* With save buffers there is no render buffer in memory for compositing, delay
|
|
|
|
|
* grease pencil in that case. */
|
|
|
|
|
delay_grease_pencil = engine->has_grease_pencil && re->result->do_exr_tile;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-08-01 14:21:50 +02:00
|
|
|
if (RE_engine_test_break(engine)) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
2018-02-20 12:55:02 -03:00
|
|
|
}
|
2018-03-09 11:44:42 +11:00
|
|
|
FOREACH_VIEW_LAYER_TO_RENDER_END;
|
2017-04-25 16:18:24 +02:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-09 18:13:03 +01:00
|
|
|
/* Clear tile data */
|
2012-11-13 11:00:46 +00:00
|
|
|
engine->tile_x = 0;
|
|
|
|
|
engine->tile_y = 0;
|
|
|
|
|
engine->flag &= ~RE_ENGINE_RENDERING;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-19 16:42:14 +00:00
|
|
|
render_result_free_list(&engine->fullresult, engine->fullresult.first);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-03-20 17:48:45 +05:00
|
|
|
BLI_rw_mutex_lock(&re->partsmutex, THREAD_LOCK_WRITE);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-09 18:13:03 +01:00
|
|
|
/* For save buffers, read back from disk. */
|
2012-09-04 13:29:07 +00:00
|
|
|
if (re->result->do_exr_tile) {
|
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
|
|
|
render_result_exr_file_end(re, engine);
|
2012-09-04 13:29:07 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-09 18:13:03 +01:00
|
|
|
/* Perform delayed grease pencil rendering. */
|
|
|
|
|
if (delay_grease_pencil) {
|
|
|
|
|
BLI_rw_mutex_unlock(&re->partsmutex);
|
|
|
|
|
|
|
|
|
|
FOREACH_VIEW_LAYER_TO_RENDER_BEGIN (re, view_layer_iter) {
|
|
|
|
|
engine_render_view_layer(re, engine, view_layer_iter, false, true);
|
|
|
|
|
if (RE_engine_test_break(engine)) {
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
FOREACH_VIEW_LAYER_TO_RENDER_END;
|
|
|
|
|
|
|
|
|
|
BLI_rw_mutex_lock(&re->partsmutex, THREAD_LOCK_WRITE);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/* re->engine becomes zero if user changed active render engine during render */
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
if (!engine_keep_depsgraph(engine) || !re->engine) {
|
|
|
|
|
/* Free depsgraph outside of parts mutex lock, since this locks OpenGL context
|
|
|
|
|
* while the the UI drawing might also lock the OpenGL context and parts mutex. */
|
|
|
|
|
BLI_rw_mutex_unlock(&re->partsmutex);
|
|
|
|
|
engine_depsgraph_free(engine);
|
|
|
|
|
BLI_rw_mutex_lock(&re->partsmutex, THREAD_LOCK_WRITE);
|
|
|
|
|
|
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
|
|
|
RE_engine_free(engine);
|
|
|
|
|
re->engine = NULL;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-06-28 19:13:54 +02:00
|
|
|
if (re->r.scemode & R_EXR_CACHE_FILE) {
|
|
|
|
|
BLI_rw_mutex_lock(&re->resultmutex, THREAD_LOCK_WRITE);
|
|
|
|
|
render_result_exr_file_cache_write(re);
|
|
|
|
|
BLI_rw_mutex_unlock(&re->resultmutex);
|
|
|
|
|
}
|
|
|
|
|
|
2012-11-21 10:20:38 +00:00
|
|
|
RE_parts_free(re);
|
2015-03-20 17:48:45 +05:00
|
|
|
BLI_rw_mutex_unlock(&re->partsmutex);
|
2012-09-04 13:29:07 +00:00
|
|
|
|
2019-04-22 09:08:06 +10:00
|
|
|
if (BKE_reports_contain(re->reports, RPT_ERROR)) {
|
2014-04-01 11:34:00 +11:00
|
|
|
G.is_break = true;
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2018-06-08 08:07:48 +02:00
|
|
|
|
2014-06-27 14:56:21 +09:00
|
|
|
#ifdef WITH_FREESTYLE
|
2019-04-22 09:08:06 +10:00
|
|
|
if (re->r.mode & R_EDGE_FRS) {
|
2014-06-27 14:56:21 +09:00
|
|
|
RE_RenderFreestyleExternal(re);
|
2019-04-22 09:08:06 +10:00
|
|
|
}
|
2014-06-27 14:56:21 +09:00
|
|
|
#endif
|
|
|
|
|
|
2021-01-09 19:00:05 +11:00
|
|
|
return true;
|
2011-10-22 16:24:28 +00:00
|
|
|
}
|
|
|
|
|
|
2019-01-18 01:47:32 +01:00
|
|
|
void RE_engine_update_render_passes(struct RenderEngine *engine,
|
|
|
|
|
struct Scene *scene,
|
|
|
|
|
struct ViewLayer *view_layer,
|
2019-03-01 19:09:17 +01:00
|
|
|
update_render_passes_cb_t callback,
|
|
|
|
|
void *callback_data)
|
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-01-18 01:47:32 +01:00
|
|
|
if (!(scene && view_layer && engine && callback && engine->type->update_render_passes)) {
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
BLI_mutex_lock(&engine->update_render_passes_mutex);
|
2019-01-08 13:21:39 +01: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
|
|
|
engine->update_render_passes_cb = callback;
|
2019-03-01 19:09:17 +01:00
|
|
|
engine->update_render_passes_data = callback_data;
|
2019-01-18 01:47:32 +01:00
|
|
|
engine->type->update_render_passes(engine, scene, view_layer);
|
2019-03-01 19:09:17 +01:00
|
|
|
engine->update_render_passes_cb = NULL;
|
|
|
|
|
engine->update_render_passes_data = NULL;
|
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
|
|
|
|
|
|
|
|
BLI_mutex_unlock(&engine->update_render_passes_mutex);
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-18 01:47:32 +01:00
|
|
|
void RE_engine_register_pass(struct RenderEngine *engine,
|
|
|
|
|
struct Scene *scene,
|
|
|
|
|
struct ViewLayer *view_layer,
|
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
|
|
|
const char *name,
|
|
|
|
|
int channels,
|
|
|
|
|
const char *chanid,
|
2020-02-20 14:53:53 +01:00
|
|
|
eNodeSocketDatatype 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-01-18 01:47:32 +01:00
|
|
|
if (!(scene && view_layer && engine && engine->update_render_passes_cb)) {
|
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
|
|
|
return;
|
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
|
|
|
}
|
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:29:26 +01:00
|
|
|
engine->update_render_passes_cb(
|
|
|
|
|
engine->update_render_passes_data, scene, view_layer, name, channels, chanid, type);
|
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
|
|
|
}
|
2018-11-09 16:14:15 +01:00
|
|
|
|
|
|
|
|
void RE_engine_free_blender_memory(RenderEngine *engine)
|
|
|
|
|
{
|
|
|
|
|
/* Weak way to save memory, but not crash grease pencil.
|
|
|
|
|
*
|
|
|
|
|
* TODO(sergey): Find better solution for this.
|
|
|
|
|
*/
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
if (engine->has_grease_pencil || engine_keep_depsgraph(engine)) {
|
2018-11-09 16:14:15 +01:00
|
|
|
return;
|
|
|
|
|
}
|
Render: faster animation and re-rendering with Persistent Data
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
2021-04-04 23:51:24 +02:00
|
|
|
engine_depsgraph_free(engine);
|
2018-11-09 16:14:15 +01:00
|
|
|
}
|