| Age | Commit message (Collapse) | Author |
|---|
|
The problem was caused by the fact that BKE_scene_copy() was simply doing "memcpy"
to duplicate render layers including lineset settings without taking care of pointers
in the linesets. For this reason, freeing the original scene and copied one resulted
in freeing allocated memory buffers twice.
Now BKE_scene_copy() properly duplicates linesets as part of render layers.
Also some code clean-up was made in the modified files.
Problem report by IRIE Shinsuke (with a patch to fix the crash). Many thanks!
|
|
spaces around operators, and so forth). Many thanks!
|
|
|
|
source/blender/freestyle files.
|
|
Now the line set buffer is cleared when a new .blend file is opened, so
that a line set may not be copied and pasted between two .blend files.
|
|
of copy/paste functionality. Instead of making a copy of the active
line set, now the settings of the active line set are copied to and
pasted from a buffer. This allows for copying and pasting line set
settings among different scenes and render layers.
|
|
of the active line set.
|
|
Écrivain through the BA Freestyle thread. Thanks!
|
|
from scenes.
|
|
Parameter Editor mode. This is a WIP commit. Only the base line
color, base alpha transparency, and base line thickness are respected.
More additions are anticipated to account for other parameters.
* Added FRS_finish_stroke_rendering() to clean Freestyle-related
temporary resources after stroke rendering.
* Some functions in FRS_freestyle.cpp are now declared as static
functions, so as not to mess up the program-wide name space.
* Made the StyleModule class inheritable, and defined new subclass
BlenderStyleModule that takes a Text object instead of a file name.
|
|
A number of UI elements were newly introduced to control line color, alpha
transparency and line thickness by means of base color/alpha/thickness plus
modifiers that alter the base values. To begin with, three basic modifiers
were prototyped with the aim of putting the new UI framework in practice
and evaluating if it works properly.
The Parameter Editor mode is still in a work-in-progress state and totally
useless from users' viewpoint.
|
|
This commit is just meant to give the new GUI framework a concrete shape.
There is no usefulness in newly introduced elements at the moment.
Freestyle options in render layers now include a pull-down menu named Control
Mode that allows you to choose either the Python Scripting or Parameter Editor
mode. The Python Scripting mode is the conventional way of controlling
Freestyle by directly using style modules written in Python. The Parameter
Editor is a new control mode that is intended to be used by everyone without
relying on Python programming.
In the Parameter Editor mode, you can specify multiple line sets for each
render layer. A line set defines feature edge selection criteria, as
well as a line style for drawing the selected feature edges using specific
line stylization parameters. Line style is a new datablock type, meaning
that a line style can be shared by multiple line sets (possibly those in
different render layers in different scenes).
Much more additions are anticipated in subsequent commits to implement UI
controls for specifying feature edge selection criteria and line stylization
parameters.
|
|
The render pipeline has been extended to better work with
Freestyle stroke rendering. Struct Render has a new member
ListBase freestyle_renders to keep Render instances generated
through stroke rendering in Freestyle. The number of
elements (LinkData instances with LinkData::data pointing to a
Render instance) in freestyle_renders is the same as the scene
render layers of the scene being rendered. When the k-th scene
render layer has the Freestyle option enabled, the k-th element
of freestyle_renders refers to a Render instance that holds
Freestyle render results for the scene layer. This association
between the scene render layer and the Render instance is used to
merge the Freestyle render results into the corresponding render
results for the scene render layer.
|
|
from within style modules. Calling this function is only valid within
style modules. Calling it from the Python Interactive Console results
in an error as follows:
>>> import Freestyle
>>> Freestyle.getCurrentScene()
Traceback (most recent call last):
File "<console>", line 1, in <module>
TypeError: current scene not available
>>>
|
|
initializing Freestyle and specifying contexts, making the API a bit messy.
Now FRS_initialize() is only for initialization, and contexts are specified
by new FRS_set_context() function just before starting rendering.
|
|
2.4x) from within Freestyle. Now Freestyle configuration parameters
are edited without relying on the notion of the current scene. This
resolved a few related issues as described below:
- A bug in Freestyle configuration management with respect to
multiple scenes was fixed. Now Freestyle configuration parameters
(e.g., style modules, ridges/valleys, suggestive contours) can be
specified for each render layer of each scene. Composition of
multiple render layers from different scenes should work as expected.
- A crash after undoing was fixed as well.
* Removed unused external Freestyle functions and global variables
from FRS_freestyle.h and FRS_freestyle.cpp.
|
|
Blender 2.5. As of I right now, Freestyle is back in the UI, but rendering still fails because of the texture manager.
|
|
- proper Freestyle initialization, with support for undo/redo
- re-added FreestyleStyleConfig data structure
- Freestyle Python interpreter updated
This commit should compile without errors. More work is necessary to complete the migration:
- add Freestyle in the UI
- set up RNA support
|
|
some Freestyle-related pointers, which led to a crash when the
rendering was initiated or the Freestyle panel (in the Scene buttons)
was redrawn.
|
|
|
|
The main contribution of this commit is the possibility to save Freestyle configuration information inside .blend files. It required an extensive refactoring of the previous interface code.
The code has been tested and does not crash on my machine. If you encounter issues, please let me know (and if possible, sending me an sample .blend file).
DETAILS:
- refactored code to notify Freestyle when adding/removing render layers (FRS_freestyle_config.{h,cpp})
- corrected the freeing of style modules when files are read from / written to disk
- moved Freestyle configuration information into scene renderlayers, to allow loading / saving .blend files (DNA_scene_types.h DNA_freestyle_types.h FRS_freestyle.cpp)
- inserted temporary trick to prevent crashes when orthographic camera is used (SilhouetteGeomEngine.cpp), but outputting incorrect feature line calculations
|
|
|
|
Freestyle's pipeline is now fully controllable at the layer level. It can be used:
- in any render layer
- with as many style modules per layer
DETAILS:
Freestyle usage has not changed:
- all the configuration happens in the "Freestyle" render panel, after it is enabled in the "Output" panel with the 'Freestyle' toggle.
- each render layer can choose to render Freestyle strokes by togglingo on 'FrSt' (in the "Render Layers" panel)
- it is fully compatible with compositor nodes
In the "Freestyle" panel, a render layer is selected via the menu list next to the "Render Layer:" label. The options displayed below are those of the currently selected render layer (and are not global to all render layers, as was previously the case).
Style modules are added by pressing the lower button "Add style module". Once added, the following operations are possible:
- deletion (cross)
- reordering (up/down arrows)
- toggling of display (check)
The order of the style modules follows Freestyle's original convention: the modules in the list from top to bottom are respectively the first to the last composited in the render layer. For example, if the module list is "contour" followed by "cartoon", the "cartoon" strokes are rendered on top of the "contour" strokes.
The "Freestyle" panel is constantly synchronized with the "Render Layers" panel: if render layers are added, deleted or toggled off display, Freestyle will take note of the changes.
The current pipeline works as follows:
----------------------------------------------------------------------------------------------
for every scene that is being rendered
if Freestyle is enabled globally
Freestyle is initialized
camera and view settings are transferred from Blender to Freestyle
for every render layer
if: - layer is enabled
- layer enabled Freestyle
- the number of displayed style modules is non-zero
canvas is cleared
geometry is transferred from Blender to Freestyle
settings are fixed for current iteration
view map is calculated
strokes are computed in the canvas (based on view map and style modules)
strokes are rendered in separate Blender scene
scene is composited in current layer
----------------------------------------------------------------------------------------------
A number of changes were made on the codebase:
- the rendering interface between Freestyle and Blender was simplified. The following naming convention was used: functions that are called from within Blender pipeline are prefixed with 'FRS_', while the variables are prefixed with 'freestyle_'
- Freestyle data structures that were put in Blender's render pipeline were removed
- Freestyle cleans up its data structures on Blender exit and shouldn't leak memory
- to ease the configuration in the "Freestyle" panel, a centralized configuration data structure was used and can be easily extended
LIMITATIONS
Even though the current commit is stable and achieves the intended result, it is not as efficient as it could be:
- the canvas and the style modules are at cleared at each layer-level render
- geometry is reloaded at each frame and is duplicated across render layers
This revision clarifies my understanding of the future role of the view map in the compositor. Unfortunately, contrary to what the original proposal said, it is impossible to provide the view map as a render pass because render passes are defined (RE_pipeline.h) as raw floating-point rects. We will have to determine whether or not to extend the notion of render pass to fully integrate the view map in the compositor.
|
|
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)
|
|
|
|
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.
|
|
suggestive contours) and add corresponding UI controls to the Freestyle tab in the Scene buttons.
|
|
modes (OpenGL and Blender internal), applied a patch to allow CMake to be used for compilation.
|
|
by specifying its pathname. By default, it is loaded with the contour.py path.
|
|
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.
|
