| Age | Commit message (Collapse) | Author |
|---|
|
render resolution and scale.
Problem reports independently by Light BWK and Folkert de Vries, thanks.
|
|
This fix should be considered for inclusion in the 2.73 release, since
it concerns a new feature of Freestyle introduced in 2.73.
|
|
|
|
New render layer option named "View map cache" is added to reuse a
previously computed view map for subsequent rendering. The cache is
automatically updated when the mesh geometry of the input 3D scene has
been changed.
This functionality offers a major performance boost for Freestyle
animation rendering when camera-space mesh geometry is static, as well
as for repeated still renders with updates of line stylization options.
Although the "View map cache" toggle is a render layer option, the cache
memory is shared by all render layers and scenes. This means that if
Freestyle is used for two or more render layers (possibly in different
scenes through the compositor), then the cached view map for one render
layer is replaced by a new view map for another render layer and hence
no performance gain is expected.
|
|
New properties 'line_color' and 'line_priority' are added to Material ID data blocks.
The 'line_color' property allows users to specify a per-material line color that can be
used as a Freestyle line color through Material color modifiers of line style settings.
The new line color property is intended to provide a solution for line color
stylization when a proper Freestyle support for Cycles is implemented (likely
as part of the upcoming Blender 2.72 release; see Patch D632). Materials in
Cycles are usually set up using shader nodes, and Freestyle won't be capable
of retrieving colors and other properties from node-based materials any soon.
The new line color property of materials addresses this foreseen limitation by
providing artists with an intuitive alternative mean to specify line colors on a
per-material basis independently from node trees.
The 'line_priority' property gives users a way to control line colors at material
boundaries. When a line is drawn along a feature edge at material boundaries,
one of the two materials on both sides of the edge has to be picked up to
determine the line color. So far there was no way to control this selection
(which was in effect at random). Now the material with a higher line color
priority will be selected.
The new per-material line settings are shown in the new Freestyle Line tab in
the Material context of the Properties window (only when Freestyle is enabled).
|
|
These qualifiers were leftovers of the stand alone Freestyle program and not used
(set to an empty string) in Blender for years.
|
|
The issue was caused by including both Python.h and BLI_math.h. Since the macro
definition in Python.h was unconditional, it was necessary to include it first and then
BLI_math.h.
Addressing the issue turned out to affect many Freestyle source files. There were several
other coding flaws that complicated the situation:
1. intern/system/FreestyleConfig.h was abused just to include BLI_math.h which was in
fact unnecessary in FreestyleConfig.h. While addressing this, inclusion of both math.h
and BLI_math.h had to be duly dealt with to avoid a compiler error about round().
2. #include <Python.h> was not properly put in the extern "C" { ... } construct.
3. intern/view_map/Interface0D.h and intern/python/Director.h, both of which included
Python.h, were included from within Freestyle header files that were almost or completely
independent of Python. These non-Python header files were used everywhere in the
Freestyle code base, causing many cases of the reported macro redefinitions.
4. The Director.h file was also declaring 'using namespace Freestyle', which was causing
another scope issue in several Freestyle header files.
This commit is intended to address the first problem above. Subsequent commits will deal
with the other three.
|
|
|
|
|
|
|
|
A crash in the Freestyle renderer was reported by Ton on IRC with a stack trace
below. Note that #2 is in Freestyle, whereas #1 is in the compositor. The problem
was observed in a debug build on OS X 10.7 (gcc 4.2, openmp disabled, no llvm).
----------------------------------------------------------------------
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
[Switching to process 72386 thread 0xf303]
0x0000000100c129f3 in NodeBase::~NodeBase (this=0x10e501c80) at COM_NodeBase.cpp:43
43 delete (this->m_outputsockets.back());
Current language: auto; currently c++
(gdb) where
#0 0x0000000100c129f3 in NodeBase::~NodeBase (this=0x10e501c80) at COM_NodeBase.cpp:43
#1 0x0000000100c29066 in Node::~Node (this=0x10e501c80) at COM_Node.h:49
#2 0x000000010089c273 in NodeShape::~NodeShape (this=0x10e501c80) at NodeShape.cpp:43
#3 0x000000010089910b in NodeGroup::destroy (this=0x10e501da0) at NodeGroup.cpp:61
#4 0x00000001008990cd in NodeGroup::destroy (this=0x10e5014b0) at NodeGroup.cpp:59
#5 0x00000001008990cd in NodeGroup::destroy (this=0x114e18da0) at NodeGroup.cpp:59
#6 0x00000001007e6602 in Controller::ClearRootNode (this=0x114e19640) at Controller.cpp:329
#7 0x00000001007ea52e in Controller::LoadMesh (this=0x114e19640, re=0x10aba4638, srl=0x1140f5258) at Controller.cpp:302
#8 0x00000001008030ad in prepare (re=0x10aba4638, srl=0x1140f5258) at FRS_freestyle.cpp:302
#9 0x000000010080457a in FRS_do_stroke_rendering (re=0x10aba4638, srl=0x1140f5258) at FRS_freestyle.cpp:600
#10 0x00000001006aeb9d in add_freestyle (re=0x10aba4638) at pipeline.c:1584
#11 0x00000001006aceb7 in do_render_3d (re=0x10aba4638) at pipeline.c:1094
#12 0x00000001006ae061 in do_render_fields_blur_3d (re=0x10aba4638) at pipeline.c:1367
#13 0x00000001006afa16 in do_render_composite_fields_blur_3d (re=0x10aba4638) at pipeline.c:1815
#14 0x00000001006b04e4 in do_render_all_options (re=0x10aba4638) at pipeline.c:2021
----------------------------------------------------------------------
Apparently a name conflict between the two Blender modules is taking place.
The present commit hence intends to address it by putting all the Freestyle C++
classes in the namespace 'Freestyle'. This revision will also prevent potential
name conflicts with other Blender modules in the future.
Special thanks to Lukas Toenne for the help with C++ namespace.
|
|
|
|
this can be added back on case-by-case basis, but better not assume ownership of another projects work by default.
|
|
|
|
(from gcc 4.7),
mostly by commenting out unused variables, or using the BLI's SET_UINT_IN_POINTER macro.
|
|
again!
|
|
Reported by Bastien Montagne, thanks!
|
|
Patch contribution by Bastien Montagne, thanks!
|
|
New "face marks" and "edge marks" have been introduced in mesh data
blocks. In the edit mode of a mesh object, face marks can be put
to selected faces by choosing Mesh >> Faces >> Mark Freestyle Face
from the menu of a 3D View window or Ctrl-F >> Mark Freestyle Face
from the context menu. Similarly, edge marks can be put to selected
edges by Mesh >> Edges >> Mark Freestyle Edge or Ctrl-E >> Mark
Freestyle Edge. These marks should work fine with the Subdivision
surface modifier.
Moreover, two new conditions for feature edge selection have been
added to the Parameter Editor mode as described below:
1. The Selection by Edge Types option has now the new Edge Mark type,
which can be used to (de)select feature edges having edge marks.
This option can be used to add to (or remove from) the view map
arbitrary edges of mesh objects.
2. Selection by Face Marks option has been newly introduced, in which
face marks are used for feature edge selection in two ways. One
option is called "One Face" which is to (de)select feature edges if
one of faces on the left and right of each feature edge has a face
mark. The other option is "Both Faces" to (de)select feature edges
if both faces on the left and right have a face mark.
|
|
ViewShape objects in the view map, as well as SShape objects
that can be retrieved with ViewShape::sshape(), now have a
getName() method that returns the name of the object from
which each shape is created. For instance, visible feature
edges of specific mesh objects (e.g., Cube.001 and Cube.002)
can be selected using custom predicate ObjectNamesUP1D as
follows:
class ObjectNamesUP1D(UnaryPredicate1D):
def __init__(self, names):
UnaryPredicate1D.__init__(self)
self._names = names
def getName(self):
return "ObjectNamesUP1D"
def __call__(self, viewEdge):
return viewEdge.viewShape().getName() in self._names
upred = AndUP1D(QuantitativeInvisibilityUP1D(0),
ObjectNamesUP1D(["Cube.001", "Cube.002"]))
Operators.select(upred)
|
|
end of a file.
* Fixed compiler warnings due to an invalid argument to PyList_New().
NULL was used instead of 0 to create an empty list.
|
|
source/freestyle/intern/blender_interface folder
|
|
- 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
|
|
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.
|
|
view map based on selected object layers in a render layer, instead of the global selection of object layers. This allows, for example, to have two render layers, one for rendering solid faces in all object layers, and the other for rendering outlines of objects in selected object layers by Freestyle. At the moment, the number of Freestyle-enabled render layers is restricted to one -- a better fix is in the future work.
|
|
|
|
handled case when scene is empty
made controller's view map as public variable
|
|
|
|
|
|
|
|
within Blender without using a 3ds import format. Most shapes tested work, the only exception being strands and halos.
|
|
providing the exact same information (verified by the same bounding box and grid), the ViewMap does not have any view edge yet. The lib3ds-less iteration does NOT work yet.
|
|
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.
|
|
IMPORTANT: The setters functions' names were normalized due to constant confusion regarding capitalization. All the function names start with set... instead of Set.... This convention was changed all throughout Freestyle. To use Freestyle as an external renderer, the SWIG library MUST be regenerated.
|
|
QImage dependencies. Up to this commit, the following directories compile well (and without any warning): system, image, geometry, graph, winged_edge, view_map, stroke.
Modified code is commented by //soc and unused variables by //soc unused
|
|
source/blender/freestyle
|
