This is a regression since threaded dependency graph landed to master.
Root of the issue goes to the loads of graph preparation being done
even if there's nothing to be updated.
The idea of this change is to use ID type recalc bits to determine
whether there're objects to be updated. Generally speaking, we now
check object and object data datablocks with DAG_id_type_tagged()
and if there's no such IDs tagged we skip the whole task pool creation
and so,
The only difficult aspect was that in some circumstances it was possible
that there are tagged objects but nothing in ID recalc bit fields.
There were several different circumstances when it was possible:
* When one assigns object->recalc flag directly DAG flush didn't
set corresponding bits to ID recalc bits. Partially it is fixed
by making it so flush will set bitfield, but also for object
types there's no reason to assign recalc flag directly. Using
generic DAG_id_type_tag works almost the same fast as direct
assignment, ensures all the bitflags are set properly and for the
long run it seems it's what we would actually want to.
* DAG_on_visible_update() didn't set recalc bits at all.
* Some areas were checking for object->recalc != 0, however it is was
possible that object recalc flag contains PSYS_RECALC_CHILD which
was never cleaned from there.
No idea why would we need to assign such a flag when enabling
scene simplification, this is to be investigated separately.
* It is possible that scene_update_post and frame_update_post handlers
will modify objects. The issue is that DAG_ids_clear_recalc is called
just after callbacks, which leaves objects with recalc flags but no
corresponding bit in ID recalc bitfield. This leads to some kind of
regression when using ID type tag fields to check whether there objects
to be updated internally comparing threaded DAG with legacy one.
For now let's have a workaround which will preserve tag for ID_OB
if there're objects with OB_RECALC_ALL bits. This keeps behavior
unchanged comparing with 2.69 release.
Now add_freestyle() in pipeline.c takes a second argument to enable/disable
stroke rendering. When stroke rendering is disabled, the function allocates
data structures but does not perform stroke rendering. The allocated data
structures (mostly left unpopulated with data elements) are intended to allow
for the Read Full Sample Layers (Shift-R) command in the compositor.
Reverted the trunk revision 56136 and part of revision 56127 concerning the local Main
for Freestyle and temporary scene generation for stroke rendering.
The function do_merge_fullsample() in pipeline.c has access to the Scene of each Render,
so that the temporary Scene generated by Freestyle has to be kept for FSAA even after
stroke rendering has been done. By the same token, the local Main has been moved from
the BlenderStrokeRenderer class to Render. It is noted that free_all_freestyle_renders()
in pipeline.c is intended to get the temporary Scene of each Render released specifically
taking account of the FSAA case.
It's more like an ownership thing, but it's not so much
clear who actually is an owner of temporary scene, so
for now just ensure Render does not have link to it
after strokes are rendered.
There're also suspicious thing related on why separate
RE_free_database is needed for freestyle renders, but
that's also another story.
This means main database is no longer pollutes with
temporary scene and objects needed for freestyle
render.
Actually, there're few of separated temporary mains
now. Ideally it's better to use single one, but it's
not so much trivial to pass it to all classes. Not
so big deal actually.
Required some changes to blender kernel, to make it
possible to add object to a given main, also to
check on mesh materials for objects in given main.
This is all straightforward changes.
As an additional, solved issue with main database
being infinitely polluted with text blocks created
by create_lineset_handler function.
This fixes:
- #35003: Freestyle crashes if user expands objects in FRS1_Scene
- #35012: ctrl+f12 rendering crashes when using Freestyle
Because of our release soon, feature has been added behind the Debug Menu.
CTRL+ALT+D and set it to -1. Or commandline --debug-value -1.
When debug set to -1, you can put the viewport to 'render' mode, just like
for Cycles. Notes for testers: (and please no bugs in tracker for this :)
- It renders without AA, MBlur, Panorama, Sequence, Composite
- Only active render layer gets rendered. Select another layer will re-render.
- But yes: it works for FreeStyle renders!
- Also does great for local view.
- BI is not well suited for incremental renders on view changes. This only
works for non-raytrace scenes, or zoom in ortho or camera mode, or for
Material changes. In most cases a full re-render is being done.
- ESC works to stop the preview render.
- Borders render as well. (CTRL+B)
- Force a refresh with arrow key left/right. A lot of settings don't trigger
re-render yet.
Tech notes:
- FreeStyle is adding a lot of temp objects/meshes in the Main database. This
caused DepsGraph to trigger changes (and redraws). I've prepended the names
for these temp objects with char number 27 (ESC), and made these names be
ignored for tag update checking.
- Fixed some bugs that were noticable with such excessive re-renders, like
for opening file window, quit during renders.
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.
- Revert some stylistic changes made in branch
They weren't directly related on freestyle project
and better be handled in trunk. Helps reading patches
ad prevents possible merge conflicts.
- Solved issue introduced with recent deprecation of
RenderData.maximize,
on the console during Freestyle rendering. The debug prints are turned off
by default now. Errors are still printed on the console.
A patch set implementing this functionality was provided by Bastien Montagne.
Many thanks! :)
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.
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.
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().
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!
for stroke rendering. This fix is intended to improve the
stability of stroke rendering when the output format is AVI
Codec, QuickTime, or one of FFMpeg codecs.
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.
rendering.
RE_BlenderFrame() and RE_BlenderAnim() are Blender's internal
top-level rendering API functions for a single frame and a series of
frames, respectively. These functions rely on global variables to
keep render pipeline states. Freestyle's stroke rendering was also
using RE_BlenderFrame to render a temporary scene of stroke meshes.
These nested calls of the top-level rendering API functions were
causing broken render pipeline states and eventually led to a crash.
This commit is intended to fix the issue, by introducing an rendering
API function RE_RenderFreestyleStrokes specifically used for stroke
rendering in Freestyle. The new function does not do anything with
regard to the global variables in the rendering API implementation.
Transparent strokes are rendered by means of transparent vertex colors.
To make this possible, Blender's internal renderer has been slightly
extended to allow transparent vertex colors. When Material::vcol_alpha
is non-zero, the renderer takes MCol::a into account.
because of incomplete functionality.
When two transparent strokes intersect, the stroke drawn first is
completely overridden by the stroke drawn after the first stroke,
instead of two stroke colors being blended at the intersection.
In Freestyle, strokes are represented with triangle strips, and stroke
colors are realized using vertex colors in order to enable variable
stroke colors (i.e., each triangle has a different color). Stroke
colors in Freestyle are in the RGBA format, while vertex colors in
Blender do not have an alpha component. Therefore, we here employ a
2-pass rendering approach as follows. First, the alpha component of
an image is rendered by using the red component of vertex colors as
the alpha component of stroke colors (1st pass). The render result is
saved into a temporary buffer. Then, the vertex colors of stroke
meshes are replaced with RGB values, and the RGB components of the
image is rendered (2nd pass). Finally, the RGB and alpha components
are merged to produce the render result in the RGBA format.
rendering. When objects exists out of the viewing frustrum and
near the near clipping plane, feature edges in the 3D camera
coordinate system are projected to an extremely far location from
the camera view in the 2D image space. These feature edges
result in very long strokes with a large number of stroke
vertices, which temporarily require a significant memory storage,
causing a fatal "out of memory" error. This problem is partially
addressed by the changes in the present commit.
