archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
510c69368b7382aa55f3fae0dac9ee6aaadee7e5
blender-archive/source/blender/freestyle/intern/blender_interface/FRS_freestyle.cpp

565 lines
18 KiB
C++
Raw Normal View History

fixed headers and SConscript to have successful build
2009-10-05 01:27:35 +00:00
#include "../application/Controller.h"
Got rid of a number of compiler warnings with regard to redefinitions of _POSIX_C_SOURCE and _XOPEN_SOURCE. There are no functional changes. Tested with GCC 4.4.1 on Ubuntu 9.10 (karmic).
2010-04-07 23:28:29 +00:00
#include "../application/AppView.h"
fixed headers and SConscript to have successful build
2009-10-05 01:27:35 +00:00
#include "../application/AppConfig.h"
#include "../application/AppCanvas.h"
soc-2008-mxcurioni: Big update. Finally works (links and compiles). So far, the following steps work: 1. instantiates the config path, the controller and the view 2. sets the controller’s view 3. loads a 3ds file (right now a fixed file) 4. inserts a style module (right now, also fixed) 5. computes the view map The next and final step is running the Python script. A lot of information are fixed and should be changed to test the following code: see source/blender/freestyle/app_blender/*.cpp and search for fixed paths (starting in /Users/). I am currently evaluating whether it's worth making Python run on its own environment (right now, the program crashes because of PyImport_AddModule) or whether it should use Blender's Python capabilities. Also, I need to figure out how to integrate the SWIG wrapper dynamic library into the current scheme.
2008-05-25 17:34:21 +00:00
soc-2008-mxcurioni: uploaded missing files. Still NOT linking so do not use this version yet :(
2008-05-19 05:34:31 +00:00
#include <iostream>
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
#include <map>
#include <set>
using namespace std;
soc-2008-mxcurioni: uploaded missing files. Still NOT linking so do not use this version yet :(
2008-05-19 05:34:31 +00:00
soc-2008-mxcurioni: First render ! It should render the teapot upside down on a black background. The correction was made by following Yafray's rendering and display implementation, which is very clear.
2008-05-29 00:27:09 +00:00
#ifdef __cplusplus
extern "C" {
#endif
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
#include "MEM_guardedalloc.h"
Made changes to enable features line parameters (ridges/valleys and suggestive contours) and add corresponding UI controls to the Freestyle tab in the Scene buttons.
2008-11-09 13:14:41 +00:00
soc-2008-mxcurioni: renamed libQGLWidget's Camera class to AppGLWidget_Camera to use Blender's Camera struct, integrated the camera parameters from Blender. Perspective projection (precisely field of view) is now correct. Orthographic projection still having issues.
2008-07-02 12:16:36 +00:00
#include "DNA_camera_types.h"
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
#include "DNA_text_types.h"
Fix for the Link/Append commands not working when scenes had line styles. The problem was reported by mato.sus304, thank you!
2011-09-15 00:06:49 +00:00
#include "DNA_group_types.h"
SUMMARY: 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
2009-08-04 00:40:36 +00:00
#include "DNA_freestyle_types.h"
soc-2008-mxcurioni: renamed libQGLWidget's Camera class to AppGLWidget_Camera to use Blender's Camera struct, integrated the camera parameters from Blender. Perspective projection (precisely field of view) is now correct. Orthographic projection still having issues.
2008-07-02 12:16:36 +00:00
A step toward a new user-friendly GUI for manipulating line style parameters. 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.
2010-06-25 22:45:42 +00:00
#include "BKE_global.h"
#include "BKE_library.h"
#include "BKE_linestyle.h"
Migration of Freestyle to Blender 2.5 codebase (continued): - 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
2009-09-28 03:56:31 +00:00
#include "BKE_main.h"
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
#include "BKE_text.h"
soc-2008-mxcurioni: now supports current scene drawing (instead of fixed scene object), still with fixed style and fixed camera. Initialization is properly handled, which limits memory problems and speed-ups subsequent rendering. The viewing ratio should be correct now too. I also removed linking references to former lib3ds library path (caused some linking problems).
2008-06-08 19:35:20 +00:00
#include "BLI_blenlib.h"
Fixed a bug in SilhouetteGeomEngine::ImageToWorldParameter() that caused instability issues regarding the view map creation. A new iterative solver of the 2D-to-3D inverse projection transformation problem was implemented. Instead of directly solving the problem in the direction from the 2D to 3D space, the new solver starts with an initial guess of an approximated solution and asymptotically approaches to the true solution by iteratively performing the forward 3D-to-2D projection transformation and improving the approximation. Preliminary tests with one simple and another complex scenes showed that the solver converges quickly (more and less 20 iterations in many cases, with a stopping criterion of a residual distance between the true and approximated solutions less than 1e-6 Blender Unit).
2010-01-10 14:08:59 +00:00
#include "BLI_math.h"
soc-2008-mxcurioni: now supports current scene drawing (instead of fixed scene object), still with fixed style and fixed camera. Initialization is properly handled, which limits memory problems and speed-ups subsequent rendering. The viewing ratio should be correct now too. I also removed linking references to former lib3ds library path (caused some linking problems).
2008-06-08 19:35:20 +00:00
#include "BPY_extern.h"
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
#include "renderpipeline.h"
#include "pixelblending.h"
soc-2008-mxcurioni: uploaded missing files. Still NOT linking so do not use this version yet :(
2008-05-19 05:34:31 +00:00
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
#include "../../FRS_freestyle.h"
SUMMARY: 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
2009-08-04 00:40:36 +00:00
#include "../../FRS_freestyle_config.h"
soc-2008-mxcurioni: uploaded missing files. Still NOT linking so do not use this version yet :(
2008-05-19 05:34:31 +00:00
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
// Freestyle configuration
* Removed a back pointer to a Scene (the "current" scene as in Blender 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.
2009-11-01 01:11:15 +00:00
static short freestyle_is_initialized = 0;
soc-2008-mxcurioni: foundations for Freestyle as a render layer - new UI buttons and mode flags, Freestyle API refactoring, modified pipeline to incorporate the new render layer. Compared to previously, the layer functionality is available when selecting 'Blender Internal' as the rendering engine. Freestyle's result is not available in the layer yet. I need to integrate OpenGL offscreen rendering properly (with framebuffer objects) to reach that goal.
2008-07-04 07:59:19 +00:00
static Config::Path *pathconfig = NULL;
soc-2008-mxcurioni: now supports current scene drawing (instead of fixed scene object), still with fixed style and fixed camera. Initialization is properly handled, which limits memory problems and speed-ups subsequent rendering. The viewing ratio should be correct now too. I also removed linking references to former lib3ds library path (caused some linking problems).
2008-06-08 19:35:20 +00:00
static Controller *controller = NULL;
removed AppGLWidget and all related classes added an AppView class to transfer camera information from Blender to Freestyle removed unused functions
2008-12-10 21:51:58 +00:00
static AppView *view = NULL;
soc-2008-mxcurioni: foundations for Freestyle as a render layer - new UI buttons and mode flags, Freestyle API refactoring, modified pipeline to incorporate the new render layer. Compared to previously, the layer functionality is available when selecting 'Blender Internal' as the rendering engine. Freestyle's result is not available in the layer yet. I need to integrate OpenGL offscreen rendering properly (with framebuffer objects) to reach that goal.
2008-07-04 07:59:19 +00:00
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
// camera information
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes. 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.
2008-12-01 21:30:44 +00:00
float freestyle_viewpoint[3];
float freestyle_mv[4][4];
float freestyle_proj[4][4];
int freestyle_viewport[4];
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
Added Freestyle.getCurrentScene() to give access to the current scene 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 >>>
2009-12-06 22:01:04 +00:00
// current scene
Scene *freestyle_scene;
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
string default_module_path;
//=======================================================
// Initialization
//=======================================================
soc-2008-mxcurioni: added a Freestyle panel to select a style at run-time, by specifying its pathname. By default, it is loaded with the contour.py path.
2008-07-31 11:20:30 +00:00
Improved context handling. Previously FRS_initialize() was used for both 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.
2009-11-10 00:03:31 +00:00
void FRS_initialize() {
soc-2008-mxcurioni: Big update. Finally works (links and compiles). So far, the following steps work: 1. instantiates the config path, the controller and the view 2. sets the controller’s view 3. loads a 3ds file (right now a fixed file) 4. inserts a style module (right now, also fixed) 5. computes the view map The next and final step is running the Python script. A lot of information are fixed and should be changed to test the following code: see source/blender/freestyle/app_blender/*.cpp and search for fixed paths (starting in /Users/). I am currently evaluating whether it's worth making Python run on its own environment (right now, the program crashes because of PyImport_AddModule) or whether it should use Blender's Python capabilities. Also, I need to figure out how to integrate the SWIG wrapper dynamic library into the current scheme.
2008-05-25 17:34:21 +00:00
* Removed a back pointer to a Scene (the "current" scene as in Blender 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.
2009-11-01 01:11:15 +00:00
if( freestyle_is_initialized )
return;
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
* Removed a back pointer to a Scene (the "current" scene as in Blender 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.
2009-11-01 01:11:15 +00:00
pathconfig = new Config::Path;
Improved context handling. Previously FRS_initialize() was used for both 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.
2009-11-10 00:03:31 +00:00
controller = new Controller();
* Removed a back pointer to a Scene (the "current" scene as in Blender 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.
2009-11-01 01:11:15 +00:00
view = new AppView;
controller->setView(view);
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
controller->Clear();
Added Freestyle.getCurrentScene() to give access to the current scene 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 >>>
2009-12-06 22:01:04 +00:00
freestyle_scene = NULL;
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
* Removed a back pointer to a Scene (the "current" scene as in Blender 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.
2009-11-01 01:11:15 +00:00
default_module_path = pathconfig->getProjectDir() + Config::DIR_SEP + "style_modules" + Config::DIR_SEP + "contour.py";
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
* Removed a back pointer to a Scene (the "current" scene as in Blender 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.
2009-11-01 01:11:15 +00:00
freestyle_is_initialized = 1;
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
}
SUMMARY: 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
2009-08-04 00:40:36 +00:00
Improved context handling. Previously FRS_initialize() was used for both 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.
2009-11-10 00:03:31 +00:00
void FRS_set_context(bContext* C) {
cout << "FRS_set_context: context 0x" << C << " scene 0x" << CTX_data_scene(C) << endl;
controller->setContext(C);
}
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
void FRS_exit() {
delete pathconfig;
delete controller;
delete view;
soc-2008-mxcurioni: now supports current scene drawing (instead of fixed scene object), still with fixed style and fixed camera. Initialization is properly handled, which limits memory problems and speed-ups subsequent rendering. The viewing ratio should be correct now too. I also removed linking references to former lib3ds library path (caused some linking problems).
2008-06-08 19:35:20 +00:00
}
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
//=======================================================
// Rendering
//=======================================================
soc-2008-mxcurioni: foundations for Freestyle as a render layer - new UI buttons and mode flags, Freestyle API refactoring, modified pipeline to incorporate the new render layer. Compared to previously, the layer functionality is available when selecting 'Blender Internal' as the rendering engine. Freestyle's result is not available in the layer yet. I need to integrate OpenGL offscreen rendering properly (with framebuffer objects) to reach that goal.
2008-07-04 07:59:19 +00:00
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
static void init_view(Render* re){
Fixed a bug that caused a Y-direction offset in rendering results. The renderer now takes the aspect ratio settings into account.
2010-01-29 22:13:39 +00:00
float ycor = ((float)re->r.yasp) / ((float)re->r.xasp);
Fixed bugs in AppCanvas::readColorPixels() and AppCanvas::readDepthPixels() that caused a crash when the aspect ratio was not 1:1.
2010-02-16 21:44:18 +00:00
int width = re->r.xsch;
int height = (int)(((float)re->r.ysch) * ycor);
Fix for the issue described in the commit log of revision 27846: Made the diffuse and Z depth information accessible from style modules when the border option is enabled.
2010-03-30 17:10:52 +00:00
int xmin = re->r.border.xmin * width;
int xmax = re->r.border.xmax * width;
int ymin = re->r.border.ymin * height;
int ymax = re->r.border.ymax * height;
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes. 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.
2008-12-01 21:30:44 +00:00
freestyle_viewport[0] = freestyle_viewport[1] = 0;
freestyle_viewport[2] = width;
freestyle_viewport[3] = height;
view->setWidth( width );
view->setHeight( height );
Fix for the issue described in the commit log of revision 27846: Made the diffuse and Z depth information accessible from style modules when the border option is enabled.
2010-03-30 17:10:52 +00:00
view->setBorder( xmin, ymin, xmax, ymax );
cout << "\n=== Dimensions of the 2D image coordinate system ===" << endl;
cout << "Width : " << width << endl;
cout << "Height : " << height << endl;
if (re->r.mode & R_BORDER)
cout << "Border : (" << xmin << ", " << ymin << ") - (" << xmax << ", " << ymax << ")" << endl;
soc-2008-mxcurioni: foundations for Freestyle as a render layer - new UI buttons and mode flags, Freestyle API refactoring, modified pipeline to incorporate the new render layer. Compared to previously, the layer functionality is available when selecting 'Blender Internal' as the rendering engine. Freestyle's result is not available in the layer yet. I need to integrate OpenGL offscreen rendering properly (with framebuffer objects) to reach that goal.
2008-07-04 07:59:19 +00:00
}
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
static void init_camera(Render* re){
Improvements of mesh importing. Previously mesh vertices imported from vlak nodes were transformed from the camera coordinate system to the object local coordinate system. This causes a difficulty in recovering object local vertices when mesh deforming modifiers (e.g., curve, cloth, and soft body) have been applied. Now the view map creation is done based on mesh vertices in the camera coordinate system. Advantages of this approach includes: 1) faster mesh importing because of less matrix-based transformations; and 2) proper handling of meshes with deforming modifiers.
2010-01-30 01:36:12 +00:00
// It is assumed that imported meshes are in the camera coordinate system.
// Therefore, the view point (i.e., camera position) is at the origin, and
// the the model-view matrix is simply the identity matrix.
freestyle_viewpoint[0] = 0.0;
freestyle_viewpoint[1] = 0.0;
freestyle_viewpoint[2] = 0.0;
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes. 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.
2008-12-01 21:30:44 +00:00
Simplified modelview matrix copy
2009-04-12 07:02:03 +00:00
for( int i = 0; i < 4; i++ )
for( int j = 0; j < 4; j++ )
Improvements of mesh importing. Previously mesh vertices imported from vlak nodes were transformed from the camera coordinate system to the object local coordinate system. This causes a difficulty in recovering object local vertices when mesh deforming modifiers (e.g., curve, cloth, and soft body) have been applied. Now the view map creation is done based on mesh vertices in the camera coordinate system. Advantages of this approach includes: 1) faster mesh importing because of less matrix-based transformations; and 2) proper handling of meshes with deforming modifiers.
2010-01-30 01:36:12 +00:00
freestyle_mv[i][j] = (i == j) ? 1.0 : 0.0;
Simplified modelview matrix copy
2009-04-12 07:02:03 +00:00
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes. 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.
2008-12-01 21:30:44 +00:00
for( int i = 0; i < 4; i++ )
for( int j = 0; j < 4; j++ )
freestyle_proj[i][j] = re->winmat[i][j];
Fixed a bug in SilhouetteGeomEngine::ImageToWorldParameter() that caused instability issues regarding the view map creation. A new iterative solver of the 2D-to-3D inverse projection transformation problem was implemented. Instead of directly solving the problem in the direction from the 2D to 3D space, the new solver starts with an initial guess of an approximated solution and asymptotically approaches to the true solution by iteratively performing the forward 3D-to-2D projection transformation and improving the approximation. Preliminary tests with one simple and another complex scenes showed that the solver converges quickly (more and less 20 iterations in many cases, with a stopping criterion of a residual distance between the true and approximated solutions less than 1e-6 Blender Unit).
2010-01-10 14:08:59 +00:00
//print_m4("mv", freestyle_mv);
//print_m4("proj", freestyle_proj);
soc-2008-mxcurioni: foundations for Freestyle as a render layer - new UI buttons and mode flags, Freestyle API refactoring, modified pipeline to incorporate the new render layer. Compared to previously, the layer functionality is available when selecting 'Blender Internal' as the rendering engine. Freestyle's result is not available in the layer yet. I need to integrate OpenGL offscreen rendering properly (with framebuffer objects) to reach that goal.
2008-07-04 07:59:19 +00:00
}
soc-2008-mxcurioni: refactored Freestyle API to prepare for both rendering modes (OpenGL and Blender internal), applied a patch to allow CMake to be used for compilation.
2008-10-01 15:03:35 +00:00
* Fix for a freeze issue in stroke rendering when using round/square caps. The problem was caused by a stroke with only one vertex. Such a stroke was generated when for some unknown reason a chained curve consisted of only two vertices such that their 3D positions were exactly or almost the same. * Fix for the Parameter Editor mode that failed when scene render layers and/or linesets contain a single quote in their names.
2010-12-06 22:17:19 +00:00
static char *escape_quotes(char *name)
{
char *s= (char *)MEM_mallocN(strlen(name) * 2 + 1, "escape_quotes");
char *p= s;
while (*name) {
if (*name == '\'')
*p++= '\\';
*p++ = *name++;
}
*p = '\0';
return s;
}
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
static Text *create_lineset_handler(char *layer_name, char *lineset_name)
{
* Fix for a freeze issue in stroke rendering when using round/square caps. The problem was caused by a stroke with only one vertex. Such a stroke was generated when for some unknown reason a chained curve consisted of only two vertices such that their 3D positions were exactly or almost the same. * Fix for the Parameter Editor mode that failed when scene render layers and/or linesets contain a single quote in their names.
2010-12-06 22:17:19 +00:00
char *s1= escape_quotes(layer_name);
char *s2= escape_quotes(lineset_name);
Text *text= add_empty_text(lineset_name);
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
write_text(text, "import parameter_editor; parameter_editor.process('");
* Fix for a freeze issue in stroke rendering when using round/square caps. The problem was caused by a stroke with only one vertex. Such a stroke was generated when for some unknown reason a chained curve consisted of only two vertices such that their 3D positions were exactly or almost the same. * Fix for the Parameter Editor mode that failed when scene render layers and/or linesets contain a single quote in their names.
2010-12-06 22:17:19 +00:00
write_text(text, s1);
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
write_text(text, "', '");
* Fix for a freeze issue in stroke rendering when using round/square caps. The problem was caused by a stroke with only one vertex. Such a stroke was generated when for some unknown reason a chained curve consisted of only two vertices such that their 3D positions were exactly or almost the same. * Fix for the Parameter Editor mode that failed when scene render layers and/or linesets contain a single quote in their names.
2010-12-06 22:17:19 +00:00
write_text(text, s2);
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
write_text(text, "')\n");
* Fix for a freeze issue in stroke rendering when using round/square caps. The problem was caused by a stroke with only one vertex. Such a stroke was generated when for some unknown reason a chained curve consisted of only two vertices such that their 3D positions were exactly or almost the same. * Fix for the Parameter Editor mode that failed when scene render layers and/or linesets contain a single quote in their names.
2010-12-06 22:17:19 +00:00
MEM_freeN(s1);
MEM_freeN(s2);
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
return text;
}
soc-2008-mxcurioni: clean up
2008-08-08 08:53:13 +00:00
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
static void prepare(Render* re, SceneRenderLayer* srl ) {
soc-2008-mxcurioni: refactored Freestyle API to prepare for both rendering modes (OpenGL and Blender internal), applied a patch to allow CMake to be used for compilation.
2008-10-01 15:03:35 +00:00
// load mesh
Added changes for showing the rendering status in the status bar of the Info window.
2010-02-13 12:16:08 +00:00
re->i.infostr= "Freestyle: Mesh loading";
re->stats_draw(re->sdh, &re->i);
re->i.infostr= NULL;
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
if( controller->LoadMesh(re, srl) ) // returns if scene cannot be loaded or if empty
replaced "Shape loading" message with "Importing triangular meshes into Blender" handled case when scene is empty made controller's view map as public variable
2008-12-10 15:30:43 +00:00
return;
Added changes for escaping from rendering by pressing the ESC key. ESC key press checks are performed 1) before entering Freestyle, and 2) after the completion of the view map creation.
2010-02-13 11:37:34 +00:00
if( re->test_break(re->tbh) )
return;
soc-2008-mxcurioni: first render layer implementation with frame buffer objects. It does not work yet: I cannot manage to read from the correct buffer yet.
2008-07-05 06:22:15 +00:00
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
// add style modules
SUMMARY: 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
2009-08-04 00:40:36 +00:00
FreestyleConfig* config = &srl->freestyleConfig;
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
cout << "\n=== Rendering options ===" << endl;
int layer_count = 0;
SUMMARY: 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
2009-08-04 00:40:36 +00:00
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
switch (config->mode) {
case FREESTYLE_CONTROL_SCRIPT_MODE:
cout << "Modules :"<< endl;
for (FreestyleModuleConfig* module_conf = (FreestyleModuleConfig *)config->modules.first; module_conf; module_conf = module_conf->next) {
if( module_conf->is_displayed ) {
cout << " " << layer_count+1 << ": " << module_conf->module_path << endl;
controller->InsertStyleModule( layer_count, module_conf->module_path );
controller->toggleLayer(layer_count, true);
layer_count++;
}
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
}
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
cout << endl;
Automatic configuration of feature edge detection options. In the Parameter Editor mode, three feature edge detection options (i.e., Ridges and Valleys, Suggestive Contours, and Material Boundaries) are automatically configured based on feature edge selection settings of linesets.
2010-08-07 22:48:25 +00:00
controller->setComputeRidgesAndValleysFlag( (config->flags & FREESTYLE_RIDGES_AND_VALLEYS_FLAG) ? true : false);
controller->setComputeSuggestiveContoursFlag( (config->flags & FREESTYLE_SUGGESTIVE_CONTOURS_FLAG) ? true : false);
controller->setComputeMaterialBoundariesFlag( (config->flags & FREESTYLE_MATERIAL_BOUNDARIES_FLAG) ? true : false);
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
break;
case FREESTYLE_CONTROL_EDITOR_MODE:
Automatic configuration of feature edge detection options. In the Parameter Editor mode, three feature edge detection options (i.e., Ridges and Valleys, Suggestive Contours, and Material Boundaries) are automatically configured based on feature edge selection settings of linesets.
2010-08-07 22:48:25 +00:00
int use_ridges_and_valleys = 0;
int use_suggestive_contours = 0;
int use_material_boundaries = 0;
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
cout << "Linesets:"<< endl;
for (FreestyleLineSet *lineset = (FreestyleLineSet *)config->linesets.first; lineset; lineset = lineset->next) {
if (lineset->flags & FREESTYLE_LINESET_ENABLED) {
cout << " " << layer_count+1 << ": " << lineset->name << " - " << lineset->linestyle->id.name+2 << endl;
Text *text = create_lineset_handler(srl->name, lineset->name);
controller->InsertStyleModule( layer_count, lineset->name, text );
controller->toggleLayer(layer_count, true);
Automatic configuration of feature edge detection options. In the Parameter Editor mode, three feature edge detection options (i.e., Ridges and Valleys, Suggestive Contours, and Material Boundaries) are automatically configured based on feature edge selection settings of linesets.
2010-08-07 22:48:25 +00:00
if (!(lineset->selection & FREESTYLE_SEL_EDGE_TYPES) || !lineset->edge_types) {
++use_ridges_and_valleys;
++use_suggestive_contours;
++use_material_boundaries;
} else if (lineset->flags & FREESTYLE_LINESET_FE_NOT) {
if (!(lineset->edge_types & ~FREESTYLE_FE_RIDGE) ||
!(lineset->edge_types & ~FREESTYLE_FE_VALLEY) ||
(lineset->flags & FREESTYLE_LINESET_FE_AND))
++use_ridges_and_valleys;
if (lineset->edge_types & ~FREESTYLE_FE_SUGGESTIVE_CONTOUR)
++use_suggestive_contours;
if (lineset->edge_types & ~FREESTYLE_FE_MATERIAL_BOUNDARY)
++use_material_boundaries;
} else {
if (lineset->edge_types & (FREESTYLE_FE_RIDGE | FREESTYLE_FE_VALLEY))
++use_ridges_and_valleys;
if (lineset->edge_types & FREESTYLE_FE_SUGGESTIVE_CONTOUR)
++use_suggestive_contours;
if (lineset->edge_types & FREESTYLE_FE_MATERIAL_BOUNDARY)
++use_material_boundaries;
}
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
layer_count++;
}
}
Automatic configuration of feature edge detection options. In the Parameter Editor mode, three feature edge detection options (i.e., Ridges and Valleys, Suggestive Contours, and Material Boundaries) are automatically configured based on feature edge selection settings of linesets.
2010-08-07 22:48:25 +00:00
controller->setComputeRidgesAndValleysFlag( use_ridges_and_valleys > 0 );
controller->setComputeSuggestiveContoursFlag( use_suggestive_contours > 0 );
controller->setComputeMaterialBoundariesFlag( use_material_boundaries > 0 );
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
break;
}
soc-2008-mxcurioni: Freestyle now supports camera information (the image is still a bit larger than Blender's internal renderer, probably a field of view problem). 3d scene is now no longer rendered, only 2d scene (strokes from view map information) is. Style module is still static (contour.py), will soon be handled via independent UI panel. Phase 1 is considered finished. Phase 2 starts now: the objective is integrating Freestyle as an independent render layer.
2008-06-16 00:51:19 +00:00
Made changes to enable features line parameters (ridges/valleys and suggestive contours) and add corresponding UI controls to the Freestyle tab in the Scene buttons.
2008-11-09 13:14:41 +00:00
// set parameters
Optimized view map calculation by Alexander Beels. * View map calculation has been intensively optimized for speed by means of: 1) new spatial grid data structures (SphericalGrid for perspective cameras and BoxGrid for orthographic cameras; automatically switched based on the camera type); 2) a heuristic grid density calculation algorithm; and 3) new line visibility computation algorithms: A "traditional" algorithm for emulating old visibility algorithms, and a "cumulative" algorithm for improved, more consistent line visibility, both exploiting the new spatial grid data structures for fast ray casting. A new option "Raycasting Algorithm" was added to allow users to choose a ray casting (line visibility) algorithm. Available choices are: - Normal Ray Casting - Fast Ray Casting - Very Fast Ray Casting - Culled Traditional Visibility Detection - Unculled Traditional Visibility Detection - Culled Cumulative Visibility Detection - Unculled Cumulative Visibility Detection The first three algorithms are those available in the original Freestyle (the "normal" ray casting was used unconditionally, though). The "fast" and "very fast" ray casting algorithms achieve a faster calculation at the cost of less visibility accuracy. The last four are newly introduced optimized options. The culled versions of the new algorithms will exclude from visibility calculation those faces that lay outside the camera, which leads to a faster view map construction. The unculled counterparts will take all faces into account. The unculled visibility algorithms are useful when culling affects stroke chaining. The recommended options for users are the culled/unculled cumulative visibility algorithms. These options are meant to replace the old algorithms in the future. Performance improvements over the old algorithms depend on the scenes to be rendered. * Silhouette detection has also been considerably optimized for speed. Performance gains by this optimization do not depend on scenes. * Improper handling of error conditions in the view map construction was fixed.
2011-03-14 00:36:27 +00:00
controller->setFaceSmoothness( (config->flags & FREESTYLE_FACE_SMOOTHNESS_FLAG) ? true : false);
New option to specify the angular threshold for detecting crease edges. An entry "Crease Angle" has been added to the Layers tab of the Render buttons, to allow users to specify an angle (between 0 and 180) used for crease edge detection. An edge is considered a crease edge if the angle between two faces sharing the edge is smaller than the threshold. The default value is 134.43 degrees (for backward compatibility). Be aware that a larger threshold leads to a larger number of feature edges and thus a larger memory consumption.
2010-05-22 23:56:42 +00:00
controller->setCreaseAngle( config->crease_angle );
SUMMARY: 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
2009-08-04 00:40:36 +00:00
controller->setSphereRadius( config->sphere_radius );
controller->setSuggestiveContourKrDerivativeEpsilon( config->dkr_epsilon ) ;
Optimized view map calculation by Alexander Beels. * View map calculation has been intensively optimized for speed by means of: 1) new spatial grid data structures (SphericalGrid for perspective cameras and BoxGrid for orthographic cameras; automatically switched based on the camera type); 2) a heuristic grid density calculation algorithm; and 3) new line visibility computation algorithms: A "traditional" algorithm for emulating old visibility algorithms, and a "cumulative" algorithm for improved, more consistent line visibility, both exploiting the new spatial grid data structures for fast ray casting. A new option "Raycasting Algorithm" was added to allow users to choose a ray casting (line visibility) algorithm. Available choices are: - Normal Ray Casting - Fast Ray Casting - Very Fast Ray Casting - Culled Traditional Visibility Detection - Unculled Traditional Visibility Detection - Culled Cumulative Visibility Detection - Unculled Cumulative Visibility Detection The first three algorithms are those available in the original Freestyle (the "normal" ray casting was used unconditionally, though). The "fast" and "very fast" ray casting algorithms achieve a faster calculation at the cost of less visibility accuracy. The last four are newly introduced optimized options. The culled versions of the new algorithms will exclude from visibility calculation those faces that lay outside the camera, which leads to a faster view map construction. The unculled counterparts will take all faces into account. The unculled visibility algorithms are useful when culling affects stroke chaining. The recommended options for users are the culled/unculled cumulative visibility algorithms. These options are meant to replace the old algorithms in the future. Performance improvements over the old algorithms depend on the scenes to be rendered. * Silhouette detection has also been considerably optimized for speed. Performance gains by this optimization do not depend on scenes. * Improper handling of error conditions in the view map construction was fixed.
2011-03-14 00:36:27 +00:00
controller->setVisibilityAlgo( config->raycasting_algorithm );
Made changes to enable features line parameters (ridges/valleys and suggestive contours) and add corresponding UI controls to the Freestyle tab in the Scene buttons.
2008-11-09 13:14:41 +00:00
New option to specify the angular threshold for detecting crease edges. An entry "Crease Angle" has been added to the Layers tab of the Render buttons, to allow users to specify an angle (between 0 and 180) used for crease edge detection. An edge is considered a crease edge if the angle between two faces sharing the edge is smaller than the threshold. The default value is 134.43 degrees (for backward compatibility). Be aware that a larger threshold leads to a larger number of feature edges and thus a larger memory consumption.
2010-05-22 23:56:42 +00:00
cout << "Crease angle : " << controller->getCreaseAngle() << endl;
Made changes to enable features line parameters (ridges/valleys and suggestive contours) and add corresponding UI controls to the Freestyle tab in the Scene buttons.
2008-11-09 13:14:41 +00:00
cout << "Sphere radius : " << controller->getSphereRadius() << endl;
Optimized view map calculation by Alexander Beels. * View map calculation has been intensively optimized for speed by means of: 1) new spatial grid data structures (SphericalGrid for perspective cameras and BoxGrid for orthographic cameras; automatically switched based on the camera type); 2) a heuristic grid density calculation algorithm; and 3) new line visibility computation algorithms: A "traditional" algorithm for emulating old visibility algorithms, and a "cumulative" algorithm for improved, more consistent line visibility, both exploiting the new spatial grid data structures for fast ray casting. A new option "Raycasting Algorithm" was added to allow users to choose a ray casting (line visibility) algorithm. Available choices are: - Normal Ray Casting - Fast Ray Casting - Very Fast Ray Casting - Culled Traditional Visibility Detection - Unculled Traditional Visibility Detection - Culled Cumulative Visibility Detection - Unculled Cumulative Visibility Detection The first three algorithms are those available in the original Freestyle (the "normal" ray casting was used unconditionally, though). The "fast" and "very fast" ray casting algorithms achieve a faster calculation at the cost of less visibility accuracy. The last four are newly introduced optimized options. The culled versions of the new algorithms will exclude from visibility calculation those faces that lay outside the camera, which leads to a faster view map construction. The unculled counterparts will take all faces into account. The unculled visibility algorithms are useful when culling affects stroke chaining. The recommended options for users are the culled/unculled cumulative visibility algorithms. These options are meant to replace the old algorithms in the future. Performance improvements over the old algorithms depend on the scenes to be rendered. * Silhouette detection has also been considerably optimized for speed. Performance gains by this optimization do not depend on scenes. * Improper handling of error conditions in the view map construction was fixed.
2011-03-14 00:36:27 +00:00
cout << "Face smoothness : " << (controller->getFaceSmoothness() ? "enabled" : "disabled") << endl;
Made changes to enable features line parameters (ridges/valleys and suggestive contours) and add corresponding UI controls to the Freestyle tab in the Scene buttons.
2008-11-09 13:14:41 +00:00
cout << "Redges and valleys : " << (controller->getComputeRidgesAndValleysFlag() ? "enabled" : "disabled") << endl;
cout << "Suggestive contours : " << (controller->getComputeSuggestiveContoursFlag() ? "enabled" : "disabled") << endl;
Automatic configuration of feature edge detection options. In the Parameter Editor mode, three feature edge detection options (i.e., Ridges and Valleys, Suggestive Contours, and Material Boundaries) are automatically configured based on feature edge selection settings of linesets.
2010-08-07 22:48:25 +00:00
cout << "Suggestive contour Kr derivative epsilon : " << controller->getSuggestiveContourKrDerivativeEpsilon() << endl;
cout << "Material boundaries : " << (controller->getComputeMaterialBoundariesFlag() ? "enabled" : "disabled") << endl;
Added support for pixel-based density and Z depth information. Availability of pixel-based density and Z depth information depends on passes of a render layer being rendered. - Density information is available if the diffuse pass of the render layer is enabled. It is accessible through the DensityF0D and DensityF1D functions provided by the Freestyle Python API. These functions return 0 if the diffuse pass is disabled. - Z depth information is available if the Z pass is enabled. It can be accessed through LocalAverageDepthF0D and LocalAverageDepthF1D. These functions return 0 if the Z pass is disabled.
2010-02-14 03:17:52 +00:00
cout << endl;
// set diffuse and z depth passes
RenderLayer *rl = RE_GetRenderLayer(re->result, srl->name);
Fixed bugs in AppCanvas::readColorPixels() and AppCanvas::readDepthPixels() that caused a crash when the aspect ratio was not 1:1.
2010-02-16 21:44:18 +00:00
bool diffuse = false, z = false;
for (RenderPass *rpass = (RenderPass *)rl->passes.first; rpass; rpass = rpass->next) {
switch (rpass->passtype) {
case SCE_PASS_DIFFUSE:
controller->setPassDiffuse(rpass->rect, rpass->rectx, rpass->recty);
diffuse = true;
break;
case SCE_PASS_Z:
controller->setPassZ(rpass->rect, rpass->rectx, rpass->recty);
z = true;
break;
}
}
Added support for pixel-based density and Z depth information. Availability of pixel-based density and Z depth information depends on passes of a render layer being rendered. - Density information is available if the diffuse pass of the render layer is enabled. It is accessible through the DensityF0D and DensityF1D functions provided by the Freestyle Python API. These functions return 0 if the diffuse pass is disabled. - Z depth information is available if the Z pass is enabled. It can be accessed through LocalAverageDepthF0D and LocalAverageDepthF1D. These functions return 0 if the Z pass is disabled.
2010-02-14 03:17:52 +00:00
cout << "Passes :" << endl;
cout << " Diffuse = " << (diffuse ? "enabled" : "disabled") << endl;
cout << " Z = " << (z ? "enabled" : "disabled") << endl;
Made changes to enable features line parameters (ridges/valleys and suggestive contours) and add corresponding UI controls to the Freestyle tab in the Scene buttons.
2008-11-09 13:14:41 +00:00
soc-2008-mxcurioni: Freestyle now supports camera information (the image is still a bit larger than Blender's internal renderer, probably a field of view problem). 3d scene is now no longer rendered, only 2d scene (strokes from view map information) is. Style module is still static (contour.py), will soon be handled via independent UI panel. Phase 1 is considered finished. Phase 2 starts now: the objective is integrating Freestyle as an independent render layer.
2008-06-16 00:51:19 +00:00
// compute view map
Added changes for showing the rendering status in the status bar of the Info window.
2010-02-13 12:16:08 +00:00
re->i.infostr= "Freestyle: View map creation";
re->stats_draw(re->sdh, &re->i);
re->i.infostr= NULL;
soc-2008-mxcurioni: now supports current scene drawing (instead of fixed scene object), still with fixed style and fixed camera. Initialization is properly handled, which limits memory problems and speed-ups subsequent rendering. The viewing ratio should be correct now too. I also removed linking references to former lib3ds library path (caused some linking problems).
2008-06-08 19:35:20 +00:00
controller->ComputeViewMap();
soc-2008-mxcurioni: uploaded missing files. Still NOT linking so do not use this version yet :(
2008-05-19 05:34:31 +00:00
}
The GL-based renderer was removed. Freestyle now uses Blender's internal renderer to raster strokes. 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.
2008-12-01 21:30:44 +00:00
Fixed the full sample anti-aliasing support in Freestyle. 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.
2010-03-28 17:46:10 +00:00
void FRS_composite_result(Render* re, SceneRenderLayer* srl, Render* freestyle_render)
Freestyle was changed from a tile-based process to a post-processing effect. This will allow style modules to process the underlying color buffer ( AppCanvas::readColorPixels ) and depth buffer ( AppCanvas::readDepthPixels ), as was supported in the original program. Corrected crash when Freestyle is rendered in "Single" render layer mode (for example, in the compositor)
2009-03-22 16:25:14 +00:00
{
RenderLayer *rl;
float *src, *dest, *pixSrc, *pixDest;
Second attempt to fix the border option. At the moment, accessing diffuse and Z depth information through style modules won't work correctly with the border option. Another fix will follow.
2010-03-30 00:41:26 +00:00
int x, y, rectx, recty;
Freestyle was changed from a tile-based process to a post-processing effect. This will allow style modules to process the underlying color buffer ( AppCanvas::readColorPixels ) and depth buffer ( AppCanvas::readDepthPixels ), as was supported in the original program. Corrected crash when Freestyle is rendered in "Single" render layer mode (for example, in the compositor)
2009-03-22 16:25:14 +00:00
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
if( freestyle_render == NULL || freestyle_render->result == NULL )
Freestyle was changed from a tile-based process to a post-processing effect. This will allow style modules to process the underlying color buffer ( AppCanvas::readColorPixels ) and depth buffer ( AppCanvas::readDepthPixels ), as was supported in the original program. Corrected crash when Freestyle is rendered in "Single" render layer mode (for example, in the compositor)
2009-03-22 16:25:14 +00:00
return;
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
rl = render_get_active_layer( freestyle_render, freestyle_render->result );
Freestyle was changed from a tile-based process to a post-processing effect. This will allow style modules to process the underlying color buffer ( AppCanvas::readColorPixels ) and depth buffer ( AppCanvas::readDepthPixels ), as was supported in the original program. Corrected crash when Freestyle is rendered in "Single" render layer mode (for example, in the compositor)
2009-03-22 16:25:14 +00:00
if( !rl || rl->rectf == NULL) { cout << "Cannot find Freestyle result image" << endl; return; }
src = rl->rectf;
Second attempt to fix the border option. At the moment, accessing diffuse and Z depth information through style modules won't work correctly with the border option. Another fix will follow.
2010-03-30 00:41:26 +00:00
//cout << "src: " << rl->rectx << " x " << rl->recty << endl;
Freestyle was changed from a tile-based process to a post-processing effect. This will allow style modules to process the underlying color buffer ( AppCanvas::readColorPixels ) and depth buffer ( AppCanvas::readDepthPixels ), as was supported in the original program. Corrected crash when Freestyle is rendered in "Single" render layer mode (for example, in the compositor)
2009-03-22 16:25:14 +00:00
rl = RE_GetRenderLayer(re->result, srl->name);
if( !rl || rl->rectf == NULL) { cout << "No layer to composite to" << endl; return; }
dest = rl->rectf;
Second attempt to fix the border option. At the moment, accessing diffuse and Z depth information through style modules won't work correctly with the border option. Another fix will follow.
2010-03-30 00:41:26 +00:00
//cout << "dest: " << rl->rectx << " x " << rl->recty << endl;
rectx = re->rectx;
recty = re->recty;
for( y = 0; y < recty; y++) {
for( x = 0; x < rectx; x++) {
pixSrc = src + 4 * (rectx * y + x);
Freestyle was changed from a tile-based process to a post-processing effect. This will allow style modules to process the underlying color buffer ( AppCanvas::readColorPixels ) and depth buffer ( AppCanvas::readDepthPixels ), as was supported in the original program. Corrected crash when Freestyle is rendered in "Single" render layer mode (for example, in the compositor)
2009-03-22 16:25:14 +00:00
if( pixSrc[3] > 0.0) {
Second attempt to fix the border option. At the moment, accessing diffuse and Z depth information through style modules won't work correctly with the border option. Another fix will follow.
2010-03-30 00:41:26 +00:00
pixDest = dest + 4 * (rectx * y + x);
Freestyle was changed from a tile-based process to a post-processing effect. This will allow style modules to process the underlying color buffer ( AppCanvas::readColorPixels ) and depth buffer ( AppCanvas::readDepthPixels ), as was supported in the original program. Corrected crash when Freestyle is rendered in "Single" render layer mode (for example, in the compositor)
2009-03-22 16:25:14 +00:00
addAlphaOverFloat(pixDest, pixSrc);
Fixed the border option that was not functional when the crop option was turned off.
2010-03-29 21:58:58 +00:00
}
}
Freestyle was changed from a tile-based process to a post-processing effect. This will allow style modules to process the underlying color buffer ( AppCanvas::readColorPixels ) and depth buffer ( AppCanvas::readDepthPixels ), as was supported in the original program. Corrected crash when Freestyle is rendered in "Single" render layer mode (for example, in the compositor)
2009-03-22 16:25:14 +00:00
}
}
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
static int displayed_layer_count( SceneRenderLayer* srl ) {
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
int count = 0;
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
switch (srl->freestyleConfig.mode) {
case FREESTYLE_CONTROL_SCRIPT_MODE:
for (FreestyleModuleConfig* module = (FreestyleModuleConfig *)srl->freestyleConfig.modules.first; module; module = module->next) {
if( module->is_displayed )
count++;
}
break;
case FREESTYLE_CONTROL_EDITOR_MODE:
for (FreestyleLineSet *lineset = (FreestyleLineSet *)srl->freestyleConfig.linesets.first; lineset; lineset = lineset->next) {
if (lineset->flags & FREESTYLE_LINESET_ENABLED)
count++;
}
break;
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
}
return count;
}
Fixed the full sample anti-aliasing support in Freestyle. 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.
2010-03-28 17:46:10 +00:00
int FRS_is_freestyle_enabled(SceneRenderLayer* srl) {
return (!(srl->layflag & SCE_LAY_DISABLE) &&
srl->layflag & SCE_LAY_FRS &&
displayed_layer_count(srl) > 0);
}
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
Fixed the full sample anti-aliasing support in Freestyle. 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.
2010-03-28 17:46:10 +00:00
void FRS_init_stroke_rendering(Render* re) {
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
cout << "\n#===============================================================" << endl;
cout << "# Freestyle" << endl;
cout << "#===============================================================" << endl;
init_view(re);
init_camera(re);
Fixed the full sample anti-aliasing support in Freestyle. 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.
2010-03-28 17:46:10 +00:00
controller->ResetRenderCount();
}
Render* FRS_do_stroke_rendering(Render* re, SceneRenderLayer *srl) {
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
Fixed the full sample anti-aliasing support in Freestyle. 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.
2010-03-28 17:46:10 +00:00
Render* freestyle_render = NULL;
Freestyle was changed from a tile-based process to a post-processing effect. This will allow style modules to process the underlying color buffer ( AppCanvas::readColorPixels ) and depth buffer ( AppCanvas::readDepthPixels ), as was supported in the original program. Corrected crash when Freestyle is rendered in "Single" render layer mode (for example, in the compositor)
2009-03-22 16:25:14 +00:00
Fixed the full sample anti-aliasing support in Freestyle. 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.
2010-03-28 17:46:10 +00:00
cout << "\n----------------------------------------------------------" << endl;
cout << "| " << (re->scene->id.name+2) << "|" << srl->name << endl;
cout << "----------------------------------------------------------" << endl;
// prepare Freestyle:
// - load mesh
// - add style modules
// - set parameters
// - compute view map
prepare(re, srl);
if( re->test_break(re->tbh) ) {
controller->CloseFile();
return NULL;
}
// render and composite Freestyle result
if( controller->_ViewMap ) {
// render strokes
re->i.infostr= "Freestyle: Stroke rendering";
re->stats_draw(re->sdh, &re->i);
re->i.infostr= NULL;
freestyle_scene = re->scene;
controller->DrawStrokes();
freestyle_render = controller->RenderStrokes(re);
controller->CloseFile();
freestyle_scene = NULL;
// composite result
FRS_composite_result(re, srl, freestyle_render);
RE_FreeRenderResult(freestyle_render->result);
freestyle_render->result = NULL;
}
return freestyle_render;
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
}
* Implemented the basic stroke rendering functionality for the new 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.
2010-07-26 01:23:27 +00:00
void FRS_finish_stroke_rendering(Render* re) {
// clear canvas
controller->Clear();
}
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
//=======================================================
// Freestyle Panel Configuration
//=======================================================
SUMMARY: 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
2009-08-04 00:40:36 +00:00
void FRS_add_freestyle_config( SceneRenderLayer* srl )
{
FreestyleConfig* config = &srl->freestyleConfig;
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
A step toward a new user-friendly GUI for manipulating line style parameters. 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.
2010-06-25 22:45:42 +00:00
config->mode = FREESTYLE_CONTROL_SCRIPT_MODE;
SUMMARY: 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
2009-08-04 00:40:36 +00:00
config->modules.first = config->modules.last = NULL;
config->flags = 0;
More on the new GUI for the Parameter Editor mode. This is a WIP commit. * Moved render layer-specific Freestyle options to a separate "Freestyle" tab (in addition to the "Freestyle: Line Style" tab that has been introduced in the previous commit). * Added UI controls for specifying feature edge selection criteria in the Parameter Editor mode. Feature edge selection starts with a set of all feature edges in the view map. Each line set specifies edge selection criteria (e.g., to select only visible crease edges) by enabling appropriate UI controls (e.g., by turning on the "Crease" and "Visibility" toggle buttons). Selected criteria are combined by logical conjunction. Logical disjunction (e.g., "crease edges or contours") is represented by two or more line sets. * Slightly rearranged several UI controls in the Python Scripting mode.
2010-06-27 00:03:34 +00:00
config->sphere_radius = 1.0f;
config->dkr_epsilon = 0.001f;
config->crease_angle = 134.43f;
A step toward a new user-friendly GUI for manipulating line style parameters. 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.
2010-06-25 22:45:42 +00:00
config->linesets.first = config->linesets.last = NULL;
Optimized view map calculation by Alexander Beels. * View map calculation has been intensively optimized for speed by means of: 1) new spatial grid data structures (SphericalGrid for perspective cameras and BoxGrid for orthographic cameras; automatically switched based on the camera type); 2) a heuristic grid density calculation algorithm; and 3) new line visibility computation algorithms: A "traditional" algorithm for emulating old visibility algorithms, and a "cumulative" algorithm for improved, more consistent line visibility, both exploiting the new spatial grid data structures for fast ray casting. A new option "Raycasting Algorithm" was added to allow users to choose a ray casting (line visibility) algorithm. Available choices are: - Normal Ray Casting - Fast Ray Casting - Very Fast Ray Casting - Culled Traditional Visibility Detection - Unculled Traditional Visibility Detection - Culled Cumulative Visibility Detection - Unculled Cumulative Visibility Detection The first three algorithms are those available in the original Freestyle (the "normal" ray casting was used unconditionally, though). The "fast" and "very fast" ray casting algorithms achieve a faster calculation at the cost of less visibility accuracy. The last four are newly introduced optimized options. The culled versions of the new algorithms will exclude from visibility calculation those faces that lay outside the camera, which leads to a faster view map construction. The unculled counterparts will take all faces into account. The unculled visibility algorithms are useful when culling affects stroke chaining. The recommended options for users are the culled/unculled cumulative visibility algorithms. These options are meant to replace the old algorithms in the future. Performance improvements over the old algorithms depend on the scenes to be rendered. * Silhouette detection has also been considerably optimized for speed. Performance gains by this optimization do not depend on scenes. * Improper handling of error conditions in the view map construction was fixed.
2011-03-14 00:36:27 +00:00
config->raycasting_algorithm = FREESTYLE_ALGO_REGULAR;
SUMMARY: 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
2009-08-04 00:40:36 +00:00
}
void FRS_free_freestyle_config( SceneRenderLayer* srl )
{
A step toward a new user-friendly GUI for manipulating line style parameters. 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.
2010-06-25 22:45:42 +00:00
FreestyleLineSet *lineset;
for(lineset=(FreestyleLineSet *)srl->freestyleConfig.linesets.first; lineset; lineset=lineset->next) {
Fix for the Link/Append commands not working when scenes had line styles. The problem was reported by mato.sus304, thank you!
2011-09-15 00:06:49 +00:00
if (lineset->group) {
lineset->group->id.us--;
lineset->group = NULL;
}
A step toward a new user-friendly GUI for manipulating line style parameters. 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.
2010-06-25 22:45:42 +00:00
lineset->linestyle->id.us--;
lineset->linestyle = NULL;
}
BLI_freelistN( &srl->freestyleConfig.linesets );
SUMMARY: 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
2009-08-04 00:40:36 +00:00
BLI_freelistN( &srl->freestyleConfig.modules );
Freestyle was changed from a tile-based process to a post-processing effect. This will allow style modules to process the underlying color buffer ( AppCanvas::readColorPixels ) and depth buffer ( AppCanvas::readDepthPixels ), as was supported in the original program. Corrected crash when Freestyle is rendered in "Single" render layer mode (for example, in the compositor)
2009-03-22 16:25:14 +00:00
}
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
* Removed a back pointer to a Scene (the "current" scene as in Blender 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.
2009-11-01 01:11:15 +00:00
void FRS_add_module(FreestyleConfig *config)
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
{
SUMMARY: 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
2009-08-04 00:40:36 +00:00
FreestyleModuleConfig* module_conf = (FreestyleModuleConfig*) MEM_callocN( sizeof(FreestyleModuleConfig), "style module configuration");
* Removed a back pointer to a Scene (the "current" scene as in Blender 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.
2009-11-01 01:11:15 +00:00
BLI_addtail(&config->modules, (void*) module_conf);
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
strcpy( module_conf->module_path, default_module_path.c_str() );
module_conf->is_displayed = 1;
}
* Removed a back pointer to a Scene (the "current" scene as in Blender 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.
2009-11-01 01:11:15 +00:00
void FRS_delete_module(FreestyleConfig *config, FreestyleModuleConfig *module_conf)
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
{
* Removed a back pointer to a Scene (the "current" scene as in Blender 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.
2009-11-01 01:11:15 +00:00
BLI_freelinkN(&config->modules, module_conf);
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
}
A step toward a new user-friendly GUI for manipulating line style parameters. 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.
2010-06-25 22:45:42 +00:00
void FRS_move_module_up(FreestyleConfig *config, FreestyleModuleConfig *module_conf)
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
{
* Removed a back pointer to a Scene (the "current" scene as in Blender 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.
2009-11-01 01:11:15 +00:00
BLI_remlink(&config->modules, module_conf);
A step toward a new user-friendly GUI for manipulating line style parameters. 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.
2010-06-25 22:45:42 +00:00
BLI_insertlinkbefore(&config->modules, module_conf->prev, module_conf);
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
}
A step toward a new user-friendly GUI for manipulating line style parameters. 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.
2010-06-25 22:45:42 +00:00
void FRS_move_module_down(FreestyleConfig *config, FreestyleModuleConfig *module_conf)
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
{
* Removed a back pointer to a Scene (the "current" scene as in Blender 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.
2009-11-01 01:11:15 +00:00
BLI_remlink(&config->modules, module_conf);
A step toward a new user-friendly GUI for manipulating line style parameters. 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.
2010-06-25 22:45:42 +00:00
BLI_insertlinkafter(&config->modules, module_conf->next, module_conf);
}
void FRS_add_lineset(FreestyleConfig *config)
{
int lineset_index = BLI_countlist(&config->linesets);
FreestyleLineSet *lineset = (FreestyleLineSet *) MEM_callocN( sizeof(FreestyleLineSet), "Freestyle line set");
BLI_addtail(&config->linesets, (void *) lineset);
FRS_set_active_lineset_index(config, lineset_index);
lineset->linestyle = FRS_new_linestyle("LineStyle", NULL);
lineset->flags |= FREESTYLE_LINESET_ENABLED;
A few attempts to reduce the amount of memory consumption in Freestyle. * Made changes to the Controller so that dynamically allocated memory areas (e.g. imported mesh data, winged edges, and a view map) are released soon after they become unnecessary. * Added a new feature edge selection criterion based on image border. When the "Selection by Image Border" option is enabled, feature edges are selected only if they are within the border of the image being rendered. The border is defined either by the frame size or a border region (specified by the Shift-B key in a 3D View window). When large scenes are rendered, this clipping by the image border leads to less memory consumption. * Enabled the "Silhouette", "Border", and "Crease" edge types of the Selection by Edge Types option by default. When no edge types are specified, all feature edges including "Ridge", "Valley" and "Suggestive Contour" are detected at the cost of extra memory consumption. Disabling these three edge types and enabling some other edge type leads to less memory consumption. This change is intended to help new Freestyle users by providing a typical, low memory consumption default setting. * Slightly rearranged the UI controls for feature edge selection.
2010-12-03 23:17:49 +00:00
lineset->selection = FREESTYLE_SEL_IMAGE_BORDER;
More on the new GUI for the Parameter Editor mode. This is a WIP commit. * Moved render layer-specific Freestyle options to a separate "Freestyle" tab (in addition to the "Freestyle: Line Style" tab that has been introduced in the previous commit). * Added UI controls for specifying feature edge selection criteria in the Parameter Editor mode. Feature edge selection starts with a set of all feature edges in the view map. Each line set specifies edge selection criteria (e.g., to select only visible crease edges) by enabling appropriate UI controls (e.g., by turning on the "Crease" and "Visibility" toggle buttons). Selected criteria are combined by logical conjunction. Logical disjunction (e.g., "crease edges or contours") is represented by two or more line sets. * Slightly rearranged several UI controls in the Python Scripting mode.
2010-06-27 00:03:34 +00:00
lineset->qi = FREESTYLE_QI_VISIBLE;
lineset->qi_start = 0;
lineset->qi_end = 100;
A few attempts to reduce the amount of memory consumption in Freestyle. * Made changes to the Controller so that dynamically allocated memory areas (e.g. imported mesh data, winged edges, and a view map) are released soon after they become unnecessary. * Added a new feature edge selection criterion based on image border. When the "Selection by Image Border" option is enabled, feature edges are selected only if they are within the border of the image being rendered. The border is defined either by the frame size or a border region (specified by the Shift-B key in a 3D View window). When large scenes are rendered, this clipping by the image border leads to less memory consumption. * Enabled the "Silhouette", "Border", and "Crease" edge types of the Selection by Edge Types option by default. When no edge types are specified, all feature edges including "Ridge", "Valley" and "Suggestive Contour" are detected at the cost of extra memory consumption. Disabling these three edge types and enabling some other edge type leads to less memory consumption. This change is intended to help new Freestyle users by providing a typical, low memory consumption default setting. * Slightly rearranged the UI controls for feature edge selection.
2010-12-03 23:17:49 +00:00
lineset->edge_types = FREESTYLE_FE_SILHOUETTE | FREESTYLE_FE_BORDER | FREESTYLE_FE_CREASE;
New feature edge selection criterion based on object groups. The Freestyle tab in the Render buttons has a couple of new options "Group" and "Group Negation". The Group option specifies a group of objects (defined through the Groups tab in the Object buttons), while the Group Negation value is either INCLUSIVE or EXCLUSIVE. If INCLUSIVE, feature edges belonging to some object in the group are selected. Otherwise, those feature edges not belonging to any object in the group are selected.
2010-12-02 23:50:10 +00:00
lineset->group = NULL;
A step toward a new user-friendly GUI for manipulating line style parameters. 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.
2010-06-25 22:45:42 +00:00
if (lineset_index > 0)
sprintf(lineset->name, "LineSet %i", lineset_index+1);
else
strcpy(lineset->name, "LineSet");
Replaced offsetof by BLI_STRUCT_OFFSET.
2010-07-20 17:38:09 +00:00
BLI_uniquename(&config->linesets, lineset, "FreestyleLineSet", '.', BLI_STRUCT_OFFSET(FreestyleLineSet, name), sizeof(lineset->name));
A step toward a new user-friendly GUI for manipulating line style parameters. 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.
2010-06-25 22:45:42 +00:00
}
void FRS_delete_active_lineset(FreestyleConfig *config)
{
FreestyleLineSet *lineset = FRS_get_active_lineset(config);
if (lineset) {
Fix for the Link/Append commands not working when scenes had line styles. The problem was reported by mato.sus304, thank you!
2011-09-15 00:06:49 +00:00
if (lineset->group) {
lineset->group->id.us--;
lineset->group = NULL;
}
A step toward a new user-friendly GUI for manipulating line style parameters. 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.
2010-06-25 22:45:42 +00:00
lineset->linestyle->id.us--;
lineset->linestyle = NULL;
BLI_remlink(&config->linesets, lineset);
MEM_freeN(lineset);
FRS_set_active_lineset_index(config, 0);
}
}
void FRS_move_active_lineset_up(FreestyleConfig *config)
{
FreestyleLineSet *lineset = FRS_get_active_lineset(config);
if (lineset) {
BLI_remlink(&config->linesets, lineset);
BLI_insertlinkbefore(&config->linesets, lineset->prev, lineset);
}
}
void FRS_move_active_lineset_down(FreestyleConfig *config)
{
FreestyleLineSet *lineset = FRS_get_active_lineset(config);
if (lineset) {
BLI_remlink(&config->linesets, lineset);
BLI_insertlinkafter(&config->linesets, lineset->next, lineset);
}
}
FreestyleLineSet *FRS_get_active_lineset(FreestyleConfig *config)
{
FreestyleLineSet *lineset;
for(lineset=(FreestyleLineSet *)config->linesets.first; lineset; lineset=lineset->next)
if(lineset->flags & FREESTYLE_LINESET_CURRENT)
return lineset;
return NULL;
}
short FRS_get_active_lineset_index(FreestyleConfig *config)
{
FreestyleLineSet *lineset;
short i;
for(lineset=(FreestyleLineSet *)config->linesets.first, i=0; lineset; lineset=lineset->next, i++)
if(lineset->flags & FREESTYLE_LINESET_CURRENT)
return i;
return 0;
}
void FRS_set_active_lineset_index(FreestyleConfig *config, short index)
{
FreestyleLineSet *lineset;
short i;
for(lineset=(FreestyleLineSet *)config->linesets.first, i=0; lineset; lineset=lineset->next, i++) {
if(i == index)
lineset->flags |= FREESTYLE_LINESET_CURRENT;
else
lineset->flags &= ~FREESTYLE_LINESET_CURRENT;
}
SUMMARY: 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.
2009-04-07 18:38:23 +00:00
}
* Removed a back pointer to a Scene (the "current" scene as in Blender 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.
2009-11-01 01:11:15 +00:00
Fix for properly unlinking target object pointers when objects are deleted from scenes.
2010-11-29 21:24:55 +00:00
void FRS_unlink_target_object(FreestyleConfig *config, Object *ob)
{
FreestyleLineSet *lineset;
for(lineset=(FreestyleLineSet *)config->linesets.first; lineset; lineset=lineset->next) {
FRS_unlink_linestyle_target_object(lineset->linestyle, ob);
}
}
soc-2008-mxcurioni: uploaded missing files. Still NOT linking so do not use this version yet :(
2008-05-19 05:34:31 +00:00
#ifdef __cplusplus
}
#endif
Copy Permalink