Age | Commit message (Collapse) | Author |
|
(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
|