2011-02-23 10:52:22 +00:00
|
|
|
/*
|
2009-07-21 14:11:51 +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
|
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* 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,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2009-07-21 14:11:51 +00:00
|
|
|
*/
|
|
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup RNA
|
2011-02-27 20:20:01 +00:00
|
|
|
*/
|
|
|
|
|
|
2009-07-21 14:11:51 +00:00
|
|
|
#include <stdlib.h>
|
|
|
|
|
|
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
|
|
|
#include "DNA_node_types.h"
|
2015-04-06 10:40:12 -03:00
|
|
|
#include "DNA_object_types.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "DNA_scene_types.h"
|
2009-07-21 14:11:51 +00:00
|
|
|
|
2012-09-03 22:04:14 +00:00
|
|
|
#include "BLI_path_util.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLI_utildefines.h"
|
2012-09-03 22:04:14 +00:00
|
|
|
|
2020-10-16 15:56:03 +11:00
|
|
|
#ifdef WITH_PYTHON
|
|
|
|
|
# include "BPY_extern.h"
|
|
|
|
|
#endif
|
2020-07-20 17:23:18 +02:00
|
|
|
|
2017-04-25 16:18:24 +02:00
|
|
|
#include "DEG_depsgraph.h"
|
|
|
|
|
|
2017-02-06 17:23:02 +01:00
|
|
|
#include "BKE_image.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BKE_scene.h"
|
2017-08-15 00:11:52 +02:00
|
|
|
|
2009-07-21 14:11:51 +00:00
|
|
|
#include "RNA_define.h"
|
2011-05-17 15:20:12 +00:00
|
|
|
#include "RNA_enum_types.h"
|
2009-07-21 14:11:51 +00:00
|
|
|
|
|
|
|
|
#include "rna_internal.h"
|
|
|
|
|
|
2011-05-05 09:43:45 +00:00
|
|
|
#include "RE_engine.h"
|
2009-07-21 14:11:51 +00:00
|
|
|
#include "RE_pipeline.h"
|
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-09-18 03:36:39 +02:00
|
|
|
#include "ED_render.h"
|
2009-07-21 14:11:51 +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
|
|
|
/* Deprecated, only provided for API compatibility. */
|
2017-10-18 15:07:26 +11:00
|
|
|
const EnumPropertyItem rna_enum_render_pass_type_items[] = {
|
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
|
|
|
{SCE_PASS_COMBINED, "COMBINED", 0, "Combined", ""},
|
|
|
|
|
{SCE_PASS_Z, "Z", 0, "Z", ""},
|
|
|
|
|
{SCE_PASS_SHADOW, "SHADOW", 0, "Shadow", ""},
|
2018-11-01 15:56:03 +01:00
|
|
|
{SCE_PASS_AO, "AO", 0, "Ambient Occlusion", ""},
|
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
|
|
|
{SCE_PASS_NORMAL, "NORMAL", 0, "Normal", ""},
|
|
|
|
|
{SCE_PASS_VECTOR, "VECTOR", 0, "Vector", ""},
|
|
|
|
|
{SCE_PASS_INDEXOB, "OBJECT_INDEX", 0, "Object Index", ""},
|
|
|
|
|
{SCE_PASS_UV, "UV", 0, "UV", ""},
|
|
|
|
|
{SCE_PASS_MIST, "MIST", 0, "Mist", ""},
|
|
|
|
|
{SCE_PASS_EMIT, "EMIT", 0, "Emit", ""},
|
|
|
|
|
{SCE_PASS_ENVIRONMENT, "ENVIRONMENT", 0, "Environment", ""},
|
|
|
|
|
{SCE_PASS_INDEXMA, "MATERIAL_INDEX", 0, "Material Index", ""},
|
|
|
|
|
{SCE_PASS_DIFFUSE_DIRECT, "DIFFUSE_DIRECT", 0, "Diffuse Direct", ""},
|
|
|
|
|
{SCE_PASS_DIFFUSE_INDIRECT, "DIFFUSE_INDIRECT", 0, "Diffuse Indirect", ""},
|
|
|
|
|
{SCE_PASS_DIFFUSE_COLOR, "DIFFUSE_COLOR", 0, "Diffuse Color", ""},
|
|
|
|
|
{SCE_PASS_GLOSSY_DIRECT, "GLOSSY_DIRECT", 0, "Glossy Direct", ""},
|
|
|
|
|
{SCE_PASS_GLOSSY_INDIRECT, "GLOSSY_INDIRECT", 0, "Glossy Indirect", ""},
|
|
|
|
|
{SCE_PASS_GLOSSY_COLOR, "GLOSSY_COLOR", 0, "Glossy Color", ""},
|
|
|
|
|
{SCE_PASS_TRANSM_DIRECT, "TRANSMISSION_DIRECT", 0, "Transmission Direct", ""},
|
|
|
|
|
{SCE_PASS_TRANSM_INDIRECT, "TRANSMISSION_INDIRECT", 0, "Transmission Indirect", ""},
|
|
|
|
|
{SCE_PASS_TRANSM_COLOR, "TRANSMISSION_COLOR", 0, "Transmission Color", ""},
|
|
|
|
|
{SCE_PASS_SUBSURFACE_DIRECT, "SUBSURFACE_DIRECT", 0, "Subsurface Direct", ""},
|
|
|
|
|
{SCE_PASS_SUBSURFACE_INDIRECT, "SUBSURFACE_INDIRECT", 0, "Subsurface Indirect", ""},
|
|
|
|
|
{SCE_PASS_SUBSURFACE_COLOR, "SUBSURFACE_COLOR", 0, "Subsurface Color", ""},
|
2014-10-04 19:00:26 +06:00
|
|
|
#ifdef WITH_CYCLES_DEBUG
|
|
|
|
|
{SCE_PASS_DEBUG, "DEBUG", 0, "Pass used for render engine debugging", ""},
|
|
|
|
|
#endif
|
2019-02-03 14:01:45 +11:00
|
|
|
{0, NULL, 0, NULL, 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
|
|
|
};
|
2011-01-07 19:18:31 +00:00
|
|
|
|
2017-10-18 15:07:26 +11:00
|
|
|
const EnumPropertyItem rna_enum_bake_pass_type_items[] = {
|
2016-01-15 13:00:56 -02:00
|
|
|
{SCE_PASS_COMBINED, "COMBINED", 0, "Combined", ""},
|
2018-11-01 15:56:03 +01:00
|
|
|
{SCE_PASS_AO, "AO", 0, "Ambient Occlusion", ""},
|
2016-01-15 13:00:56 -02:00
|
|
|
{SCE_PASS_SHADOW, "SHADOW", 0, "Shadow", ""},
|
|
|
|
|
{SCE_PASS_NORMAL, "NORMAL", 0, "Normal", ""},
|
|
|
|
|
{SCE_PASS_UV, "UV", 0, "UV", ""},
|
2018-03-10 18:18:05 +01:00
|
|
|
{SCE_PASS_ROUGHNESS, "ROUGHNESS", 0, "ROUGHNESS", ""},
|
2016-01-15 13:00:56 -02:00
|
|
|
{SCE_PASS_EMIT, "EMIT", 0, "Emit", ""},
|
|
|
|
|
{SCE_PASS_ENVIRONMENT, "ENVIRONMENT", 0, "Environment", ""},
|
|
|
|
|
{SCE_PASS_DIFFUSE_COLOR, "DIFFUSE", 0, "Diffuse", ""},
|
|
|
|
|
{SCE_PASS_GLOSSY_COLOR, "GLOSSY", 0, "Glossy", ""},
|
|
|
|
|
{SCE_PASS_TRANSM_COLOR, "TRANSMISSION", 0, "Transmission", ""},
|
2019-02-03 14:01:45 +11:00
|
|
|
{0, NULL, 0, NULL, NULL},
|
2016-01-15 13:00:56 -02:00
|
|
|
};
|
|
|
|
|
|
2009-07-21 14:11:51 +00:00
|
|
|
#ifdef RNA_RUNTIME
|
|
|
|
|
|
|
|
|
|
# include "MEM_guardedalloc.h"
|
|
|
|
|
|
|
|
|
|
# include "RNA_access.h"
|
|
|
|
|
|
|
|
|
|
# include "BKE_context.h"
|
|
|
|
|
# include "BKE_report.h"
|
|
|
|
|
|
2020-09-07 19:35:56 +02:00
|
|
|
# include "GPU_capabilities.h"
|
2020-02-11 15:18:55 +01:00
|
|
|
# include "GPU_shader.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
# include "IMB_colormanagement.h"
|
2013-08-30 23:49:35 +00:00
|
|
|
|
2018-05-23 12:13:21 +02:00
|
|
|
# include "DEG_depsgraph_query.h"
|
|
|
|
|
|
2011-11-02 15:15:45 +00:00
|
|
|
/* RenderEngine Callbacks */
|
|
|
|
|
|
2012-10-22 17:34:16 +00:00
|
|
|
static void engine_tag_redraw(RenderEngine *engine)
|
2.5: Render/Game Engine
An engine to use for output can now be selected an influences what
shows in the buttons window, only showing relevant data. The idea
behind this is to make it more clear what is supported where, make
the system more pluggable for external render/game engines, and save
space hiding stuff that is not relevant anyway.
* Top header now has an engine menu, to choose between the blender
render engine, game engine, and other future external engines.
* If the game engine is enabled, the buttons window should show
only properties that work in the game engine, and similarly for
the render engine.
* Moved panels from the logic space and game tabs to the physics,
scene and world tabs instead, and removed the game tab.
* Materials and textures tabs should eventually become game
specific too, to better show what is supported.
2009-07-23 21:50:40 +00:00
|
|
|
{
|
2011-11-02 15:15:45 +00:00
|
|
|
engine->flag |= RE_ENGINE_DO_DRAW;
|
2.5: Render/Game Engine
An engine to use for output can now be selected an influences what
shows in the buttons window, only showing relevant data. The idea
behind this is to make it more clear what is supported where, make
the system more pluggable for external render/game engines, and save
space hiding stuff that is not relevant anyway.
* Top header now has an engine menu, to choose between the blender
render engine, game engine, and other future external engines.
* If the game engine is enabled, the buttons window should show
only properties that work in the game engine, and similarly for
the render engine.
* Moved panels from the logic space and game tabs to the physics,
scene and world tabs instead, and removed the game tab.
* Materials and textures tabs should eventually become game
specific too, to better show what is supported.
2009-07-23 21:50:40 +00:00
|
|
|
}
|
|
|
|
|
|
2012-10-22 17:34:16 +00:00
|
|
|
static void engine_tag_update(RenderEngine *engine)
|
2.5: Render/Game Engine
An engine to use for output can now be selected an influences what
shows in the buttons window, only showing relevant data. The idea
behind this is to make it more clear what is supported where, make
the system more pluggable for external render/game engines, and save
space hiding stuff that is not relevant anyway.
* Top header now has an engine menu, to choose between the blender
render engine, game engine, and other future external engines.
* If the game engine is enabled, the buttons window should show
only properties that work in the game engine, and similarly for
the render engine.
* Moved panels from the logic space and game tabs to the physics,
scene and world tabs instead, and removed the game tab.
* Materials and textures tabs should eventually become game
specific too, to better show what is supported.
2009-07-23 21:50:40 +00:00
|
|
|
{
|
2011-11-02 15:15:45 +00:00
|
|
|
engine->flag |= RE_ENGINE_DO_UPDATE;
|
2011-05-17 14:26:45 +00:00
|
|
|
}
|
2.5: Render/Game Engine
An engine to use for output can now be selected an influences what
shows in the buttons window, only showing relevant data. The idea
behind this is to make it more clear what is supported where, make
the system more pluggable for external render/game engines, and save
space hiding stuff that is not relevant anyway.
* Top header now has an engine menu, to choose between the blender
render engine, game engine, and other future external engines.
* If the game engine is enabled, the buttons window should show
only properties that work in the game engine, and similarly for
the render engine.
* Moved panels from the logic space and game tabs to the physics,
scene and world tabs instead, and removed the game tab.
* Materials and textures tabs should eventually become game
specific too, to better show what is supported.
2009-07-23 21:50:40 +00:00
|
|
|
|
2018-07-01 15:47:09 +02:00
|
|
|
static bool engine_support_display_space_shader(RenderEngine *UNUSED(engine), Scene *scene)
|
2013-08-30 23:49:35 +00:00
|
|
|
{
|
2013-10-09 15:57:32 +00:00
|
|
|
return IMB_colormanagement_support_glsl_draw(&scene->view_settings);
|
2013-08-30 23:49:35 +00:00
|
|
|
}
|
|
|
|
|
|
2017-08-15 00:11:52 +02:00
|
|
|
static int engine_get_preview_pixel_size(RenderEngine *UNUSED(engine), Scene *scene)
|
|
|
|
|
{
|
|
|
|
|
return BKE_render_preview_pixel_size(&scene->r);
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-11 15:18:55 +01:00
|
|
|
static void engine_bind_display_space_shader(RenderEngine *UNUSED(engine), Scene *UNUSED(scene))
|
2013-08-30 23:49:35 +00:00
|
|
|
{
|
2020-02-24 13:53:34 +01:00
|
|
|
GPUShader *shader = GPU_shader_get_builtin_shader(GPU_SHADER_2D_IMAGE);
|
2020-02-11 15:18:55 +01:00
|
|
|
GPU_shader_bind(shader);
|
|
|
|
|
|
2020-06-02 12:29:20 +02:00
|
|
|
int img_loc = GPU_shader_get_uniform(shader, "image");
|
2020-02-11 15:18:55 +01:00
|
|
|
|
|
|
|
|
GPU_shader_uniform_int(shader, img_loc, 0);
|
2013-08-30 23:49:35 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void engine_unbind_display_space_shader(RenderEngine *UNUSED(engine))
|
|
|
|
|
{
|
2020-02-11 15:18:55 +01:00
|
|
|
GPU_shader_unbind();
|
2013-08-30 23:49:35 +00:00
|
|
|
}
|
|
|
|
|
|
2018-05-23 12:13:21 +02:00
|
|
|
static void engine_update(RenderEngine *engine, Main *bmain, Depsgraph *depsgraph)
|
2011-05-17 14:26:45 +00:00
|
|
|
{
|
2011-10-21 20:13:12 +00:00
|
|
|
extern FunctionRNA rna_RenderEngine_update_func;
|
2011-05-17 14:26:45 +00:00
|
|
|
PointerRNA ptr;
|
|
|
|
|
ParameterList list;
|
|
|
|
|
FunctionRNA *func;
|
2.5: Render/Game Engine
An engine to use for output can now be selected an influences what
shows in the buttons window, only showing relevant data. The idea
behind this is to make it more clear what is supported where, make
the system more pluggable for external render/game engines, and save
space hiding stuff that is not relevant anyway.
* Top header now has an engine menu, to choose between the blender
render engine, game engine, and other future external engines.
* If the game engine is enabled, the buttons window should show
only properties that work in the game engine, and similarly for
the render engine.
* Moved panels from the logic space and game tabs to the physics,
scene and world tabs instead, and removed the game tab.
* Materials and textures tabs should eventually become game
specific too, to better show what is supported.
2009-07-23 21:50:40 +00:00
|
|
|
|
2020-04-03 18:24:08 +02:00
|
|
|
RNA_pointer_create(NULL, engine->type->rna_ext.srna, engine, &ptr);
|
2012-03-05 23:30:41 +00:00
|
|
|
func = &rna_RenderEngine_update_func;
|
2.5: Render/Game Engine
An engine to use for output can now be selected an influences what
shows in the buttons window, only showing relevant data. The idea
behind this is to make it more clear what is supported where, make
the system more pluggable for external render/game engines, and save
space hiding stuff that is not relevant anyway.
* Top header now has an engine menu, to choose between the blender
render engine, game engine, and other future external engines.
* If the game engine is enabled, the buttons window should show
only properties that work in the game engine, and similarly for
the render engine.
* Moved panels from the logic space and game tabs to the physics,
scene and world tabs instead, and removed the game tab.
* Materials and textures tabs should eventually become game
specific too, to better show what is supported.
2009-07-23 21:50:40 +00:00
|
|
|
|
2011-05-17 14:26:45 +00:00
|
|
|
RNA_parameter_list_create(&list, &ptr, func);
|
|
|
|
|
RNA_parameter_set_lookup(&list, "data", &bmain);
|
2018-05-23 12:13:21 +02:00
|
|
|
RNA_parameter_set_lookup(&list, "depsgraph", &depsgraph);
|
2020-04-03 18:24:08 +02:00
|
|
|
engine->type->rna_ext.call(NULL, &ptr, func, &list);
|
2011-05-17 14:26:45 +00:00
|
|
|
|
|
|
|
|
RNA_parameter_list_free(&list);
|
2.5: Render/Game Engine
An engine to use for output can now be selected an influences what
shows in the buttons window, only showing relevant data. The idea
behind this is to make it more clear what is supported where, make
the system more pluggable for external render/game engines, and save
space hiding stuff that is not relevant anyway.
* Top header now has an engine menu, to choose between the blender
render engine, game engine, and other future external engines.
* If the game engine is enabled, the buttons window should show
only properties that work in the game engine, and similarly for
the render engine.
* Moved panels from the logic space and game tabs to the physics,
scene and world tabs instead, and removed the game tab.
* Materials and textures tabs should eventually become game
specific too, to better show what is supported.
2009-07-23 21:50:40 +00:00
|
|
|
}
|
|
|
|
|
|
2018-05-30 14:32:47 +02:00
|
|
|
static void engine_render(RenderEngine *engine, Depsgraph *depsgraph)
|
Blender modifications for Cycles integration.
Some notes about code status:
* The Blender modifications were fairly quickly put together, much more code
polish and work is needed to get this to a state where it can be committed
to trunk. Files created with this version may not work in future versions.
* Only simple path tracing is supported currently, but we intend to provide
finer control, and more options where it makes sense.
* For GPU rendering, only CUDA works currently. The intention is to have the
same kernel code compile for C++/OpenCL/CUDA, some more work is needed to
get OpenCL functional.
* There are two shading backends: GPU compatible and Open Shading Language.
Unfortunately, OSL only runs on the CPU currently, getting this to run on
the GPU would be a major undertaking, and is unlikely to be supported soon.
Additionally, it's not possible yet to write custom OSL shaders.
* There is some code for adaptive subdivision and displacement, but it's far
from finished. The intention is to eventually have a nice unified bump and
displacement system.
* The code currently has a number of fairly heavy dependencies: Boost,
OpenImageIO, GLEW, GLUT, and optionally OSL, Partio. This makes it difficult
to compile, we'll try to eliminate some, it may take a while before it
becomes easy to compile this.
2011-04-27 14:36:02 +00:00
|
|
|
{
|
2018-05-30 14:32:47 +02:00
|
|
|
extern FunctionRNA rna_RenderEngine_render_func;
|
2011-05-17 14:26:45 +00:00
|
|
|
PointerRNA ptr;
|
|
|
|
|
ParameterList list;
|
|
|
|
|
FunctionRNA *func;
|
|
|
|
|
|
2020-04-03 18:24:08 +02:00
|
|
|
RNA_pointer_create(NULL, engine->type->rna_ext.srna, engine, &ptr);
|
2018-05-30 14:32:47 +02:00
|
|
|
func = &rna_RenderEngine_render_func;
|
2011-05-17 14:26:45 +00:00
|
|
|
|
|
|
|
|
RNA_parameter_list_create(&list, &ptr, func);
|
2017-04-25 16:18:24 +02:00
|
|
|
RNA_parameter_set_lookup(&list, "depsgraph", &depsgraph);
|
2020-04-03 18:24:08 +02:00
|
|
|
engine->type->rna_ext.call(NULL, &ptr, func, &list);
|
2011-05-17 14:26:45 +00:00
|
|
|
|
|
|
|
|
RNA_parameter_list_free(&list);
|
Blender modifications for Cycles integration.
Some notes about code status:
* The Blender modifications were fairly quickly put together, much more code
polish and work is needed to get this to a state where it can be committed
to trunk. Files created with this version may not work in future versions.
* Only simple path tracing is supported currently, but we intend to provide
finer control, and more options where it makes sense.
* For GPU rendering, only CUDA works currently. The intention is to have the
same kernel code compile for C++/OpenCL/CUDA, some more work is needed to
get OpenCL functional.
* There are two shading backends: GPU compatible and Open Shading Language.
Unfortunately, OSL only runs on the CPU currently, getting this to run on
the GPU would be a major undertaking, and is unlikely to be supported soon.
Additionally, it's not possible yet to write custom OSL shaders.
* There is some code for adaptive subdivision and displacement, but it's far
from finished. The intention is to eventually have a nice unified bump and
displacement system.
* The code currently has a number of fairly heavy dependencies: Boost,
OpenImageIO, GLEW, GLUT, and optionally OSL, Partio. This makes it difficult
to compile, we'll try to eliminate some, it may take a while before it
becomes easy to compile this.
2011-04-27 14:36:02 +00:00
|
|
|
}
|
|
|
|
|
|
2018-05-23 12:13:21 +02:00
|
|
|
static void engine_bake(RenderEngine *engine,
|
|
|
|
|
struct Depsgraph *depsgraph,
|
2016-01-15 13:00:56 -02:00
|
|
|
struct Object *object,
|
|
|
|
|
const int pass_type,
|
|
|
|
|
const int pass_filter,
|
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
|
|
|
const int width,
|
|
|
|
|
const int height)
|
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
|
|
|
{
|
|
|
|
|
extern FunctionRNA rna_RenderEngine_bake_func;
|
|
|
|
|
PointerRNA ptr;
|
|
|
|
|
ParameterList list;
|
|
|
|
|
FunctionRNA *func;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-04-03 18:24:08 +02:00
|
|
|
RNA_pointer_create(NULL, engine->type->rna_ext.srna, engine, &ptr);
|
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
|
|
|
func = &rna_RenderEngine_bake_func;
|
2019-04-17 06:17:24 +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
|
|
|
RNA_parameter_list_create(&list, &ptr, func);
|
2018-02-26 16:46:48 +01:00
|
|
|
RNA_parameter_set_lookup(&list, "depsgraph", &depsgraph);
|
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
|
|
|
RNA_parameter_set_lookup(&list, "object", &object);
|
|
|
|
|
RNA_parameter_set_lookup(&list, "pass_type", &pass_type);
|
2016-01-15 13:00:56 -02:00
|
|
|
RNA_parameter_set_lookup(&list, "pass_filter", &pass_filter);
|
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
|
|
|
RNA_parameter_set_lookup(&list, "width", &width);
|
|
|
|
|
RNA_parameter_set_lookup(&list, "height", &height);
|
2020-04-03 18:24:08 +02:00
|
|
|
engine->type->rna_ext.call(NULL, &ptr, func, &list);
|
2019-04-17 06:17:24 +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
|
|
|
RNA_parameter_list_free(&list);
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-16 17:19:05 +02:00
|
|
|
static void engine_view_update(RenderEngine *engine,
|
|
|
|
|
const struct bContext *context,
|
|
|
|
|
Depsgraph *depsgraph)
|
Blender modifications for Cycles integration.
Some notes about code status:
* The Blender modifications were fairly quickly put together, much more code
polish and work is needed to get this to a state where it can be committed
to trunk. Files created with this version may not work in future versions.
* Only simple path tracing is supported currently, but we intend to provide
finer control, and more options where it makes sense.
* For GPU rendering, only CUDA works currently. The intention is to have the
same kernel code compile for C++/OpenCL/CUDA, some more work is needed to
get OpenCL functional.
* There are two shading backends: GPU compatible and Open Shading Language.
Unfortunately, OSL only runs on the CPU currently, getting this to run on
the GPU would be a major undertaking, and is unlikely to be supported soon.
Additionally, it's not possible yet to write custom OSL shaders.
* There is some code for adaptive subdivision and displacement, but it's far
from finished. The intention is to eventually have a nice unified bump and
displacement system.
* The code currently has a number of fairly heavy dependencies: Boost,
OpenImageIO, GLEW, GLUT, and optionally OSL, Partio. This makes it difficult
to compile, we'll try to eliminate some, it may take a while before it
becomes easy to compile this.
2011-04-27 14:36:02 +00:00
|
|
|
{
|
2011-10-21 20:13:12 +00:00
|
|
|
extern FunctionRNA rna_RenderEngine_view_update_func;
|
Blender modifications for Cycles integration.
Some notes about code status:
* The Blender modifications were fairly quickly put together, much more code
polish and work is needed to get this to a state where it can be committed
to trunk. Files created with this version may not work in future versions.
* Only simple path tracing is supported currently, but we intend to provide
finer control, and more options where it makes sense.
* For GPU rendering, only CUDA works currently. The intention is to have the
same kernel code compile for C++/OpenCL/CUDA, some more work is needed to
get OpenCL functional.
* There are two shading backends: GPU compatible and Open Shading Language.
Unfortunately, OSL only runs on the CPU currently, getting this to run on
the GPU would be a major undertaking, and is unlikely to be supported soon.
Additionally, it's not possible yet to write custom OSL shaders.
* There is some code for adaptive subdivision and displacement, but it's far
from finished. The intention is to eventually have a nice unified bump and
displacement system.
* The code currently has a number of fairly heavy dependencies: Boost,
OpenImageIO, GLEW, GLUT, and optionally OSL, Partio. This makes it difficult
to compile, we'll try to eliminate some, it may take a while before it
becomes easy to compile this.
2011-04-27 14:36:02 +00:00
|
|
|
PointerRNA ptr;
|
|
|
|
|
ParameterList list;
|
|
|
|
|
FunctionRNA *func;
|
|
|
|
|
|
2020-04-03 18:24:08 +02:00
|
|
|
RNA_pointer_create(NULL, engine->type->rna_ext.srna, engine, &ptr);
|
2012-03-05 23:30:41 +00:00
|
|
|
func = &rna_RenderEngine_view_update_func;
|
Blender modifications for Cycles integration.
Some notes about code status:
* The Blender modifications were fairly quickly put together, much more code
polish and work is needed to get this to a state where it can be committed
to trunk. Files created with this version may not work in future versions.
* Only simple path tracing is supported currently, but we intend to provide
finer control, and more options where it makes sense.
* For GPU rendering, only CUDA works currently. The intention is to have the
same kernel code compile for C++/OpenCL/CUDA, some more work is needed to
get OpenCL functional.
* There are two shading backends: GPU compatible and Open Shading Language.
Unfortunately, OSL only runs on the CPU currently, getting this to run on
the GPU would be a major undertaking, and is unlikely to be supported soon.
Additionally, it's not possible yet to write custom OSL shaders.
* There is some code for adaptive subdivision and displacement, but it's far
from finished. The intention is to eventually have a nice unified bump and
displacement system.
* The code currently has a number of fairly heavy dependencies: Boost,
OpenImageIO, GLEW, GLUT, and optionally OSL, Partio. This makes it difficult
to compile, we'll try to eliminate some, it may take a while before it
becomes easy to compile this.
2011-04-27 14:36:02 +00:00
|
|
|
|
|
|
|
|
RNA_parameter_list_create(&list, &ptr, func);
|
2011-05-17 14:26:45 +00:00
|
|
|
RNA_parameter_set_lookup(&list, "context", &context);
|
2019-05-16 17:19:05 +02:00
|
|
|
RNA_parameter_set_lookup(&list, "depsgraph", &depsgraph);
|
2020-04-03 18:24:08 +02:00
|
|
|
engine->type->rna_ext.call(NULL, &ptr, func, &list);
|
Blender modifications for Cycles integration.
Some notes about code status:
* The Blender modifications were fairly quickly put together, much more code
polish and work is needed to get this to a state where it can be committed
to trunk. Files created with this version may not work in future versions.
* Only simple path tracing is supported currently, but we intend to provide
finer control, and more options where it makes sense.
* For GPU rendering, only CUDA works currently. The intention is to have the
same kernel code compile for C++/OpenCL/CUDA, some more work is needed to
get OpenCL functional.
* There are two shading backends: GPU compatible and Open Shading Language.
Unfortunately, OSL only runs on the CPU currently, getting this to run on
the GPU would be a major undertaking, and is unlikely to be supported soon.
Additionally, it's not possible yet to write custom OSL shaders.
* There is some code for adaptive subdivision and displacement, but it's far
from finished. The intention is to eventually have a nice unified bump and
displacement system.
* The code currently has a number of fairly heavy dependencies: Boost,
OpenImageIO, GLEW, GLUT, and optionally OSL, Partio. This makes it difficult
to compile, we'll try to eliminate some, it may take a while before it
becomes easy to compile this.
2011-04-27 14:36:02 +00:00
|
|
|
|
|
|
|
|
RNA_parameter_list_free(&list);
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-16 17:19:05 +02:00
|
|
|
static void engine_view_draw(RenderEngine *engine,
|
|
|
|
|
const struct bContext *context,
|
|
|
|
|
Depsgraph *depsgraph)
|
Blender modifications for Cycles integration.
Some notes about code status:
* The Blender modifications were fairly quickly put together, much more code
polish and work is needed to get this to a state where it can be committed
to trunk. Files created with this version may not work in future versions.
* Only simple path tracing is supported currently, but we intend to provide
finer control, and more options where it makes sense.
* For GPU rendering, only CUDA works currently. The intention is to have the
same kernel code compile for C++/OpenCL/CUDA, some more work is needed to
get OpenCL functional.
* There are two shading backends: GPU compatible and Open Shading Language.
Unfortunately, OSL only runs on the CPU currently, getting this to run on
the GPU would be a major undertaking, and is unlikely to be supported soon.
Additionally, it's not possible yet to write custom OSL shaders.
* There is some code for adaptive subdivision and displacement, but it's far
from finished. The intention is to eventually have a nice unified bump and
displacement system.
* The code currently has a number of fairly heavy dependencies: Boost,
OpenImageIO, GLEW, GLUT, and optionally OSL, Partio. This makes it difficult
to compile, we'll try to eliminate some, it may take a while before it
becomes easy to compile this.
2011-04-27 14:36:02 +00:00
|
|
|
{
|
2018-05-30 14:32:47 +02:00
|
|
|
extern FunctionRNA rna_RenderEngine_view_draw_func;
|
Blender modifications for Cycles integration.
Some notes about code status:
* The Blender modifications were fairly quickly put together, much more code
polish and work is needed to get this to a state where it can be committed
to trunk. Files created with this version may not work in future versions.
* Only simple path tracing is supported currently, but we intend to provide
finer control, and more options where it makes sense.
* For GPU rendering, only CUDA works currently. The intention is to have the
same kernel code compile for C++/OpenCL/CUDA, some more work is needed to
get OpenCL functional.
* There are two shading backends: GPU compatible and Open Shading Language.
Unfortunately, OSL only runs on the CPU currently, getting this to run on
the GPU would be a major undertaking, and is unlikely to be supported soon.
Additionally, it's not possible yet to write custom OSL shaders.
* There is some code for adaptive subdivision and displacement, but it's far
from finished. The intention is to eventually have a nice unified bump and
displacement system.
* The code currently has a number of fairly heavy dependencies: Boost,
OpenImageIO, GLEW, GLUT, and optionally OSL, Partio. This makes it difficult
to compile, we'll try to eliminate some, it may take a while before it
becomes easy to compile this.
2011-04-27 14:36:02 +00:00
|
|
|
PointerRNA ptr;
|
|
|
|
|
ParameterList list;
|
|
|
|
|
FunctionRNA *func;
|
|
|
|
|
|
2020-04-03 18:24:08 +02:00
|
|
|
RNA_pointer_create(NULL, engine->type->rna_ext.srna, engine, &ptr);
|
2018-05-30 14:32:47 +02:00
|
|
|
func = &rna_RenderEngine_view_draw_func;
|
Blender modifications for Cycles integration.
Some notes about code status:
* The Blender modifications were fairly quickly put together, much more code
polish and work is needed to get this to a state where it can be committed
to trunk. Files created with this version may not work in future versions.
* Only simple path tracing is supported currently, but we intend to provide
finer control, and more options where it makes sense.
* For GPU rendering, only CUDA works currently. The intention is to have the
same kernel code compile for C++/OpenCL/CUDA, some more work is needed to
get OpenCL functional.
* There are two shading backends: GPU compatible and Open Shading Language.
Unfortunately, OSL only runs on the CPU currently, getting this to run on
the GPU would be a major undertaking, and is unlikely to be supported soon.
Additionally, it's not possible yet to write custom OSL shaders.
* There is some code for adaptive subdivision and displacement, but it's far
from finished. The intention is to eventually have a nice unified bump and
displacement system.
* The code currently has a number of fairly heavy dependencies: Boost,
OpenImageIO, GLEW, GLUT, and optionally OSL, Partio. This makes it difficult
to compile, we'll try to eliminate some, it may take a while before it
becomes easy to compile this.
2011-04-27 14:36:02 +00:00
|
|
|
|
|
|
|
|
RNA_parameter_list_create(&list, &ptr, func);
|
2011-05-17 14:26:45 +00:00
|
|
|
RNA_parameter_set_lookup(&list, "context", &context);
|
2019-05-16 17:19:05 +02:00
|
|
|
RNA_parameter_set_lookup(&list, "depsgraph", &depsgraph);
|
2020-04-03 18:24:08 +02:00
|
|
|
engine->type->rna_ext.call(NULL, &ptr, func, &list);
|
Blender modifications for Cycles integration.
Some notes about code status:
* The Blender modifications were fairly quickly put together, much more code
polish and work is needed to get this to a state where it can be committed
to trunk. Files created with this version may not work in future versions.
* Only simple path tracing is supported currently, but we intend to provide
finer control, and more options where it makes sense.
* For GPU rendering, only CUDA works currently. The intention is to have the
same kernel code compile for C++/OpenCL/CUDA, some more work is needed to
get OpenCL functional.
* There are two shading backends: GPU compatible and Open Shading Language.
Unfortunately, OSL only runs on the CPU currently, getting this to run on
the GPU would be a major undertaking, and is unlikely to be supported soon.
Additionally, it's not possible yet to write custom OSL shaders.
* There is some code for adaptive subdivision and displacement, but it's far
from finished. The intention is to eventually have a nice unified bump and
displacement system.
* The code currently has a number of fairly heavy dependencies: Boost,
OpenImageIO, GLEW, GLUT, and optionally OSL, Partio. This makes it difficult
to compile, we'll try to eliminate some, it may take a while before it
becomes easy to compile this.
2011-04-27 14:36:02 +00:00
|
|
|
|
|
|
|
|
RNA_parameter_list_free(&list);
|
|
|
|
|
}
|
|
|
|
|
|
2012-11-03 14:32:26 +00:00
|
|
|
static void engine_update_script_node(RenderEngine *engine,
|
|
|
|
|
struct bNodeTree *ntree,
|
|
|
|
|
struct bNode *node)
|
|
|
|
|
{
|
|
|
|
|
extern FunctionRNA rna_RenderEngine_update_script_node_func;
|
|
|
|
|
PointerRNA ptr, nodeptr;
|
|
|
|
|
ParameterList list;
|
|
|
|
|
FunctionRNA *func;
|
|
|
|
|
|
2020-04-03 18:24:08 +02:00
|
|
|
RNA_pointer_create(NULL, engine->type->rna_ext.srna, engine, &ptr);
|
2012-12-30 15:16:08 +00:00
|
|
|
RNA_pointer_create((ID *)ntree, &RNA_Node, node, &nodeptr);
|
2012-11-03 14:32:26 +00:00
|
|
|
func = &rna_RenderEngine_update_script_node_func;
|
|
|
|
|
|
|
|
|
|
RNA_parameter_list_create(&list, &ptr, func);
|
|
|
|
|
RNA_parameter_set_lookup(&list, "node", &nodeptr);
|
2020-04-03 18:24:08 +02:00
|
|
|
engine->type->rna_ext.call(NULL, &ptr, func, &list);
|
2012-11-03 14:32:26 +00:00
|
|
|
|
|
|
|
|
RNA_parameter_list_free(&list);
|
|
|
|
|
}
|
|
|
|
|
|
2017-11-22 10:52:39 -02:00
|
|
|
static void engine_update_render_passes(RenderEngine *engine,
|
|
|
|
|
struct Scene *scene,
|
|
|
|
|
struct ViewLayer *view_layer)
|
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
|
|
|
{
|
|
|
|
|
extern FunctionRNA rna_RenderEngine_update_render_passes_func;
|
|
|
|
|
PointerRNA ptr;
|
|
|
|
|
ParameterList list;
|
|
|
|
|
FunctionRNA *func;
|
|
|
|
|
|
2020-04-03 18:24:08 +02:00
|
|
|
RNA_pointer_create(NULL, engine->type->rna_ext.srna, engine, &ptr);
|
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
|
|
|
func = &rna_RenderEngine_update_render_passes_func;
|
|
|
|
|
|
|
|
|
|
RNA_parameter_list_create(&list, &ptr, func);
|
|
|
|
|
RNA_parameter_set_lookup(&list, "scene", &scene);
|
2017-11-22 10:52:39 -02:00
|
|
|
RNA_parameter_set_lookup(&list, "renderlayer", &view_layer);
|
2020-04-03 18:24:08 +02:00
|
|
|
engine->type->rna_ext.call(NULL, &ptr, func, &list);
|
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
|
|
|
|
|
|
|
|
RNA_parameter_list_free(&list);
|
|
|
|
|
}
|
|
|
|
|
|
2011-05-17 14:26:45 +00:00
|
|
|
/* RenderEngine registration */
|
|
|
|
|
|
2017-09-18 03:36:39 +02:00
|
|
|
static void rna_RenderEngine_unregister(Main *bmain, StructRNA *type)
|
2009-07-21 20:28:32 +00:00
|
|
|
{
|
2012-03-05 23:30:41 +00:00
|
|
|
RenderEngineType *et = RNA_struct_blender_type_get(type);
|
2009-07-21 20:28:32 +00:00
|
|
|
|
2019-06-04 00:21:57 +10:00
|
|
|
if (!et) {
|
2009-07-21 20:28:32 +00:00
|
|
|
return;
|
2019-06-04 00:21:57 +10:00
|
|
|
}
|
2018-06-09 14:40:09 +02:00
|
|
|
|
2020-11-09 18:37:29 +01:00
|
|
|
RE_FreeAllPersistentData();
|
2020-04-03 18:24:08 +02:00
|
|
|
RNA_struct_free_extension(type, &et->rna_ext);
|
2009-07-21 20:28:32 +00:00
|
|
|
RNA_struct_free(&BLENDER_RNA, type);
|
2017-08-11 19:09:03 +10:00
|
|
|
BLI_freelinkN(&R_engines, et);
|
2017-09-18 03:36:39 +02:00
|
|
|
|
|
|
|
|
/* Stop all renders in case we were using this one. */
|
2020-06-26 16:12:47 +02:00
|
|
|
ED_render_engine_changed(bmain, false);
|
2009-07-21 20:28:32 +00:00
|
|
|
}
|
|
|
|
|
|
2017-09-13 21:52:57 +10:00
|
|
|
static StructRNA *rna_RenderEngine_register(Main *bmain,
|
|
|
|
|
ReportList *reports,
|
|
|
|
|
void *data,
|
|
|
|
|
const char *identifier,
|
|
|
|
|
StructValidateFunc validate,
|
|
|
|
|
StructCallbackFunc call,
|
|
|
|
|
StructFreeFunc free)
|
2009-07-21 20:28:32 +00:00
|
|
|
{
|
2011-03-03 17:58:06 +00:00
|
|
|
RenderEngineType *et, dummyet = {NULL};
|
2012-03-05 23:30:41 +00:00
|
|
|
RenderEngine dummyengine = {NULL};
|
2009-07-21 20:28:32 +00:00
|
|
|
PointerRNA dummyptr;
|
2017-05-03 18:33:02 +02:00
|
|
|
int have_function[8];
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-21 20:28:32 +00:00
|
|
|
/* setup dummy engine & engine type to store static properties in */
|
2012-03-05 23:30:41 +00:00
|
|
|
dummyengine.type = &dummyet;
|
2015-05-06 23:50:54 +10:00
|
|
|
dummyet.flag |= RE_USE_SHADING_NODES_CUSTOM;
|
2009-07-21 20:28:32 +00:00
|
|
|
RNA_pointer_create(NULL, &RNA_RenderEngine, &dummyengine, &dummyptr);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-21 20:28:32 +00:00
|
|
|
/* validate the python class */
|
2019-06-04 00:21:57 +10:00
|
|
|
if (validate(&dummyptr, data, have_function) != 0) {
|
2009-07-21 20:28:32 +00:00
|
|
|
return NULL;
|
2019-06-04 00:21:57 +10:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
if (strlen(identifier) >= sizeof(dummyet.idname)) {
|
2012-10-20 10:28:34 +00:00
|
|
|
BKE_reportf(reports,
|
|
|
|
|
RPT_ERROR,
|
|
|
|
|
"Registering render engine class: '%s' is too long, maximum length is %d",
|
2012-03-18 09:27:36 +00:00
|
|
|
identifier,
|
|
|
|
|
(int)sizeof(dummyet.idname));
|
2009-12-22 10:04:15 +00:00
|
|
|
return NULL;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-21 20:28:32 +00:00
|
|
|
/* check if we have registered this engine type before, and remove it */
|
2012-03-05 23:30:41 +00:00
|
|
|
for (et = R_engines.first; et; et = et->next) {
|
2015-01-26 16:03:11 +01:00
|
|
|
if (STREQ(et->idname, dummyet.idname)) {
|
2020-04-03 18:24:08 +02:00
|
|
|
if (et->rna_ext.srna) {
|
|
|
|
|
rna_RenderEngine_unregister(bmain, et->rna_ext.srna);
|
2019-06-04 00:21:57 +10:00
|
|
|
}
|
2009-07-21 20:28:32 +00:00
|
|
|
break;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
}
|
|
|
|
|
|
2009-07-21 20:28:32 +00:00
|
|
|
/* create a new engine type */
|
2020-03-05 07:54:52 +11:00
|
|
|
et = MEM_mallocN(sizeof(RenderEngineType), "python render engine");
|
2009-07-21 20:28:32 +00:00
|
|
|
memcpy(et, &dummyet, sizeof(dummyet));
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-04-03 18:24:08 +02:00
|
|
|
et->rna_ext.srna = RNA_def_struct_ptr(&BLENDER_RNA, et->idname, &RNA_RenderEngine);
|
|
|
|
|
et->rna_ext.data = data;
|
|
|
|
|
et->rna_ext.call = call;
|
|
|
|
|
et->rna_ext.free = free;
|
|
|
|
|
RNA_struct_blender_type_set(et->rna_ext.srna, et);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-05-12 11:01:29 +00:00
|
|
|
et->update = (have_function[0]) ? engine_update : NULL;
|
2018-05-30 14:32:47 +02:00
|
|
|
et->render = (have_function[1]) ? engine_render : 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
|
|
|
et->bake = (have_function[2]) ? engine_bake : NULL;
|
|
|
|
|
et->view_update = (have_function[3]) ? engine_view_update : NULL;
|
2018-05-30 14:32:47 +02:00
|
|
|
et->view_draw = (have_function[4]) ? engine_view_draw : 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
|
|
|
et->update_script_node = (have_function[5]) ? engine_update_script_node : 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
|
|
|
et->update_render_passes = (have_function[6]) ? engine_update_render_passes : NULL;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-16 21:40:05 +02:00
|
|
|
RE_engines_register(et);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-04-03 18:24:08 +02:00
|
|
|
return et->rna_ext.srna;
|
2009-07-21 20:28:32 +00:00
|
|
|
}
|
|
|
|
|
|
Blender modifications for Cycles integration.
Some notes about code status:
* The Blender modifications were fairly quickly put together, much more code
polish and work is needed to get this to a state where it can be committed
to trunk. Files created with this version may not work in future versions.
* Only simple path tracing is supported currently, but we intend to provide
finer control, and more options where it makes sense.
* For GPU rendering, only CUDA works currently. The intention is to have the
same kernel code compile for C++/OpenCL/CUDA, some more work is needed to
get OpenCL functional.
* There are two shading backends: GPU compatible and Open Shading Language.
Unfortunately, OSL only runs on the CPU currently, getting this to run on
the GPU would be a major undertaking, and is unlikely to be supported soon.
Additionally, it's not possible yet to write custom OSL shaders.
* There is some code for adaptive subdivision and displacement, but it's far
from finished. The intention is to eventually have a nice unified bump and
displacement system.
* The code currently has a number of fairly heavy dependencies: Boost,
OpenImageIO, GLEW, GLUT, and optionally OSL, Partio. This makes it difficult
to compile, we'll try to eliminate some, it may take a while before it
becomes easy to compile this.
2011-04-27 14:36:02 +00:00
|
|
|
static void **rna_RenderEngine_instance(PointerRNA *ptr)
|
|
|
|
|
{
|
|
|
|
|
RenderEngine *engine = ptr->data;
|
|
|
|
|
return &engine->py_instance;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-12 11:01:29 +00:00
|
|
|
static StructRNA *rna_RenderEngine_refine(PointerRNA *ptr)
|
2009-07-21 20:28:32 +00:00
|
|
|
{
|
2012-05-12 11:01:29 +00:00
|
|
|
RenderEngine *engine = (RenderEngine *)ptr->data;
|
2020-04-03 18:24:08 +02:00
|
|
|
return (engine->type && engine->type->rna_ext.srna) ? engine->type->rna_ext.srna :
|
|
|
|
|
&RNA_RenderEngine;
|
2009-07-21 20:28:32 +00:00
|
|
|
}
|
|
|
|
|
|
2013-03-14 07:38:37 +00:00
|
|
|
static PointerRNA rna_RenderEngine_render_get(PointerRNA *ptr)
|
|
|
|
|
{
|
|
|
|
|
RenderEngine *engine = (RenderEngine *)ptr->data;
|
|
|
|
|
|
|
|
|
|
if (engine->re) {
|
|
|
|
|
RenderData *r = RE_engine_get_render_data(engine->re);
|
|
|
|
|
|
|
|
|
|
return rna_pointer_inherit_refine(ptr, &RNA_RenderSettings, r);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
return rna_pointer_inherit_refine(ptr, &RNA_RenderSettings, NULL);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
static PointerRNA rna_RenderEngine_camera_override_get(PointerRNA *ptr)
|
2009-07-21 14:11:51 +00:00
|
|
|
{
|
2015-04-06 10:40:12 -03:00
|
|
|
RenderEngine *engine = (RenderEngine *)ptr->data;
|
2018-05-23 12:13:21 +02:00
|
|
|
/* TODO(sergey): Shouldn't engine point to an evaluated datablocks already? */
|
2015-04-06 10:40:12 -03:00
|
|
|
if (engine->re) {
|
|
|
|
|
Object *cam = RE_GetCamera(engine->re);
|
2018-05-23 12:13:21 +02:00
|
|
|
Object *cam_eval = DEG_get_evaluated_object(engine->depsgraph, cam);
|
|
|
|
|
return rna_pointer_inherit_refine(ptr, &RNA_Object, cam_eval);
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
return rna_pointer_inherit_refine(ptr, &RNA_Object, engine->camera_override);
|
|
|
|
|
}
|
2009-07-21 14:11:51 +00:00
|
|
|
}
|
|
|
|
|
|
2020-07-20 17:23:18 +02:00
|
|
|
static void rna_RenderEngine_engine_frame_set(RenderEngine *engine, int frame, float subframe)
|
|
|
|
|
{
|
|
|
|
|
# ifdef WITH_PYTHON
|
|
|
|
|
BPy_BEGIN_ALLOW_THREADS;
|
|
|
|
|
# endif
|
|
|
|
|
|
|
|
|
|
RE_engine_frame_set(engine, frame, subframe);
|
|
|
|
|
|
|
|
|
|
# ifdef WITH_PYTHON
|
|
|
|
|
BPy_END_ALLOW_THREADS;
|
|
|
|
|
# endif
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
static void rna_RenderResult_views_begin(CollectionPropertyIterator *iter, PointerRNA *ptr)
|
2009-07-21 14:11:51 +00:00
|
|
|
{
|
2015-04-06 10:40:12 -03:00
|
|
|
RenderResult *rr = (RenderResult *)ptr->data;
|
|
|
|
|
rna_iterator_listbase_begin(iter, &rr->views, NULL);
|
2009-07-21 14:11:51 +00:00
|
|
|
}
|
|
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
static void rna_RenderResult_layers_begin(CollectionPropertyIterator *iter, PointerRNA *ptr)
|
2009-07-21 14:11:51 +00:00
|
|
|
{
|
2015-04-06 10:40:12 -03:00
|
|
|
RenderResult *rr = (RenderResult *)ptr->data;
|
|
|
|
|
rna_iterator_listbase_begin(iter, &rr->layers, NULL);
|
2009-07-21 14:11:51 +00:00
|
|
|
}
|
|
|
|
|
|
2017-02-06 17:23:02 +01:00
|
|
|
static void rna_RenderResult_stamp_data_add_field(RenderResult *rr,
|
|
|
|
|
const char *field,
|
|
|
|
|
const char *value)
|
|
|
|
|
{
|
|
|
|
|
BKE_render_result_stamp_data(rr, field, value);
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
static void rna_RenderLayer_passes_begin(CollectionPropertyIterator *iter, PointerRNA *ptr)
|
2009-07-21 14:11:51 +00:00
|
|
|
{
|
2012-05-12 11:01:29 +00:00
|
|
|
RenderLayer *rl = (RenderLayer *)ptr->data;
|
2015-04-06 10:40:12 -03:00
|
|
|
rna_iterator_listbase_begin(iter, &rl->passes, NULL);
|
2009-07-21 14:11:51 +00:00
|
|
|
}
|
|
|
|
|
|
2009-09-09 19:40:46 +00:00
|
|
|
static int rna_RenderPass_rect_get_length(PointerRNA *ptr, int length[RNA_MAX_ARRAY_DIMENSION])
|
2009-07-21 14:11:51 +00:00
|
|
|
{
|
2012-05-12 11:01:29 +00:00
|
|
|
RenderPass *rpass = (RenderPass *)ptr->data;
|
2009-09-09 19:40:46 +00:00
|
|
|
|
2012-05-12 11:01:29 +00:00
|
|
|
length[0] = rpass->rectx * rpass->recty;
|
2012-03-05 23:30:41 +00:00
|
|
|
length[1] = rpass->channels;
|
2009-09-09 19:40:46 +00:00
|
|
|
|
2012-05-12 11:01:29 +00:00
|
|
|
return length[0] * length[1];
|
2009-07-21 14:11:51 +00:00
|
|
|
}
|
|
|
|
|
|
2009-09-09 19:40:46 +00:00
|
|
|
static void rna_RenderPass_rect_get(PointerRNA *ptr, float *values)
|
2009-07-21 14:11:51 +00:00
|
|
|
{
|
2012-05-12 11:01:29 +00:00
|
|
|
RenderPass *rpass = (RenderPass *)ptr->data;
|
|
|
|
|
memcpy(values, rpass->rect, sizeof(float) * rpass->rectx * rpass->recty * rpass->channels);
|
2009-07-21 14:11:51 +00:00
|
|
|
}
|
|
|
|
|
|
2012-09-22 17:00:02 +00:00
|
|
|
void rna_RenderPass_rect_set(PointerRNA *ptr, const float *values)
|
2009-09-09 19:40:46 +00:00
|
|
|
{
|
2012-05-12 11:01:29 +00:00
|
|
|
RenderPass *rpass = (RenderPass *)ptr->data;
|
|
|
|
|
memcpy(rpass->rect, values, sizeof(float) * rpass->rectx * rpass->recty * rpass->channels);
|
2009-09-09 19:40:46 +00:00
|
|
|
}
|
2009-07-21 14:11:51 +00:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
static RenderPass *rna_RenderPass_find_by_type(RenderLayer *rl, int passtype, const char *view)
|
|
|
|
|
{
|
2015-04-17 09:48:31 -03:00
|
|
|
return RE_pass_find_by_type(rl, passtype, view);
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
|
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
static RenderPass *rna_RenderPass_find_by_name(RenderLayer *rl, const char *name, const char *view)
|
|
|
|
|
{
|
|
|
|
|
return RE_pass_find_by_name(rl, name, view);
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
#else /* RNA_RUNTIME */
|
2009-07-21 14:11:51 +00:00
|
|
|
|
2009-07-21 20:28:32 +00:00
|
|
|
static void rna_def_render_engine(BlenderRNA *brna)
|
|
|
|
|
{
|
|
|
|
|
StructRNA *srna;
|
|
|
|
|
PropertyRNA *prop;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-21 20:28:32 +00:00
|
|
|
FunctionRNA *func;
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
PropertyRNA *parm;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-10-18 15:07:26 +11:00
|
|
|
static const EnumPropertyItem render_pass_type_items[] = {
|
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
|
|
|
{SOCK_FLOAT, "VALUE", 0, "Value", ""},
|
|
|
|
|
{SOCK_VECTOR, "VECTOR", 0, "Vector", ""},
|
|
|
|
|
{SOCK_RGBA, "COLOR", 0, "Color", ""},
|
2019-02-03 14:01:45 +11:00
|
|
|
{0, NULL, 0, NULL, 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
|
|
|
};
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
srna = RNA_def_struct(brna, "RenderEngine", NULL);
|
2009-07-21 20:28:32 +00:00
|
|
|
RNA_def_struct_sdna(srna, "RenderEngine");
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_struct_ui_text(srna, "Render Engine", "Render engine");
|
2009-07-21 20:28:32 +00:00
|
|
|
RNA_def_struct_refine_func(srna, "rna_RenderEngine_refine");
|
2012-03-18 09:27:36 +00:00
|
|
|
RNA_def_struct_register_funcs(srna,
|
|
|
|
|
"rna_RenderEngine_register",
|
|
|
|
|
"rna_RenderEngine_unregister",
|
|
|
|
|
"rna_RenderEngine_instance");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-05-17 14:26:45 +00:00
|
|
|
/* final render callbacks */
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "update", NULL);
|
2011-05-17 14:26:45 +00:00
|
|
|
RNA_def_function_ui_description(func, "Export scene data for render");
|
2013-02-28 15:33:26 +00:00
|
|
|
RNA_def_function_flag(func, FUNC_REGISTER_OPTIONAL | FUNC_ALLOW_WRITE);
|
2011-05-17 14:26:45 +00:00
|
|
|
RNA_def_pointer(func, "data", "BlendData", "", "");
|
2018-05-23 12:13:21 +02:00
|
|
|
RNA_def_pointer(func, "depsgraph", "Depsgraph", "", "");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-05-30 14:32:47 +02:00
|
|
|
func = RNA_def_function(srna, "render", NULL);
|
2011-11-02 15:15:45 +00:00
|
|
|
RNA_def_function_ui_description(func, "Render scene into an image");
|
2013-02-28 15:33:26 +00:00
|
|
|
RNA_def_function_flag(func, FUNC_REGISTER_OPTIONAL | FUNC_ALLOW_WRITE);
|
2018-02-26 16:46:48 +01:00
|
|
|
parm = RNA_def_pointer(func, "depsgraph", "Depsgraph", "", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +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
|
|
|
func = RNA_def_function(srna, "bake", NULL);
|
|
|
|
|
RNA_def_function_ui_description(func, "Bake passes");
|
|
|
|
|
RNA_def_function_flag(func, FUNC_REGISTER_OPTIONAL | FUNC_ALLOW_WRITE);
|
2018-02-26 16:46:48 +01:00
|
|
|
parm = RNA_def_pointer(func, "depsgraph", "Depsgraph", "", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_pointer(func, "object", "Object", "", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_enum(func, "pass_type", rna_enum_bake_pass_type_items, 0, "Pass", "Pass to bake");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_int(func,
|
|
|
|
|
"pass_filter",
|
|
|
|
|
0,
|
|
|
|
|
0,
|
|
|
|
|
INT_MAX,
|
|
|
|
|
"Pass Filter",
|
2020-02-14 12:20:12 +01:00
|
|
|
"Filter to combined, diffuse, glossy and transmission passes",
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
0,
|
|
|
|
|
INT_MAX);
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
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
|
|
|
parm = RNA_def_int(func, "width", 0, 0, INT_MAX, "Width", "Image width", 0, INT_MAX);
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
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
|
|
|
parm = RNA_def_int(func, "height", 0, 0, INT_MAX, "Height", "Image height", 0, INT_MAX);
|
2018-05-30 14:32:47 +02:00
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-05-17 14:26:45 +00:00
|
|
|
/* viewport render callbacks */
|
2018-05-30 14:32:47 +02:00
|
|
|
func = RNA_def_function(srna, "view_update", NULL);
|
2011-05-17 14:26:45 +00:00
|
|
|
RNA_def_function_ui_description(func, "Update on data changes for viewport render");
|
2011-11-02 15:15:45 +00:00
|
|
|
RNA_def_function_flag(func, FUNC_REGISTER_OPTIONAL | FUNC_ALLOW_WRITE);
|
2019-05-16 17:19:05 +02:00
|
|
|
parm = RNA_def_pointer(func, "context", "Context", "", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_pointer(func, "depsgraph", "Depsgraph", "", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-11-02 15:15:45 +00:00
|
|
|
func = RNA_def_function(srna, "view_draw", NULL);
|
2011-05-17 14:26:45 +00:00
|
|
|
RNA_def_function_ui_description(func, "Draw viewport render");
|
2013-02-28 15:33:26 +00:00
|
|
|
RNA_def_function_flag(func, FUNC_REGISTER_OPTIONAL);
|
2019-05-16 17:19:05 +02:00
|
|
|
parm = RNA_def_pointer(func, "context", "Context", "", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_pointer(func, "depsgraph", "Depsgraph", "", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-03 14:32:26 +00:00
|
|
|
/* shader script callbacks */
|
|
|
|
|
func = RNA_def_function(srna, "update_script_node", NULL);
|
|
|
|
|
RNA_def_function_ui_description(func, "Compile shader script node");
|
|
|
|
|
RNA_def_function_flag(func, FUNC_REGISTER_OPTIONAL | FUNC_ALLOW_WRITE);
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_pointer(func, "node", "Node", "", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_RNAPTR);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-05-03 18:33:02 +02:00
|
|
|
func = RNA_def_function(srna, "update_render_passes", NULL);
|
|
|
|
|
RNA_def_function_ui_description(func, "Update the render passes that will be generated");
|
|
|
|
|
RNA_def_function_flag(func, FUNC_REGISTER_OPTIONAL | FUNC_ALLOW_WRITE);
|
|
|
|
|
parm = RNA_def_pointer(func, "scene", "Scene", "", "");
|
2017-11-22 10:52:39 -02:00
|
|
|
parm = RNA_def_pointer(func, "renderlayer", "ViewLayer", "", "");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Blender modifications for Cycles integration.
Some notes about code status:
* The Blender modifications were fairly quickly put together, much more code
polish and work is needed to get this to a state where it can be committed
to trunk. Files created with this version may not work in future versions.
* Only simple path tracing is supported currently, but we intend to provide
finer control, and more options where it makes sense.
* For GPU rendering, only CUDA works currently. The intention is to have the
same kernel code compile for C++/OpenCL/CUDA, some more work is needed to
get OpenCL functional.
* There are two shading backends: GPU compatible and Open Shading Language.
Unfortunately, OSL only runs on the CPU currently, getting this to run on
the GPU would be a major undertaking, and is unlikely to be supported soon.
Additionally, it's not possible yet to write custom OSL shaders.
* There is some code for adaptive subdivision and displacement, but it's far
from finished. The intention is to eventually have a nice unified bump and
displacement system.
* The code currently has a number of fairly heavy dependencies: Boost,
OpenImageIO, GLEW, GLUT, and optionally OSL, Partio. This makes it difficult
to compile, we'll try to eliminate some, it may take a while before it
becomes easy to compile this.
2011-04-27 14:36:02 +00:00
|
|
|
/* tag for redraw */
|
2013-08-30 23:49:35 +00:00
|
|
|
func = RNA_def_function(srna, "tag_redraw", "engine_tag_redraw");
|
2011-11-02 15:15:45 +00:00
|
|
|
RNA_def_function_ui_description(func, "Request redraw for viewport rendering");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Blender modifications for Cycles integration.
Some notes about code status:
* The Blender modifications were fairly quickly put together, much more code
polish and work is needed to get this to a state where it can be committed
to trunk. Files created with this version may not work in future versions.
* Only simple path tracing is supported currently, but we intend to provide
finer control, and more options where it makes sense.
* For GPU rendering, only CUDA works currently. The intention is to have the
same kernel code compile for C++/OpenCL/CUDA, some more work is needed to
get OpenCL functional.
* There are two shading backends: GPU compatible and Open Shading Language.
Unfortunately, OSL only runs on the CPU currently, getting this to run on
the GPU would be a major undertaking, and is unlikely to be supported soon.
Additionally, it's not possible yet to write custom OSL shaders.
* There is some code for adaptive subdivision and displacement, but it's far
from finished. The intention is to eventually have a nice unified bump and
displacement system.
* The code currently has a number of fairly heavy dependencies: Boost,
OpenImageIO, GLEW, GLUT, and optionally OSL, Partio. This makes it difficult
to compile, we'll try to eliminate some, it may take a while before it
becomes easy to compile this.
2011-04-27 14:36:02 +00:00
|
|
|
/* tag for update */
|
2013-08-30 23:49:35 +00:00
|
|
|
func = RNA_def_function(srna, "tag_update", "engine_tag_update");
|
2011-11-02 15:15:45 +00:00
|
|
|
RNA_def_function_ui_description(func, "Request update call for viewport rendering");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "begin_result", "RE_engine_begin_result");
|
2013-08-30 23:49:35 +00:00
|
|
|
RNA_def_function_ui_description(
|
2020-12-24 13:11:22 -06:00
|
|
|
func, "Create render result to write linear floating-point render layers and passes");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_int(func, "x", 0, 0, INT_MAX, "X", "", 0, INT_MAX);
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_int(func, "y", 0, 0, INT_MAX, "Y", "", 0, INT_MAX);
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_int(func, "w", 0, 0, INT_MAX, "Width", "", 0, INT_MAX);
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_int(func, "h", 0, 0, INT_MAX, "Height", "", 0, INT_MAX);
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2014-01-16 21:43:22 +11:00
|
|
|
RNA_def_string(
|
|
|
|
|
func, "layer", NULL, 0, "Layer", "Single layer to get render result for"); /* NULL ok here */
|
2015-04-06 10:40:12 -03:00
|
|
|
RNA_def_string(
|
|
|
|
|
func, "view", NULL, 0, "View", "Single view to get render result for"); /* NULL ok here */
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_pointer(func, "result", "RenderResult", "Result", "");
|
|
|
|
|
RNA_def_function_return(func, parm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "update_result", "RE_engine_update_result");
|
2013-08-30 23:49:35 +00:00
|
|
|
RNA_def_function_ui_description(
|
|
|
|
|
func, "Signal that pixels have been updated and can be redrawn in the user interface");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_pointer(func, "result", "RenderResult", "Result", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "end_result", "RE_engine_end_result");
|
2013-08-30 23:49:35 +00:00
|
|
|
RNA_def_function_ui_description(func,
|
|
|
|
|
"All pixels in the render result have been set and are final");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_pointer(func, "result", "RenderResult", "Result", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2013-12-17 23:42:38 +06:00
|
|
|
RNA_def_boolean(
|
|
|
|
|
func, "cancel", 0, "Cancel", "Don't mark tile as done, don't merge results unless forced");
|
2017-05-07 14:40:58 +02:00
|
|
|
RNA_def_boolean(func, "highlight", 0, "Highlight", "Don't mark tile as done yet");
|
2013-12-17 23:42:38 +06:00
|
|
|
RNA_def_boolean(
|
|
|
|
|
func, "do_merge_results", 0, "Merge Results", "Merge results even if cancel=true");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
func = RNA_def_function(srna, "add_pass", "RE_engine_add_pass");
|
|
|
|
|
RNA_def_function_ui_description(func, "Add a pass to the render layer");
|
|
|
|
|
parm = RNA_def_string(
|
|
|
|
|
func, "name", NULL, 0, "Name", "Name of the Pass, without view or channel tag");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_int(func, "channels", 0, 0, INT_MAX, "Channels", "", 0, INT_MAX);
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_string(
|
|
|
|
|
func, "chan_id", NULL, 0, "Channel IDs", "Channel names, one character per channel");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
RNA_def_string(
|
|
|
|
|
func, "layer", NULL, 0, "Layer", "Single layer to add render pass to"); /* NULL ok here */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-02-06 17:23:02 +01:00
|
|
|
func = RNA_def_function(srna, "get_result", "RE_engine_get_result");
|
|
|
|
|
RNA_def_function_ui_description(func, "Get final result for non-pixel operations");
|
|
|
|
|
parm = RNA_def_pointer(func, "result", "RenderResult", "Result", "");
|
|
|
|
|
RNA_def_function_return(func, parm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "test_break", "RE_engine_test_break");
|
2013-10-26 01:06:19 +00:00
|
|
|
RNA_def_function_ui_description(func,
|
|
|
|
|
"Test if the render operation should been canceled, this is a "
|
|
|
|
|
"fast call that should be used regularly for responsiveness");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_boolean(func, "do_break", 0, "Break", "");
|
|
|
|
|
RNA_def_function_return(func, parm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
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
|
|
|
func = RNA_def_function(srna, "active_view_get", "RE_engine_active_view_get");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_string(func, "view", NULL, 0, "View", "Single view active");
|
|
|
|
|
RNA_def_function_return(func, parm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
func = RNA_def_function(srna, "active_view_set", "RE_engine_active_view_set");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_string(
|
|
|
|
|
func, "view", NULL, 0, "View", "Single view to set as active"); /* NULL ok here */
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
func = RNA_def_function(srna, "camera_shift_x", "RE_engine_get_camera_shift_x");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_pointer(func, "camera", "Object", "", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
RNA_def_boolean(func, "use_spherical_stereo", 0, "Spherical Stereo", "");
|
|
|
|
|
parm = RNA_def_float(func, "shift_x", 0.0f, 0.0f, FLT_MAX, "Shift X", "", 0.0f, FLT_MAX);
|
|
|
|
|
RNA_def_function_return(func, parm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
func = RNA_def_function(srna, "camera_model_matrix", "RE_engine_get_camera_model_matrix");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_pointer(func, "camera", "Object", "", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
RNA_def_boolean(func, "use_spherical_stereo", 0, "Spherical Stereo", "");
|
|
|
|
|
parm = RNA_def_float_matrix(func,
|
|
|
|
|
"r_model_matrix",
|
|
|
|
|
4,
|
|
|
|
|
4,
|
|
|
|
|
NULL,
|
|
|
|
|
0.0f,
|
|
|
|
|
0.0f,
|
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
|
|
|
"Model Matrix",
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
"Normalized camera model matrix",
|
|
|
|
|
0.0f,
|
|
|
|
|
0.0f);
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
RNA_def_function_output(func, parm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
func = RNA_def_function(srna, "use_spherical_stereo", "RE_engine_get_spherical_stereo");
|
|
|
|
|
parm = RNA_def_pointer(func, "camera", "Object", "", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_boolean(func, "use_spherical_stereo", 0, "Spherical Stereo", "");
|
|
|
|
|
RNA_def_function_return(func, parm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
func = RNA_def_function(srna, "update_stats", "RE_engine_update_stats");
|
2013-08-30 23:49:35 +00:00
|
|
|
RNA_def_function_ui_description(func, "Update and signal to redraw render status text");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_string(func, "stats", NULL, 0, "Stats", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2018-11-08 01:05:55 +01:00
|
|
|
parm = RNA_def_string(func, "info", NULL, 0, "Info", "");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-07-20 17:23:18 +02:00
|
|
|
func = RNA_def_function(srna, "frame_set", "rna_RenderEngine_engine_frame_set");
|
2014-05-21 15:47:11 +02:00
|
|
|
RNA_def_function_ui_description(func, "Evaluate scene at a different frame (for motion blur)");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_int(func, "frame", 0, INT_MIN, INT_MAX, "Frame", "", INT_MIN, INT_MAX);
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_float(func, "subframe", 0.0f, 0.0f, 1.0f, "Subframe", "", 0.0f, 1.0f);
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "update_progress", "RE_engine_update_progress");
|
2013-08-30 23:49:35 +00:00
|
|
|
RNA_def_function_ui_description(func, "Update progress percentage of render");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_float(
|
|
|
|
|
func, "progress", 0, 0.0f, 1.0f, "", "Percentage of render that's done", 0.0f, 1.0f);
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-05 08:04:57 +00:00
|
|
|
func = RNA_def_function(srna, "update_memory_stats", "RE_engine_update_memory_stats");
|
2013-08-30 23:49:35 +00:00
|
|
|
RNA_def_function_ui_description(func, "Update memory usage statistics");
|
2012-11-05 08:04:57 +00:00
|
|
|
RNA_def_float(func,
|
|
|
|
|
"memory_used",
|
|
|
|
|
0,
|
|
|
|
|
0.0f,
|
2012-03-05 23:30:41 +00:00
|
|
|
FLT_MAX,
|
|
|
|
|
"",
|
2013-08-30 23:49:35 +00:00
|
|
|
"Current memory usage in megabytes",
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
0.0f,
|
|
|
|
|
FLT_MAX);
|
|
|
|
|
RNA_def_float(
|
|
|
|
|
func, "memory_peak", 0, 0.0f, FLT_MAX, "", "Peak memory usage in megabytes", 0.0f, FLT_MAX);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-12-05 21:56:29 +05:00
|
|
|
func = RNA_def_function(srna, "report", "RE_engine_report");
|
|
|
|
|
RNA_def_function_ui_description(func, "Report info, warning or error messages");
|
|
|
|
|
parm = RNA_def_enum_flag(func, "type", rna_enum_wm_report_items, 0, "Type", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_string(func, "message", NULL, 0, "Report Message", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-08-30 23:49:35 +00:00
|
|
|
func = RNA_def_function(srna, "error_set", "RE_engine_set_error_message");
|
|
|
|
|
RNA_def_function_ui_description(func,
|
|
|
|
|
"Set error message displaying after the render is finished");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_string(func, "message", NULL, 0, "Report Message", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-08-30 23:49:35 +00:00
|
|
|
func = RNA_def_function(srna, "bind_display_space_shader", "engine_bind_display_space_shader");
|
|
|
|
|
RNA_def_function_ui_description(func,
|
|
|
|
|
"Bind GLSL fragment shader that converts linear colors to "
|
|
|
|
|
"display space colors using scene color management settings");
|
2017-08-15 00:11:52 +02:00
|
|
|
parm = RNA_def_pointer(func, "scene", "Scene", "", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(
|
2017-08-15 00:11:52 +02:00
|
|
|
srna, "unbind_display_space_shader", "engine_unbind_display_space_shader");
|
2011-09-19 13:23:58 +00:00
|
|
|
RNA_def_function_ui_description(
|
2017-08-15 00:11:52 +02:00
|
|
|
func, "Unbind GLSL display space shader, must always be called after binding the shader");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(
|
2013-08-30 23:49:35 +00:00
|
|
|
srna, "support_display_space_shader", "engine_support_display_space_shader");
|
2011-09-19 13:23:58 +00:00
|
|
|
RNA_def_function_ui_description(func,
|
2013-08-30 23:49:35 +00:00
|
|
|
"Test if GLSL display space shader is supported for the "
|
|
|
|
|
"combination of graphics card and scene settings");
|
2017-08-15 00:11:52 +02:00
|
|
|
parm = RNA_def_pointer(func, "scene", "Scene", "", "");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2017-08-15 00:11:52 +02:00
|
|
|
parm = RNA_def_boolean(func, "supported", 0, "Supported", "");
|
|
|
|
|
RNA_def_function_return(func, parm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-11-09 16:14:15 +01:00
|
|
|
func = RNA_def_function(srna, "get_preview_pixel_size", "engine_get_preview_pixel_size");
|
|
|
|
|
RNA_def_function_ui_description(func,
|
|
|
|
|
"Get the pixel size that should be used for preview rendering");
|
2009-07-21 20:28:32 +00:00
|
|
|
parm = RNA_def_pointer(func, "scene", "Scene", "", "");
|
2012-03-05 23:30:41 +00:00
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_int(func, "pixel_size", 0, 1, 8, "Pixel Size", "", 1, 8);
|
|
|
|
|
RNA_def_function_return(func, parm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-11-24 10:41:01 +01:00
|
|
|
func = RNA_def_function(srna, "free_blender_memory", "RE_engine_free_blender_memory");
|
2012-03-05 23:30:41 +00:00
|
|
|
RNA_def_function_ui_description(func, "Free Blender side memory of render engine");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-11-02 15:15:45 +00:00
|
|
|
RNA_define_verify_sdna(0);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-04-15 13:41:07 +00:00
|
|
|
prop = RNA_def_property(srna, "is_animation", PROP_BOOLEAN, PROP_NONE);
|
2015-04-06 10:40:12 -03:00
|
|
|
RNA_def_property_boolean_sdna(prop, NULL, "flag", RE_ENGINE_ANIMATION);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-04-13 17:42:03 +00:00
|
|
|
prop = RNA_def_property(srna, "is_preview", PROP_BOOLEAN, PROP_NONE);
|
2014-07-04 16:32:17 +06:00
|
|
|
RNA_def_property_boolean_sdna(prop, NULL, "flag", RE_ENGINE_PREVIEW);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2014-07-04 16:32:17 +06:00
|
|
|
prop = RNA_def_property(srna, "camera_override", PROP_POINTER, PROP_NONE);
|
|
|
|
|
RNA_def_property_pointer_funcs(prop, "rna_RenderEngine_camera_override_get", NULL, NULL, NULL);
|
2012-09-04 13:29:07 +00:00
|
|
|
RNA_def_property_struct_type(prop, "Object");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-09-04 13:29:07 +00:00
|
|
|
prop = RNA_def_property(srna, "layer_override", PROP_BOOLEAN, PROP_LAYER_MEMBER);
|
|
|
|
|
RNA_def_property_boolean_sdna(prop, NULL, "layer_override", 1);
|
2013-12-13 04:39:15 +11:00
|
|
|
RNA_def_property_array(prop, 20);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-12-13 04:39:15 +11:00
|
|
|
prop = RNA_def_property(srna, "tile_x", PROP_INT, PROP_UNSIGNED);
|
2012-09-04 13:29:07 +00:00
|
|
|
RNA_def_property_int_sdna(prop, NULL, "tile_x");
|
|
|
|
|
prop = RNA_def_property(srna, "tile_y", PROP_INT, PROP_UNSIGNED);
|
|
|
|
|
RNA_def_property_int_sdna(prop, NULL, "tile_y");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-12-13 04:39:15 +11:00
|
|
|
prop = RNA_def_property(srna, "resolution_x", PROP_INT, PROP_PIXEL);
|
2012-09-04 13:29:07 +00:00
|
|
|
RNA_def_property_int_sdna(prop, NULL, "resolution_x");
|
|
|
|
|
RNA_def_property_clear_flag(prop, PROP_EDITABLE);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-03-14 07:38:37 +00:00
|
|
|
prop = RNA_def_property(srna, "resolution_y", PROP_INT, PROP_PIXEL);
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
RNA_def_property_int_sdna(prop, NULL, "resolution_y");
|
2013-03-14 07:38:37 +00:00
|
|
|
RNA_def_property_clear_flag(prop, PROP_EDITABLE);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
/* Render Data */
|
2013-03-14 07:38:37 +00:00
|
|
|
prop = RNA_def_property(srna, "render", PROP_POINTER, PROP_NONE);
|
|
|
|
|
RNA_def_property_struct_type(prop, "RenderSettings");
|
|
|
|
|
RNA_def_property_pointer_funcs(prop, "rna_RenderEngine_render_get", NULL, NULL, NULL);
|
|
|
|
|
RNA_def_property_ui_text(prop, "Render Data", "");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-01-01 16:15:13 +00:00
|
|
|
prop = RNA_def_property(srna, "use_highlight_tiles", PROP_BOOLEAN, PROP_NONE);
|
|
|
|
|
RNA_def_property_boolean_sdna(prop, NULL, "flag", RE_ENGINE_HIGHLIGHT_TILES);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
func = RNA_def_function(srna, "register_pass", "RE_engine_register_pass");
|
|
|
|
|
RNA_def_function_ui_description(
|
|
|
|
|
func, "Register a render pass that will be part of the render with the current settings");
|
2018-09-03 17:16:17 +02:00
|
|
|
parm = RNA_def_pointer(func, "scene", "Scene", "", "");
|
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
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2018-09-03 17:16:17 +02:00
|
|
|
parm = RNA_def_pointer(func, "view_layer", "ViewLayer", "", "");
|
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
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2018-09-03 17:16:17 +02:00
|
|
|
parm = RNA_def_string(func, "name", NULL, MAX_NAME, "Name", "");
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2018-09-03 17:16:17 +02:00
|
|
|
parm = RNA_def_int(func, "channels", 1, 1, 8, "Channels", "", 1, 4);
|
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
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2018-09-03 17:16:17 +02:00
|
|
|
parm = RNA_def_string(func, "chanid", NULL, 8, "Channel IDs", "");
|
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
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2018-09-03 17:16:17 +02:00
|
|
|
parm = RNA_def_enum(func, "type", render_pass_type_items, SOCK_FLOAT, "Type", "");
|
2020-03-17 13:45:35 -06:00
|
|
|
RNA_def_property_enum_native_type(parm, "eNodeSocketDatatype");
|
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
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-11-02 15:15:45 +00:00
|
|
|
/* registration */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "bl_idname", PROP_STRING, PROP_NONE);
|
2009-07-21 20:28:32 +00:00
|
|
|
RNA_def_property_string_sdna(prop, NULL, "type->idname");
|
2014-02-09 05:51:22 +11:00
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-01-05 13:52:41 +00:00
|
|
|
prop = RNA_def_property(srna, "bl_label", PROP_STRING, PROP_NONE);
|
2009-07-21 20:28:32 +00:00
|
|
|
RNA_def_property_string_sdna(prop, NULL, "type->name");
|
|
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "bl_use_preview", PROP_BOOLEAN, PROP_NONE);
|
2011-10-11 17:19:55 +00:00
|
|
|
RNA_def_property_boolean_sdna(prop, NULL, "type->flag", RE_USE_PREVIEW);
|
2010-03-28 13:48:11 +00:00
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER_OPTIONAL);
|
2019-06-06 14:36:40 +02:00
|
|
|
RNA_def_property_ui_text(
|
|
|
|
|
prop,
|
|
|
|
|
"Use Preview Render",
|
|
|
|
|
"Render engine supports being used for rendering previews of materials, lights and worlds");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "bl_use_postprocess", PROP_BOOLEAN, PROP_NONE);
|
2011-10-11 17:19:55 +00:00
|
|
|
RNA_def_property_boolean_negative_sdna(prop, NULL, "type->flag", RE_USE_POSTPROCESS);
|
|
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER_OPTIONAL);
|
2019-06-06 14:36:40 +02:00
|
|
|
RNA_def_property_ui_text(prop, "Use Post Processing", "Apply compositing on render results");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2019-06-06 14:36:40 +02:00
|
|
|
prop = RNA_def_property(srna, "bl_use_eevee_viewport", PROP_BOOLEAN, PROP_NONE);
|
|
|
|
|
RNA_def_property_boolean_sdna(prop, NULL, "type->flag", RE_USE_EEVEE_VIEWPORT);
|
2010-03-28 14:45:09 +00:00
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER_OPTIONAL);
|
2019-06-06 14:36:40 +02:00
|
|
|
RNA_def_property_ui_text(
|
|
|
|
|
prop, "Use Eevee Viewport", "Uses Eevee for viewport shading in LookDev shading mode");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-07-20 13:56:29 +02:00
|
|
|
prop = RNA_def_property(srna, "bl_use_gpu_context", PROP_BOOLEAN, PROP_NONE);
|
|
|
|
|
RNA_def_property_boolean_sdna(prop, NULL, "type->flag", RE_USE_GPU_CONTEXT);
|
|
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER_OPTIONAL);
|
|
|
|
|
RNA_def_property_ui_text(
|
|
|
|
|
prop,
|
|
|
|
|
"Use GPU Context",
|
|
|
|
|
"Enable OpenGL context for the render method, for engines that render using OpenGL");
|
|
|
|
|
|
2015-05-06 23:50:54 +10:00
|
|
|
prop = RNA_def_property(srna, "bl_use_shading_nodes_custom", PROP_BOOLEAN, PROP_NONE);
|
|
|
|
|
RNA_def_property_boolean_sdna(prop, NULL, "type->flag", RE_USE_SHADING_NODES_CUSTOM);
|
|
|
|
|
RNA_def_property_boolean_default(prop, true);
|
|
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER_OPTIONAL);
|
2019-06-06 14:36:40 +02:00
|
|
|
RNA_def_property_ui_text(prop,
|
|
|
|
|
"Use Custom Shading Nodes",
|
|
|
|
|
"Don't expose Cycles and Eevee shading nodes in the node editor user "
|
|
|
|
|
"interface, so own nodes can be used instead");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-07-11 12:22:29 +00:00
|
|
|
prop = RNA_def_property(srna, "bl_use_save_buffers", PROP_BOOLEAN, PROP_NONE);
|
|
|
|
|
RNA_def_property_boolean_sdna(prop, NULL, "type->flag", RE_USE_SAVE_BUFFERS);
|
|
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER_OPTIONAL);
|
2019-06-06 14:36:40 +02:00
|
|
|
RNA_def_property_ui_text(
|
|
|
|
|
prop, "Use Save Buffers", "Support render to an on disk buffer during rendering");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
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
|
|
|
prop = RNA_def_property(srna, "bl_use_spherical_stereo", PROP_BOOLEAN, PROP_NONE);
|
|
|
|
|
RNA_def_property_boolean_sdna(prop, NULL, "type->flag", RE_USE_SPHERICAL_STEREO);
|
|
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER_OPTIONAL);
|
2019-06-06 14:36:40 +02:00
|
|
|
RNA_def_property_ui_text(prop, "Use Spherical Stereo", "Support spherical stereo camera models");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-03-20 16:05:55 +01:00
|
|
|
prop = RNA_def_property(srna, "bl_use_stereo_viewport", PROP_BOOLEAN, PROP_NONE);
|
|
|
|
|
RNA_def_property_boolean_sdna(prop, NULL, "type->flag", RE_USE_STEREO_VIEWPORT);
|
|
|
|
|
RNA_def_property_flag(prop, PROP_REGISTER_OPTIONAL);
|
|
|
|
|
RNA_def_property_ui_text(prop, "Use Stereo Viewport", "Support rendering stereo 3D viewport");
|
|
|
|
|
|
2009-07-21 20:28:32 +00:00
|
|
|
RNA_define_verify_sdna(1);
|
|
|
|
|
}
|
|
|
|
|
|
2009-07-21 14:11:51 +00:00
|
|
|
static void rna_def_render_result(BlenderRNA *brna)
|
|
|
|
|
{
|
|
|
|
|
StructRNA *srna;
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
PropertyRNA *prop;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-08-16 22:53:15 +00:00
|
|
|
FunctionRNA *func;
|
2010-08-28 12:34:22 +00:00
|
|
|
PropertyRNA *parm;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
srna = RNA_def_struct(brna, "RenderResult", NULL);
|
2010-02-10 21:15:44 +00:00
|
|
|
RNA_def_struct_ui_text(
|
|
|
|
|
srna, "Render Result", "Result of rendering, including all layers and passes");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "load_from_file", "RE_result_load_from_file");
|
2011-09-19 13:23:58 +00:00
|
|
|
RNA_def_function_ui_description(func,
|
|
|
|
|
"Copies the pixels of this render result from an image file");
|
2009-08-16 22:53:15 +00:00
|
|
|
RNA_def_function_flag(func, FUNC_USE_REPORTS);
|
2014-01-16 21:43:22 +11:00
|
|
|
parm = RNA_def_string_file_name(
|
|
|
|
|
func,
|
|
|
|
|
"filename",
|
|
|
|
|
NULL,
|
|
|
|
|
FILE_MAX,
|
|
|
|
|
"File Name",
|
2012-05-12 11:01:29 +00:00
|
|
|
"Filename to load into this render tile, must be no smaller than "
|
|
|
|
|
"the render result");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-02-06 17:23:02 +01:00
|
|
|
func = RNA_def_function(srna, "stamp_data_add_field", "rna_RenderResult_stamp_data_add_field");
|
|
|
|
|
RNA_def_function_ui_description(func, "Add engine-specific stamp data to the result");
|
|
|
|
|
parm = RNA_def_string(func, "field", NULL, 1024, "Field", "Name of the stamp field to add");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2018-11-08 01:05:55 +01:00
|
|
|
parm = RNA_def_string(func, "value", NULL, 0, "Value", "Value of the stamp data");
|
2017-02-06 17:23:02 +01:00
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-21 14:11:51 +00:00
|
|
|
RNA_define_verify_sdna(0);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
prop = RNA_def_property(srna, "resolution_x", PROP_INT, PROP_PIXEL);
|
|
|
|
|
RNA_def_property_int_sdna(prop, NULL, "rectx");
|
|
|
|
|
RNA_def_property_clear_flag(prop, PROP_EDITABLE);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
prop = RNA_def_property(srna, "resolution_y", PROP_INT, PROP_PIXEL);
|
|
|
|
|
RNA_def_property_int_sdna(prop, NULL, "recty");
|
|
|
|
|
RNA_def_property_clear_flag(prop, PROP_EDITABLE);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
prop = RNA_def_property(srna, "layers", PROP_COLLECTION, PROP_NONE);
|
|
|
|
|
RNA_def_property_struct_type(prop, "RenderLayer");
|
|
|
|
|
RNA_def_property_collection_funcs(prop,
|
|
|
|
|
"rna_RenderResult_layers_begin",
|
|
|
|
|
"rna_iterator_listbase_next",
|
2012-03-18 09:27:36 +00:00
|
|
|
"rna_iterator_listbase_end",
|
|
|
|
|
"rna_iterator_listbase_get",
|
|
|
|
|
NULL,
|
|
|
|
|
NULL,
|
|
|
|
|
NULL,
|
|
|
|
|
NULL);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
prop = RNA_def_property(srna, "views", PROP_COLLECTION, PROP_NONE);
|
|
|
|
|
RNA_def_property_struct_type(prop, "RenderView");
|
|
|
|
|
RNA_def_property_collection_funcs(prop,
|
|
|
|
|
"rna_RenderResult_views_begin",
|
|
|
|
|
"rna_iterator_listbase_next",
|
2015-04-06 10:40:12 -03:00
|
|
|
"rna_iterator_listbase_end",
|
|
|
|
|
"rna_iterator_listbase_get",
|
|
|
|
|
NULL,
|
|
|
|
|
NULL,
|
|
|
|
|
NULL,
|
|
|
|
|
NULL);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
RNA_define_verify_sdna(1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void rna_def_render_view(BlenderRNA *brna)
|
|
|
|
|
{
|
|
|
|
|
StructRNA *srna;
|
|
|
|
|
PropertyRNA *prop;
|
|
|
|
|
|
|
|
|
|
srna = RNA_def_struct(brna, "RenderView", NULL);
|
|
|
|
|
RNA_def_struct_ui_text(srna, "Render View", "");
|
|
|
|
|
|
|
|
|
|
RNA_define_verify_sdna(0);
|
|
|
|
|
|
|
|
|
|
prop = RNA_def_property(srna, "name", PROP_STRING, PROP_NONE);
|
|
|
|
|
RNA_def_property_string_sdna(prop, NULL, "name");
|
|
|
|
|
RNA_def_property_clear_flag(prop, PROP_EDITABLE);
|
|
|
|
|
RNA_def_struct_name_property(srna, prop);
|
|
|
|
|
|
2009-07-21 14:11:51 +00:00
|
|
|
RNA_define_verify_sdna(1);
|
|
|
|
|
}
|
|
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
static void rna_def_render_passes(BlenderRNA *brna, PropertyRNA *cprop)
|
|
|
|
|
{
|
|
|
|
|
StructRNA *srna;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
FunctionRNA *func;
|
|
|
|
|
PropertyRNA *parm;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
RNA_def_property_srna(cprop, "RenderPasses");
|
|
|
|
|
srna = RNA_def_struct(brna, "RenderPasses", NULL);
|
|
|
|
|
RNA_def_struct_sdna(srna, "RenderLayer");
|
|
|
|
|
RNA_def_struct_ui_text(srna, "Render Passes", "Collection of render passes");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
func = RNA_def_function(srna, "find_by_type", "rna_RenderPass_find_by_type");
|
|
|
|
|
RNA_def_function_ui_description(func, "Get the render pass for a given type and view");
|
2015-11-23 13:49:52 +11:00
|
|
|
parm = RNA_def_enum(
|
|
|
|
|
func, "pass_type", rna_enum_render_pass_type_items, SCE_PASS_COMBINED, "Pass", "");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2015-04-06 10:40:12 -03:00
|
|
|
parm = RNA_def_string(
|
|
|
|
|
func, "view", NULL, 0, "View", "Render view to get pass from"); /* NULL ok here */
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2015-04-06 10:40:12 -03:00
|
|
|
parm = RNA_def_pointer(func, "render_pass", "RenderPass", "", "The matching render pass");
|
|
|
|
|
RNA_def_function_return(func, parm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
func = RNA_def_function(srna, "find_by_name", "rna_RenderPass_find_by_name");
|
|
|
|
|
RNA_def_function_ui_description(func, "Get the render pass for a given name and view");
|
|
|
|
|
parm = RNA_def_string(func, "name", RE_PASSNAME_COMBINED, 0, "Pass", "");
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_string(
|
|
|
|
|
func, "view", NULL, 0, "View", "Render view to get pass from"); /* NULL ok here */
|
|
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
|
|
|
|
parm = RNA_def_pointer(func, "render_pass", "RenderPass", "", "The matching render pass");
|
|
|
|
|
RNA_def_function_return(func, parm);
|
2015-04-06 10:40:12 -03:00
|
|
|
}
|
|
|
|
|
|
2009-07-21 14:11:51 +00:00
|
|
|
static void rna_def_render_layer(BlenderRNA *brna)
|
|
|
|
|
{
|
|
|
|
|
StructRNA *srna;
|
|
|
|
|
PropertyRNA *prop;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-27 18:50:10 +00:00
|
|
|
FunctionRNA *func;
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
PropertyRNA *parm;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
srna = RNA_def_struct(brna, "RenderLayer", NULL);
|
2009-07-21 14:11:51 +00:00
|
|
|
RNA_def_struct_ui_text(srna, "Render Layer", "");
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
func = RNA_def_function(srna, "load_from_file", "RE_layer_load_from_file");
|
2011-09-19 13:23:58 +00:00
|
|
|
RNA_def_function_ui_description(func,
|
|
|
|
|
"Copies the pixels of this renderlayer from an image file");
|
2009-07-27 18:50:10 +00:00
|
|
|
RNA_def_function_flag(func, FUNC_USE_REPORTS);
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
parm = RNA_def_string(
|
|
|
|
|
func,
|
|
|
|
|
"filename",
|
|
|
|
|
NULL,
|
|
|
|
|
0,
|
|
|
|
|
"Filename",
|
2012-05-12 11:01:29 +00:00
|
|
|
"Filename to load into this render tile, must be no smaller than the renderlayer");
|
Refactor RNA property: split flags in property flags, parameter flags, and internal flags.
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
2016-12-12 15:23:55 +01:00
|
|
|
RNA_def_parameter_flags(parm, 0, PARM_REQUIRED);
|
2011-09-19 13:23:58 +00:00
|
|
|
RNA_def_int(func,
|
|
|
|
|
"x",
|
|
|
|
|
0,
|
|
|
|
|
0,
|
|
|
|
|
INT_MAX,
|
|
|
|
|
"Offset X",
|
|
|
|
|
"Offset the position to copy from if the image is larger than the render layer",
|
|
|
|
|
0,
|
|
|
|
|
INT_MAX);
|
|
|
|
|
RNA_def_int(func,
|
|
|
|
|
"y",
|
|
|
|
|
0,
|
|
|
|
|
0,
|
|
|
|
|
INT_MAX,
|
|
|
|
|
"Offset Y",
|
|
|
|
|
"Offset the position to copy from if the image is larger than the render layer",
|
|
|
|
|
0,
|
|
|
|
|
INT_MAX);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-21 14:11:51 +00:00
|
|
|
RNA_define_verify_sdna(0);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2018-12-29 10:04:39 +11:00
|
|
|
rna_def_view_layer_common(srna, false);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "passes", PROP_COLLECTION, PROP_NONE);
|
2009-07-21 14:11:51 +00:00
|
|
|
RNA_def_property_struct_type(prop, "RenderPass");
|
2012-03-18 09:27:36 +00:00
|
|
|
RNA_def_property_collection_funcs(prop,
|
|
|
|
|
"rna_RenderLayer_passes_begin",
|
|
|
|
|
"rna_iterator_listbase_next",
|
|
|
|
|
"rna_iterator_listbase_end",
|
|
|
|
|
"rna_iterator_listbase_get",
|
|
|
|
|
NULL,
|
|
|
|
|
NULL,
|
|
|
|
|
NULL,
|
|
|
|
|
NULL);
|
2015-04-06 10:40:12 -03:00
|
|
|
rna_def_render_passes(brna, prop);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2009-07-21 14:11:51 +00:00
|
|
|
RNA_define_verify_sdna(1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void rna_def_render_pass(BlenderRNA *brna)
|
|
|
|
|
{
|
|
|
|
|
StructRNA *srna;
|
|
|
|
|
PropertyRNA *prop;
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
srna = RNA_def_struct(brna, "RenderPass", NULL);
|
2009-07-21 14:11:51 +00:00
|
|
|
RNA_def_struct_ui_text(srna, "Render Pass", "");
|
|
|
|
|
|
|
|
|
|
RNA_define_verify_sdna(0);
|
|
|
|
|
|
Render API/Cycles: Identify Render Passes by their name instead of a type flag
Previously, every RenderPass would have a bitfield that specified its type. That limits the number of passes to 32, which was reached a while ago.
However, most of the code already supported arbitrary RenderPasses since they were also used to store Multilayer EXR images.
Therefore, this commit completely removes the passflag from RenderPass and changes all code to use the unique pass name for identification.
Since Blender Internal relies on hardcoded passes and to preserve compatibility, 32 pass names are reserved for the old hardcoded passes.
To support these arbitrary passes, the Render Result compositor node now adds dynamic sockets. For compatibility, the old hardcoded sockets are always stored and just hidden when the corresponding pass isn't available.
To use these changes, the Render Engine API now includes a function that allows render engines to add arbitrary passes to the render result. To be able to add options for these passes, addons can now add their own properties to SceneRenderLayers.
To keep the compositor input node updated, render engine plugins have to implement a callback that registers all the passes that will be generated.
From a user perspective, nothing should change with this commit.
Differential Revision: https://developer.blender.org/D2443
Differential Revision: https://developer.blender.org/D2444
2017-05-03 00:21:18 +02:00
|
|
|
prop = RNA_def_property(srna, "fullname", PROP_STRING, PROP_NONE);
|
|
|
|
|
RNA_def_property_string_sdna(prop, NULL, "fullname");
|
|
|
|
|
RNA_def_property_clear_flag(prop, PROP_EDITABLE);
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "name", PROP_STRING, PROP_NONE);
|
2009-07-21 14:11:51 +00:00
|
|
|
RNA_def_property_string_sdna(prop, NULL, "name");
|
|
|
|
|
RNA_def_property_clear_flag(prop, PROP_EDITABLE);
|
|
|
|
|
RNA_def_struct_name_property(srna, prop);
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "channel_id", PROP_STRING, PROP_NONE);
|
2009-07-21 14:11:51 +00:00
|
|
|
RNA_def_property_string_sdna(prop, NULL, "chan_id");
|
|
|
|
|
RNA_def_property_clear_flag(prop, PROP_EDITABLE);
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "channels", PROP_INT, PROP_NONE);
|
2009-07-21 14:11:51 +00:00
|
|
|
RNA_def_property_int_sdna(prop, NULL, "channels");
|
|
|
|
|
RNA_def_property_clear_flag(prop, PROP_EDITABLE);
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
prop = RNA_def_property(srna, "rect", PROP_FLOAT, PROP_NONE);
|
2009-09-09 19:40:46 +00:00
|
|
|
RNA_def_property_flag(prop, PROP_DYNAMIC);
|
|
|
|
|
RNA_def_property_multi_array(prop, 2, NULL);
|
|
|
|
|
RNA_def_property_dynamic_array_funcs(prop, "rna_RenderPass_rect_get_length");
|
|
|
|
|
RNA_def_property_float_funcs(prop, "rna_RenderPass_rect_get", "rna_RenderPass_rect_set", NULL);
|
2009-07-21 14:11:51 +00:00
|
|
|
|
2015-04-06 10:40:12 -03:00
|
|
|
prop = RNA_def_property(srna, "view_id", PROP_INT, PROP_NONE);
|
|
|
|
|
RNA_def_property_int_sdna(prop, NULL, "view_id");
|
2014-10-04 19:00:26 +06:00
|
|
|
RNA_def_property_clear_flag(prop, PROP_EDITABLE);
|
|
|
|
|
|
2009-07-21 14:11:51 +00:00
|
|
|
RNA_define_verify_sdna(1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void RNA_def_render(BlenderRNA *brna)
|
|
|
|
|
{
|
2009-07-21 20:28:32 +00:00
|
|
|
rna_def_render_engine(brna);
|
2009-07-21 14:11:51 +00:00
|
|
|
rna_def_render_result(brna);
|
2015-04-06 10:40:12 -03:00
|
|
|
rna_def_render_view(brna);
|
2009-07-21 14:11:51 +00:00
|
|
|
rna_def_render_layer(brna);
|
|
|
|
|
rna_def_render_pass(brna);
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-05 23:30:41 +00:00
|
|
|
#endif /* RNA_RUNTIME */
|