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
ff110c17f705976435ee14f2cde9c85f7334a56c
blender-archive/source/blender/freestyle/intern/app_blender/FRS_freestyle.cpp

387 lines
11 KiB
C++
Raw Normal View History

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
#include "AppView.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
#include "Controller.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
#include "AppConfig.h"
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
#include "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"
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 "DNA_listBase.h"
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
#include "DNA_scene_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
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 "BKE_global.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"
soc-2008-mxcurioni: first version of lib3ds code. It does NOT work yet and has to be debugged. It can be activate in app_blender/api.cpp by replacing the FRS_scene_3ds_export call in FRS_prepare, by FRS_load_mesh. All of the reference to the original Material class were renamed to FrsMaterial to resolve a name collision with Blender. To keep the window context necessary to draw the strokes after RE_Database_FromScene has been called, the display_clear function is used.
2008-08-07 15:04:25 +00:00
#include "BIF_renderwin.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 "render_types.h"
#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"
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
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
// Panel configuration
short freestyle_current_layer_number = 0;
char* freestyle_current_module_path = NULL;
SceneRenderLayer* freestyle_current_layer = NULL;
ListBase* freestyle_modules;
int* freestyle_flags;
float* freestyle_sphere_radius;
float* freestyle_dkr_epsilon;
class FreestylePanelConfigurationData {
public:
set<SceneRenderLayer*> layers;
map<SceneRenderLayer*, ListBase*> modules;
map<SceneRenderLayer*, int*> flags;
map<SceneRenderLayer*, float*> sphere_radius;
map<SceneRenderLayer*, float*> dkr_epsilon;
FreestylePanelConfigurationData() {}
~FreestylePanelConfigurationData() {
set<SceneRenderLayer*>::iterator it;
for( it=layers.begin(); it!=layers.end(); it++)
FRS_delete_layer( *it, 1 );
}
};
static FreestylePanelConfigurationData* panelConfig;
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
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
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
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_is_initialized ) {
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
pathconfig = new Config::Path;
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 = new Controller;
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
view = new AppView;
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
controller->setView(view);
Fixed a bug that the parameter panel did not correctly work when a new file was created or an existing file was loaded.
2009-07-18 18:33:07 +00:00
} else {
delete panelConfig;
}
panelConfig = new FreestylePanelConfigurationData;
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 a bug that the parameter panel did not correctly work when a new file was created or an existing file was loaded.
2009-07-18 18:33:07 +00:00
default_module_path = pathconfig->getProjectDir() + Config::DIR_SEP + "style_modules" + Config::DIR_SEP + "contour.py";
FRS_select_layer( (SceneRenderLayer*) BLI_findlink(&G.scene->r.layers, G.scene->r.actlay) );
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 a bug that the parameter panel did not correctly work when a new file was created or an existing file was loaded.
2009-07-18 18:33:07 +00:00
freestyle_is_initialized = 1;
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
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 a bug that the parameter panel did not correctly work when a new file was created or an existing file was loaded.
2009-07-18 18:33:07 +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
void FRS_exit() {
delete pathconfig;
delete controller;
delete view;
delete panelConfig;
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
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 init_view(Render* re){
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
int width = re->scene->r.xsch;
int height = re->scene->r.ysch;
freestyle_viewport[0] = freestyle_viewport[1] = 0;
freestyle_viewport[2] = width;
freestyle_viewport[3] = height;
view->setWidth( width );
view->setHeight( height );
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
void init_camera(Render* re){
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
Object* maincam_obj = re->scene->camera;
Simplified modelview matrix copy (take 2)
2009-04-12 07:12:59 +00:00
// Camera *cam = (Camera*) maincam_obj->data;
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_viewpoint[0] = maincam_obj->obmat[3][0];
freestyle_viewpoint[1] = maincam_obj->obmat[3][1];
freestyle_viewpoint[2] = maincam_obj->obmat[3][2];
Simplified modelview matrix copy
2009-04-12 07:02:03 +00:00
// freestyle_mv[0][0] = maincam_obj->obmat[0][0];
// freestyle_mv[0][1] = maincam_obj->obmat[1][0];
// freestyle_mv[0][2] = maincam_obj->obmat[2][0];
// freestyle_mv[0][3] = 0.0;
//
// freestyle_mv[1][0] = maincam_obj->obmat[0][1];
// freestyle_mv[1][1] = maincam_obj->obmat[1][1];
// freestyle_mv[1][2] = maincam_obj->obmat[2][1];
// freestyle_mv[1][3] = 0.0;
//
// freestyle_mv[2][0] = re->viewmat[2][0];
// freestyle_mv[2][1] = re->viewmat[2][1];
// freestyle_mv[2][2] = re->viewmat[2][2];
// freestyle_mv[2][3] = 0.0;
//
// freestyle_mv[3][0] = re->viewmat[3][0];
// freestyle_mv[3][1] = re->viewmat[3][1];
// freestyle_mv[3][2] = re->viewmat[3][2];
// freestyle_mv[3][3] = 1.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++ )
freestyle_mv[i][j] = re->viewmat[i][j];
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];
Simplified modelview matrix copy
2009-04-12 07:02:03 +00:00
//f(cam && (re->r.mode & R_ORTHO)) {
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
soc-2008-mxcurioni: first version of lib3ds code. It does NOT work yet and has to be debugged. It can be activate in app_blender/api.cpp by replacing the FRS_scene_3ds_export call in FRS_prepare, by FRS_load_mesh. All of the reference to the original Material class were renamed to FrsMaterial to resolve a name collision with Blender. To keep the window context necessary to draw the strokes after RE_Database_FromScene has been called, the display_clear function is used.
2008-08-07 15:04:25 +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
void prepare(Render* re, SceneRenderLayer* srl ) {
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
// clear canvas
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
controller->Clear();
soc-2008-mxcurioni: clean up
2008-08-08 08:53:13 +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
// load mesh
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;
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
cout << "\n=== Rendering options ===" << endl;
cout << "Modules :"<< endl;
int layer_count = 0;
for( StyleModuleConf* module_conf = (StyleModuleConf *)panelConfig->modules[srl]->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++;
}
}
cout << endl;
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
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
controller->setSphereRadius(*panelConfig->sphere_radius[srl]);
controller->setComputeRidgesAndValleysFlag((*panelConfig->flags[srl] & FREESTYLE_RIDGES_AND_VALLEYS_FLAG) ? true : false);
controller->setComputeSuggestiveContoursFlag((*panelConfig->flags[srl] & FREESTYLE_SUGGESTIVE_CONTOURS_FLAG) ? true : false);
controller->setSuggestiveContourKrDerivativeEpsilon(*panelConfig->dkr_epsilon[srl]);
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;
cout << "Redges and valleys : " << (controller->getComputeRidgesAndValleysFlag() ? "enabled" : "disabled") << endl;
cout << "Suggestive contours : " << (controller->getComputeSuggestiveContoursFlag() ? "enabled" : "disabled") << endl;
cout << "Suggestive contour dkr epsilon : " << controller->getSuggestiveContourKrDerivativeEpsilon() << endl;
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
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
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 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;
int x, y, rectx, recty;
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;
rl = RE_GetRenderLayer(re->result, srl->name);
if( !rl || rl->rectf == NULL) { cout << "No layer to composite to" << endl; return; }
dest = rl->rectf;
rectx = re->rectx;
recty = re->recty;
for( y = 0; y < recty; y++) {
for( x = 0; x < rectx; x++) {
pixSrc = src + 4 * (rectx * y + x);
if( pixSrc[3] > 0.0) {
pixDest = dest + 4 * (rectx * y + x);
addAlphaOverFloat(pixDest, pixSrc);
}
}
}
}
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 displayed_layer_count( SceneRenderLayer* srl ) {
int count = 0;
Made the calculation of the number of available style modules more robust
2009-04-08 20:19:20 +00:00
if( panelConfig->layers.find(srl) == panelConfig->layers.end() )
return 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
for( StyleModuleConf* module_conf = (StyleModuleConf *)panelConfig->modules[srl]->first; module_conf; module_conf = module_conf->next ) {
if( module_conf->is_displayed )
count++;
}
return count;
}
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
void FRS_add_Freestyle(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
SceneRenderLayer *srl;
Render* freestyle_render = NULL;
// init
cout << "\n#===============================================================" << endl;
cout << "# Freestyle" << endl;
cout << "#===============================================================" << endl;
init_view(re);
init_camera(re);
Corrected crash when calculating number of available style modules
2009-04-08 17:32:56 +00:00
for(srl= (SceneRenderLayer *)G.scene->r.layers.first; srl; srl= srl->next) {
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( !(srl->layflag & SCE_LAY_DISABLE) &&
srl->layflag & SCE_LAY_FRS &&
displayed_layer_count(srl) > 0 )
{
cout << "\n----------------------------------------------------------" << endl;
cout << "| "<< srl->name << endl;
cout << "----------------------------------------------------------" << endl;
// prepare Freestyle:
// - clear canvas
// - load mesh
// - add style modules
// - set parameters
// - compute view map
prepare(re, srl);
// render and composite Freestyle result
if( controller->_ViewMap ) {
// render strokes
controller->DrawStrokes();
freestyle_render = controller->RenderStrokes(re);
controller->CloseFile();
// composite result
composite_result(re, srl, freestyle_render);
// free resources
RE_FreeRender(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
}
}
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
//=======================================================
void FRS_select_layer( SceneRenderLayer* srl )
{
if( panelConfig->layers.find(srl) == panelConfig->layers.end() )
{
panelConfig->layers.insert(srl);
panelConfig->modules[srl] = new ListBase;
panelConfig->modules[srl]->first = panelConfig->modules[srl]->last = NULL;
panelConfig->flags[srl] = new int(0);
panelConfig->sphere_radius[srl] = new float(1.0);
panelConfig->dkr_epsilon[srl] = new float(0.001);
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
freestyle_modules = panelConfig->modules[srl];
freestyle_flags = panelConfig->flags[srl];
freestyle_sphere_radius = panelConfig->sphere_radius[srl];
freestyle_dkr_epsilon = panelConfig->dkr_epsilon[srl];
freestyle_current_layer = srl;
freestyle_current_layer_number = BLI_findindex(&G.scene->r.layers, freestyle_current_layer);
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
void FRS_delete_layer( SceneRenderLayer* srl, short isDestructor )
{
BLI_freelistN( panelConfig->modules[srl] );
delete panelConfig->modules[srl];
delete panelConfig->flags[srl];
delete panelConfig->sphere_radius[srl];
delete panelConfig->dkr_epsilon[srl];
panelConfig->modules.erase(srl);
panelConfig->flags.erase(srl);
panelConfig->sphere_radius.erase(srl);
panelConfig->dkr_epsilon.erase(srl);
if( !isDestructor )
panelConfig->layers.erase(srl);
}
void FRS_add_module()
{
StyleModuleConf* module_conf = (StyleModuleConf*) MEM_callocN( sizeof(StyleModuleConf), "style module configuration");
BLI_addtail(freestyle_modules, (void*) module_conf);
strcpy( module_conf->module_path, default_module_path.c_str() );
module_conf->is_displayed = 1;
}
void FRS_delete_module(void *module_index_ptr, void *unused)
{
StyleModuleConf* module_conf = (StyleModuleConf*) BLI_findlink(freestyle_modules, (intptr_t)module_index_ptr);
BLI_freelinkN( freestyle_modules, module_conf);
}
void FRS_move_up_module(void *module_index_ptr, void *unused)
{
StyleModuleConf* module_conf = (StyleModuleConf*) BLI_findlink(freestyle_modules, (intptr_t)module_index_ptr);
BLI_remlink(freestyle_modules, module_conf);
BLI_insertlink(freestyle_modules, module_conf->prev->prev, module_conf);
}
void FRS_move_down_module(void *module_index_ptr, void *unused)
{
StyleModuleConf* module_conf = (StyleModuleConf*) BLI_findlink(freestyle_modules, (intptr_t)module_index_ptr);
BLI_remlink(freestyle_modules, module_conf);
BLI_insertlink(freestyle_modules, module_conf->next, module_conf);
}
void FRS_set_module_path(void *module_index_ptr, void *unused)
{
StyleModuleConf* module_conf = (StyleModuleConf*) BLI_findlink(freestyle_modules, (intptr_t)module_index_ptr);
freestyle_current_module_path = module_conf->module_path;
}
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