BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
The RenderResult struct still has a listbase of RenderLayer, but that's ok
since this is strictly for rendering.
* Subversion bump (to 2.80.2)
* DNA low level doversion (renames) - only for .blend created since 2.80 started
Note: We can't use DNA_struct_elem_find or get file version in init_structDNA,
so we are manually iterating over the array of the SDNA elements instead.
Note 2: This doversion change with renames can be reverted in a few months. But
so far it's required for 2.8 files created between October 2016 and now.
Reviewers: campbellbarton, sergey
Differential Revision: https://developer.blender.org/D2927
This patch moves all the functionality previously in SceneRenderLayer to SceneLayer.
If we want to rename some of these structs now would be a good time to do it, before they are in SceneLayer.
Everything should be working, though I will test things further tomorrow. Once this is committed depsgraph can get
rid of the workaround added in rna_Main_meshes_new_from_object and finish whatever this patch was preventing from being finished.
This patch also adds a few placeholders for the overrides (samples, ...). These are obviously not working, so some unittests that rely on 'lay', and 'zmask' will fail.
This patch does not addressed the change of moving samples to ViewRender (I have this as a separate patch and needs some separate discussion).
Following next is the individual note of the individual parts that were committed.
Note 1: It is up to Cycles to still get rid of exclude_layer internally.
Note 2: Cycles still need to handle its own doversion for the use_layer_samples cases and
(1) Remove the override as it is
(2) Add a new override (scene.cycles.samples) if scene.cycles.use_layer_samples != IGNORE
Respecting the expected behaviour when scene.cycles.use_layer_samples == BOUNDED.
Note 3: Cycles still need to implement the per-object holdout
(similar to how we do shadow catcher).
Note 4: There are parts of the old (Blender Internal) rendering pipeline that is still
using lay, e.g., in shi->lay.
Honestly it will be easier to purge the entire Blender Internal code away instead of taking things from it bit by bit.
Reviewers: sergey, campbellbarton, brecht
Differential Revision: https://developer.blender.org/D2919
We were calling BLI_remlink and then BLI_insertlinkbefore/after quite often. BLI_listbase_link_move simplifies code a bit and makes it easier to follow. It also returns if link position has changed which can be used to avoid unnecessary updates.
Added it to a number of list reorder operators for now and made use of return value. Behavior shouldn't be changed.
Also some minor cleanup.
In pipeline.c the function add_freestyle() was supposed to be called once
per frame, but after the Multi-view merge the function are called as many
as the number of views. There were however a few Freestyle parameters
that have to be initialized per frame, and initializing one of the
parameters for each view was causing double freeing of allocated memory
which was enough to result in a crash.
New render layer option named "View map cache" is added to reuse a
previously computed view map for subsequent rendering. The cache is
automatically updated when the mesh geometry of the input 3D scene has
been changed.
This functionality offers a major performance boost for Freestyle
animation rendering when camera-space mesh geometry is static, as well
as for repeated still renders with updates of line stylization options.
Although the "View map cache" toggle is a render layer option, the cache
memory is shared by all render layers and scenes. This means that if
Freestyle is used for two or more render layers (possibly in different
scenes through the compositor), then the cached view map for one render
layer is replaced by a new view map for another render layer and hence
no performance gain is expected.
The stored context object was used for creation of shade nodes. A closer look at the
node system showed that the context is not actually used when shader nodes are
added to a shader node tree. Relying on this fact, now a NULL pointer is passed to
nodeAddStaticNode() instead of the stored bContext pointer.
Now add_freestyle() in pipeline.c takes a second argument to enable/disable
stroke rendering. When stroke rendering is disabled, the function allocates
data structures but does not perform stroke rendering. The allocated data
structures (mostly left unpopulated with data elements) are intended to allow
for the Read Full Sample Layers (Shift-R) command in the compositor.
and RNA for it independent of the build flag for enabling Freestyle. Suggested
by Sergey Sharybin through a code review of the branch.
* Many #ifdef WITH_FREESTYLE blocks were removed to always have Freestyle-specific
DNA file specification and RNA for it built in Blender. This will allow Freestyle
setting survive even when a non-Freestyle build is used for loading and saving
files. It is noted that operations are still conditionally built through #ifdef
WITH_FREESTYLE blocks.
* To this end, new blenkernel files BKE_freestyle.h and intern/freestyle.c have
been added. All API functions in FRS_freestyle_config.h as well as some of those
in FRS_freestyle.h were moved to the new files. Now the relocated API functions
have BKE_ prefix instead of FRS_.
The problem was caused by the fact that BKE_scene_copy() was simply doing "memcpy"
to duplicate render layers including lineset settings without taking care of pointers
in the linesets. For this reason, freeing the original scene and copied one resulted
in freeing allocated memory buffers twice.
Now BKE_scene_copy() properly duplicates linesets as part of render layers.
Also some code clean-up was made in the modified files.
Problem report by IRIE Shinsuke (with a patch to fix the crash). Many thanks!
of copy/paste functionality. Instead of making a copy of the active
line set, now the settings of the active line set are copied to and
pasted from a buffer. This allows for copying and pasting line set
settings among different scenes and render layers.
Parameter Editor mode. This is a WIP commit. Only the base line
color, base alpha transparency, and base line thickness are respected.
More additions are anticipated to account for other parameters.
* Added FRS_finish_stroke_rendering() to clean Freestyle-related
temporary resources after stroke rendering.
* Some functions in FRS_freestyle.cpp are now declared as static
functions, so as not to mess up the program-wide name space.
* Made the StyleModule class inheritable, and defined new subclass
BlenderStyleModule that takes a Text object instead of a file name.
A number of UI elements were newly introduced to control line color, alpha
transparency and line thickness by means of base color/alpha/thickness plus
modifiers that alter the base values. To begin with, three basic modifiers
were prototyped with the aim of putting the new UI framework in practice
and evaluating if it works properly.
The Parameter Editor mode is still in a work-in-progress state and totally
useless from users' viewpoint.
This commit is just meant to give the new GUI framework a concrete shape.
There is no usefulness in newly introduced elements at the moment.
Freestyle options in render layers now include a pull-down menu named Control
Mode that allows you to choose either the Python Scripting or Parameter Editor
mode. The Python Scripting mode is the conventional way of controlling
Freestyle by directly using style modules written in Python. The Parameter
Editor is a new control mode that is intended to be used by everyone without
relying on Python programming.
In the Parameter Editor mode, you can specify multiple line sets for each
render layer. A line set defines feature edge selection criteria, as
well as a line style for drawing the selected feature edges using specific
line stylization parameters. Line style is a new datablock type, meaning
that a line style can be shared by multiple line sets (possibly those in
different render layers in different scenes).
Much more additions are anticipated in subsequent commits to implement UI
controls for specifying feature edge selection criteria and line stylization
parameters.
The render pipeline has been extended to better work with
Freestyle stroke rendering. Struct Render has a new member
ListBase freestyle_renders to keep Render instances generated
through stroke rendering in Freestyle. The number of
elements (LinkData instances with LinkData::data pointing to a
Render instance) in freestyle_renders is the same as the scene
render layers of the scene being rendered. When the k-th scene
render layer has the Freestyle option enabled, the k-th element
of freestyle_renders refers to a Render instance that holds
Freestyle render results for the scene layer. This association
between the scene render layer and the Render instance is used to
merge the Freestyle render results into the corresponding render
results for the scene render layer.
from within style modules. Calling this function is only valid within
style modules. Calling it from the Python Interactive Console results
in an error as follows:
>>> import Freestyle
>>> Freestyle.getCurrentScene()
Traceback (most recent call last):
File "<console>", line 1, in <module>
TypeError: current scene not available
>>>
initializing Freestyle and specifying contexts, making the API a bit messy.
Now FRS_initialize() is only for initialization, and contexts are specified
by new FRS_set_context() function just before starting rendering.
2.4x) from within Freestyle. Now Freestyle configuration parameters
are edited without relying on the notion of the current scene. This
resolved a few related issues as described below:
- A bug in Freestyle configuration management with respect to
multiple scenes was fixed. Now Freestyle configuration parameters
(e.g., style modules, ridges/valleys, suggestive contours) can be
specified for each render layer of each scene. Composition of
multiple render layers from different scenes should work as expected.
- A crash after undoing was fixed as well.
* Removed unused external Freestyle functions and global variables
from FRS_freestyle.h and FRS_freestyle.cpp.
- proper Freestyle initialization, with support for undo/redo
- re-added FreestyleStyleConfig data structure
- Freestyle Python interpreter updated
This commit should compile without errors. More work is necessary to complete the migration:
- add Freestyle in the UI
- set up RNA support
The main contribution of this commit is the possibility to save Freestyle configuration information inside .blend files. It required an extensive refactoring of the previous interface code.
The code has been tested and does not crash on my machine. If you encounter issues, please let me know (and if possible, sending me an sample .blend file).
DETAILS:
- refactored code to notify Freestyle when adding/removing render layers (FRS_freestyle_config.{h,cpp})
- corrected the freeing of style modules when files are read from / written to disk
- moved Freestyle configuration information into scene renderlayers, to allow loading / saving .blend files (DNA_scene_types.h DNA_freestyle_types.h FRS_freestyle.cpp)
- inserted temporary trick to prevent crashes when orthographic camera is used (SilhouetteGeomEngine.cpp), but outputting incorrect feature line calculations
Freestyle's pipeline is now fully controllable at the layer level. It can be used:
- in any render layer
- with as many style modules per layer
DETAILS:
Freestyle usage has not changed:
- all the configuration happens in the "Freestyle" render panel, after it is enabled in the "Output" panel with the 'Freestyle' toggle.
- each render layer can choose to render Freestyle strokes by togglingo on 'FrSt' (in the "Render Layers" panel)
- it is fully compatible with compositor nodes
In the "Freestyle" panel, a render layer is selected via the menu list next to the "Render Layer:" label. The options displayed below are those of the currently selected render layer (and are not global to all render layers, as was previously the case).
Style modules are added by pressing the lower button "Add style module". Once added, the following operations are possible:
- deletion (cross)
- reordering (up/down arrows)
- toggling of display (check)
The order of the style modules follows Freestyle's original convention: the modules in the list from top to bottom are respectively the first to the last composited in the render layer. For example, if the module list is "contour" followed by "cartoon", the "cartoon" strokes are rendered on top of the "contour" strokes.
The "Freestyle" panel is constantly synchronized with the "Render Layers" panel: if render layers are added, deleted or toggled off display, Freestyle will take note of the changes.
The current pipeline works as follows:
----------------------------------------------------------------------------------------------
for every scene that is being rendered
if Freestyle is enabled globally
Freestyle is initialized
camera and view settings are transferred from Blender to Freestyle
for every render layer
if: - layer is enabled
- layer enabled Freestyle
- the number of displayed style modules is non-zero
canvas is cleared
geometry is transferred from Blender to Freestyle
settings are fixed for current iteration
view map is calculated
strokes are computed in the canvas (based on view map and style modules)
strokes are rendered in separate Blender scene
scene is composited in current layer
----------------------------------------------------------------------------------------------
A number of changes were made on the codebase:
- the rendering interface between Freestyle and Blender was simplified. The following naming convention was used: functions that are called from within Blender pipeline are prefixed with 'FRS_', while the variables are prefixed with 'freestyle_'
- Freestyle data structures that were put in Blender's render pipeline were removed
- Freestyle cleans up its data structures on Blender exit and shouldn't leak memory
- to ease the configuration in the "Freestyle" panel, a centralized configuration data structure was used and can be easily extended
LIMITATIONS
Even though the current commit is stable and achieves the intended result, it is not as efficient as it could be:
- the canvas and the style modules are at cleared at each layer-level render
- geometry is reloaded at each frame and is duplicated across render layers
This revision clarifies my understanding of the future role of the view map in the compositor. Unfortunately, contrary to what the original proposal said, it is impossible to provide the view map as a render pass because render passes are defined (RE_pipeline.h) as raw floating-point rects. We will have to determine whether or not to extend the notion of render pass to fully integrate the view map in the compositor.
The render generated from Freestyle's data is currently stored in the original scene's render structure ( as 'freestyle_render'): when the render database is generated, the scene's geometrical data is first imported into Freestyle and strokes are calculated. The generated strokes are used to create a Blender scene, rendered independently. The render result is used in the rendering loop.
The final rendering is performed the same way edge rendering is, in a function ('freestyle_enhance_add') operating on each individual render part. Freestyle strokes are only included if the toggle button "Freestyle" (in the 'Output' panel) is active and if the "Freestyle" render layer is also selected. Freestyle's panel appears when the toggle button 'Freestyle' is active.
IMPORTANT: as of now, rendering ONLY works when OSA is disabled and when Xparts = Yparts = 1. If these settings are not set, a bogus image will be created.
To make the render happen, many modifications had to be made:
- the Canvas::Draw and Operators::create methods no longer render strokes. They only generate shading and locational information.
- a BlenderStrokeRenderer class was added to turn Freestyle's strokes into a Blender scene. Basically, the scene consists of strokes in their projected image 2D coordinates and an orthographic camera centered in the middle of the corresponding canvas. The scene is rendered using vertex colors, in shadeless mode (therefore, no lamp is needed). BlenderStrokeRenderer uses the old GLTextureManager to load textures (as required by the StrokeRenderer class), even though stroke textures are probably not supported (not tested). After the scene is rendered, it is safely and automatically discarded.
- AppCanvas' code was greatly reduced to the bare minimum. The former AppCanvas would use an OpenGL-based back buffer and z buffer to determine the scene's color and depth information. In the future, this data will be determined from the corresponding render passes. Currently, the integration is not achieved so all style modules using depth/color information are sure to fail.
- before, Freestyle needed an OpenGL context to determine the camera's information and to compute the view map. As of now, the modelview and projection matrices are fully determined using data provided by Blender. This means both perspective and orthographic projections are supported. The AppGLWidget will very soon be removed completely.
