| Age | Commit message (Collapse) | Author |
|---|
|
This commit makes a set of fixes and improvements based on the results of
Freestyle branch review by Brecht. The discussion thread is:
http://lists.blender.org/pipermail/bf-committers/2012-October/037927.html
* The Layers panel and Freestyle-related panels in the Render tab of the
Properties window were moved to the newly created Render Layers tab.
The idea is to separate per render layer rendering options into a distinct
Properties window tab, and use the existing Render tab to accommodate
per scene rendering options.
* The new Freestyle panel was added in the Render tab. The panel header
contains a toggle button for globally enabling Freestyle, with the aim of making
Freestyle easier to find. Those Freestyle options in the Post Processing panel
were also moved to the new panel.
* GUI code was updated so that UI controls will be greyed out (instead of
being hidden) when Freestyle is disabled. Additional UI changes were also
made to reduce space consumption.
* The list of line sets was moved from the Freestyle panel to the Freestyle:
Line Sets panel.
* Old ray-casting algorithms were removed from the UI. Now only two
algorithms (culled and non-culled cumulative visibility detection algorithms)
are available, and the selection is done by the new "Culling" toggle button
within the edge detection options.
|
|
50832).
The solution is exactly the same with revision 43584 for a similar issue in pre-OCIO color management:
i.e., just disabling color management during the nested invocation of BI for stroke rendering.
|
|
rendering.
|
|
stroke rendering.
Many thanks to Joshua Leung (aligorith) for the performance analysis of BKE_object_add function:
http://lists.blender.org/pipermail/bf-committers/2012-October/037759.html
|
|
Conflicts resolved:
source/blender/blenloader/intern/readfile.c
source/blender/render/intern/source/convertblender.c
source/blender/render/intern/source/pipeline.c
Also addressed code inconsistency due to changes in the trunk revision 50628 (color
management with OCIO) and 50806 (UV project material). OCIO-related changes are marked
OCIO_TODO as in some other files modified in revision 50628.
|
|
safety in curve evaluation.
Problem report from Vicente Carro with an example .blend file for reproducing the issue. Thanks!
|
|
The problem is that the visibility of view edges in the view map may be incorrect.
The main cause of this issue is that view edges are constructed from a series of FEdges
without testing the visibility of the FEdges being concatenated. Later view edges
are split into pieces if two view edges intersect in the 2D image coordinate system.
After that the visibility of the view edges is computed by taking account of occluding
faces in the 3D scene. In many cases this procedure results in correct line visibility,
but not always (that is the problem).
A simple solution experimentally implemented here is not to chain FEdges at all.
Instead view edges are constructed from at most one FEdge now. This solution is only
applied to sharp FEdges (roughly corresponding to edges in the input mesh data; specifically,
silhouette, crease, border, edge mark, contour, external contour, and material boundary).
A better solution is to reorder the three steps of view edges construction mentioned above,
i.e., first splitting FEdges at 2D intersection, computing the visibility of the FEdges,
then concatenating them to build view edges. This solution is left for future work for now.
|
|
This commit is meant to improve the response of the ESC key for stopping Freestyle rendering
throughout the rendering process. The rendering with Freestyle consists of several steps
including: (1) mesh data loading, (2) winged edge construction, (3) silhouette edge detection,
(4) view map construction, and (5) stroke drawing. All these steps have been extended to
frequently check if the ESC key is pressed, so that users can abort time-consuming rendering
at any point of time.
|
|
recovered in the Parameter Editor mode.
Several users requested the recovery as the removal of the two parameters was considered over-simplification for advanced users.
As in the Python Scripting mode, the two parameters are in the "advanced edge detection options" section and disabled by default.
Also the lower limit of Kr derivative epsilon was changed from 0 to -1000 so as to permit a negative value.
|
|
|
|
The previous stroke creation procedure was trying to clean stroke topology
by removing overlapping stroke vertices in the same 2D location. The idea
was to avoid having to address this kind of singularity during subsequent
stroke shading. In-depth analyses revealed, however, that this was a wrong
way to ensure clean stroke topology, since just deleting overlapping vertices
may break the continuity of the underlying series of FEdges on top of which
the stroke has been built. Such a break of linked FEdges was a major cause
of frequent failure in CurvePoint::getFEdge().
The present commit aims to address the singularity issue by adding small
offsets to the 2D location of overlapping vertices and making them
non-overlapping to each other. Since the offsets only result in sub-pixel
differences, the impact on visual outcomes is expected to be negligible.
|
|
BLI_assert(CustomData_has_layer(&dm->faceData, CD_POLYINDEX));
in CDDM_calc_normals_mapping_ex() in source/blender/blenkernel/intern/cdderivedmesh.c.
Problem report by flokkievids with an example .blend file for reproducing the issue. Thanks!
The issue was caused by the fact that Freestyle was using the pre-BMesh way for constructing
mesh data with the aim of generating a temporary 3D scene for stroke rendering. Specifically,
the MFace struct was used for defining triangular faces. Now BMesh is in the trunk, MFace
is internally used for tessellated faces only, and MPoly and MLoop are used for general mesh
data construction. This commit is intended to update the Freestyle stroke rendering code in
the BMesh way.
|
|
|
|
SilhouetteGeomEngine::ProjectSilhouette().
This issue arises when the Z depth of the bounding box of the scene being rendered is zero.
|
|
Problem report by octane98 in the BA Freestyle thread with a sample .blend file. Thanks!
|
|
of Normal2DF0D with smooth FEdges. The fix is to avoid generating new FEdgeSmooth
instances whose length is shorter than epsilon.
|
|
that
none of the SVertices are within the image boundary but an FEdge intersects with
the image boundary.
The problem was reported by edna through the BA Freestyle thread, with a .blend
file for reproducing the bug. Thanks!
|
|
Conflicts resolved:
source/blender/blenkernel/intern/material.c
source/blender/blenkernel/intern/subsurf_ccg.c
source/blender/blenloader/intern/readfile.c
source/blender/editors/animation/anim_channels_defines.c
source/blender/makesrna/intern/rna_scene.c
Additional changes:
* Fix for recent changes of BKE_* function renaming.
* Fix for an "attempt to free NULL pointer" in BlenderStrokeRenderer::RenderStrokeRepBasic().
|
|
rendering.
Problem report by octane98 in the BA Freestyle thread. Thanks!
|
|
triangles in imported mesh data.
|
|
|
|
Reported by flokkievids, thanks!
|
|
The Post Processing tab in the Render buttons has new Line Thickness options for
defining unit line thickness in two different modes as follows:
1. Absolute mode: The unit line thickness is given by a user-specified number
in units of pixels. The default value is 1.
2. Relative mode: The unit line thickness is scaled by the proportion of the
present vertical image resolution to 480 pixels. For instance, the unit line
thickness is 1 with the image height set to 480, 1.5 with 720, and 2 with 960.
|
|
|
|
splitting of FEdges at 2D intersections (i.e., at TVertices).
|
|
A motivating example of the problem the present solution aims to address is a
quad face such that three of the four vertices are colinear (i.e., they are
lying on a line). Depending on how this quad is separated into two triangles,
one of them can be a degenerate triangle. Degenerate triangles of this form
are easy to avoid by rotating the diagonal edge of quad faces without affecting
the visual outcome. The fix implemented in this commit tries to address
degenerate triangles in this way.
|
|
Problem report by Bastien Montagne, thanks!
|
|
This commit replaces the solution in revision 44539.
It is recalled that a degenerate triangle is a triangle such that
1) A and B are in the same position in the 3D space; or
2) the distance between point P and line segment AB is zero.
Degenerate triangles in the second form are now resolved by adding a
small offset to P (i.e., the resulting triangles have a non-zero area).
|
|
This commit replaces the solution in revision 44534.
It is recalled that a degenerate triangle is a triangle such that
1) A and B are in the same position in the 3D space; or
2) the distance between point P and line segment AB is zero.
Unlike the previous solution, the present fix is capable of
any mesh topology involving any number of degenerate triangles.
Degenerated triangles are removed in two steps. First,
degenerate triangles in the second form are transformed into
the first form by moving P to the position of either A or B
that is closer to P. This modification affects all triangles
sharing the vertex P. Then, all degenerate triangles in the
first form are removed by just ignoring them.
Obviously, the present solution has a disadvantage that
resulting strokes may appear incorrect. This drawback is
justified by the fact that the present solution is robust and
easy to implement. Users are expected to fix incorrect
strokes (if any) by manual removal of degenerate triangles
from mesh data.
|
|
This commit is an attempt to address degenerate triangles (i.e.,
triangles whose area is zero) that cause incorrect line visibility in
Freestyle.
There are two forms of degenerate triangles. Let A, B and P denote
the three vertices of a triangle. A degenerate triangle is a triangle
such that 1) A and B are in the same position in the 3D space, or
2) the distance between point P and line segment AB is zero. Note
that the first form is a special case of the second form. Degenerate
triangles in the first form is easy to remove by the Remove Doubles
command. This commit is intended to address those degenerate triangles
in the second form.
The implemented fix cannot address degenerate triangles in general.
It fails when a triangle touches with multiple degenerate triangles.
A more general solution needs to be implemented.
|
|
|
|
The Valley edge type is merely an alias of Ridge in the present Freestyle implementation.
|
|
* Sphere radius and Kr derivative epsilon were removed from the
Parameter Editor mode. Now sphere radius of 1.0 and Kr derivative
epsilon of 0.0 are used by default. The rationale of the removal
is two-fold: little predictability and very minor artistic values.
The effects of these parameters are hard to estimate in advance,
which likely leads to a frustration of users due to repeated
trials and unpredicted results. Therefore, the two parameters
are considered to have quite limited artistic values. Proper
definitions of the two parameters more and less require the
knowledge of differential geometry and would not make sense to
most artists for which the Parameter Editor is intended.
* Sphere radius and Kr derivative epsilon are still available in
the Python Scripting mode, but now in an "advanced options" section
that is disabled and hidden by default. This way new users are
properly warned, while expert users with specific technical needs
can enable these options if they want. The same default values
mentioned above are used when the two parameters are disabled.
|
|
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.
|
|
|
|
stokes with 2D length longer than 50. Problem report by Forrest Gimp, thanks!
|
|
information at a given SVertex.
|
|
segment.
|
|
|
|
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.
|
|
clipping by near/far Z planes.
Problem report by vicentecarro together with a .blend file to reproduce
the issue, thanks!
|
|
of the active line set.
|
|
|
|
resolution (i.e., image width and height, scaled by the size factor).
Problem report by flokkievids together with a .blend file for reproducing
the bug, thanks!
|
|
* Stroke::Resample(int nPoints) was not properly working when a wrong
value was returned from Stroke::getLength2D(), resulting in repeated
warning messages "Warning: incorrect points number" during stroke
rendering. The main cause was that stroke geometry shaders did not
update the two-dimensional (2D) length (also referred to as curvilinear
abscissa) after they modified the 2D points of stroke vertices. Now
all stroke geometry shaders make explicit calls for Stroke::UpdateLength()
that has been introduced for recomputing the 2D length. Many thanks to
Josef who reported the problem together with sample .blend files for
reproducing the issue.
* Missing Python wrapper of Stroke::getLength2D() was added.
|
|
Conflicts resolved:
source/blender/render/intern/source/pipeline.c
|
|
In the Parameter Editor mode, each edge type check button in the Selection
by Edge Types has now an associated toggle button to exclude the edge type
from the feature edge selection. This allows you to select, for instance,
those edges that are silhouette lines but not external contours.
|
|
of underlying FEdges introduced by chaining operations. The material of a
smooth FEdge is identified by the material index of the FEdge and the array
of materials in the SShape to which the first SVertex (i.e., vertexA) of the
FEdge belong. The present fix makes sure that the material index refers to the
intended array of materials, to avoid inconsistent reference and out-of-index
errors that lead to a crash.
|
|
FEdges
introduced by chaining operations. When two ViewEdges are concatenated by a chaining
operator, the last vertex of one ViewEdge and the first vertex of the other reside
in the same 3D position, so that the latter vertex is omitted. This caused a pair
of SVertices unconnected by an FEdge. The present commit intends to fix this issue.
The bug was reported by mato_sus304 with a .blend file reproducing the issue. Thanks!
|
|
The instability considered here is due to a persistent failure of the
getFEdge() method in the Interface0D class and its subclasses in the
presence of smooth FEdges. When the Face Smoothness option is
enabled, the view map is populated with not only sharp FEdges (i.e.,
edges in the original meshes) but also smooth FEdges (i.e., newly
built edges lying on triangular surfaces). The failure of getFEdge()
caused many related issues because the method is widely used in other
predicates and functions that rely on it. The most prominent example
of related user-visible problems is a constant failure of the built-in
MaterialF0D.
The main issue and related problems were addressed as follows:
* A bug in the construction of smooth FEdges was fixed. Individual
smooth FEdges, even when they were detected as a series of smooth
FEdges that constitute one smooth ViewEdge, may have some irregular
geometry in the form of non-uniform OWXFaceLayer::order values. The
OWXFaceLayer::order values were used in an inappropriate way, so that
resulting smooth ViewEdges may have an FEdge between two subsequent
SVertices that were indeed the same SVertex object. This was an
unexpected situation that getFEdge() could not handle.
* Another issue in the construction of smooth FEdges was resolved.
When sharp FEdges are constructed, two SVertices at both ends of an
FEdge are generated only when no SVertex exists in a given 3D position
(this way, the original mesh topology is reconstructed from a bunch of
independent triangles that the BlenderFileLoader class passes to the
view map creation process). This sharing of SVertices was used also
for the generation of SVertices at the two ends of each smooth FEdge,
causing the getFEdge() failure in the presence of smooth FEdges. The
workaround implemented here is to simply suppress the sharing of
generated SVertices when smooth FEdges are created.
* In the Parameter Editor mode, the built-in MaterialF0D was replaced
with a better implementation that works well with Curves and Strokes.
MaterialF0D does not work with these 1D data types.
|
