This is a regression introduced by rBd8b00a3bf5c1 (Freestyle: memory
consumption optimization in stroke rendering).
The issue was caused by uninitialized MPoly::mat_nr values. Before the
stroke rendering optimization, individual Freestyle strokes were
represented by distinct mesh objects, and thus MPoly::mat_nr was left
unset (i.e., was always zero). Now that the stroke rendering optimization
has been done and mesh objects may represent multiple strokes of different
materials, MPoly::mat_nr had to be properly set to the material index that
refers to the material of the poly face.
This is mandatory for incoming custom normal imports from io scripts, because
often geometry here is corrupted, so we need to call mesh.validate() to clean it up.
Issue is, we cannot set custom normals before geometry is clean, so we need to store
temporary plain loop normals in a CD_NORMAL layer, validate, and then set custom normals.
So we need a way to prevent 'temp' lnors to be freed by validate.
The reported problem was due to a special case where there are no strokes
to be rendered. Since rendering an empty scene is a waste of time, the issue
was addressed here by skipping the stroke rendering process entirely.
Previously individual strokes were represented by distinct mesh objects
no matter how many vertices and materials each stroke has, although
the vertex and material counts can be quite small depending on the input
scene data. Now stroke meshes are packed into a minimum number of
mesh objects, so as to reduce the overheads of Blender object creation.
Freestyle was using the default Cycles rendering settings (e.g., the number
of samples) and users could not change them. Now all render parameters
(except for film_transparent) are inherited for Freestyle stroke rendering.
Problem report by Danny Grimm on Facebook, thanks!
The stored context object was used for creation of shade nodes. A closer look at the
node system showed that the context is not actually used when shader nodes are
added to a shader node tree. Relying on this fact, now a NULL pointer is passed to
nodeAddStaticNode() instead of the stored bContext pointer.
Looks like the issue was caused by a UV map name starting with a lower case
letter (e.g., "color"). Capitalizing the name fixed the problem. Also adjusted
the creation of custom data layers to optimize things a bit.
Removed the previous changes for passing a line style through the Controller, and
revised the BlenderTextureShader to assign the shader node tree of a line style
(if specified) to strokes. This way the assignment of shading nodes can be done
through both the Freestyle GUI and Python scripting.
Now the shader node tree of a line style ID datablock is used to define textures
as well as their mapping and influence.
TODO: Textures alpha channel mapping and influence.
TODO: Blend mode in the Output Line Style shader node.
The cause of the crash was identified in an uninitialized member variable
`Main->lock`. Now that struct Main has a few member variables whose
values are dynamically allocated, per-render Freestyle-specific Main data
structures will be allocated and released using `BKE_main_new()` and
`BKE_main_free()`, respectively.
This revision complements the commit rB6135556f4556.
Previously mesh objects were created for individual visible stroke segments (recalling that
a stroke may consist of alternate visible and invisible segments). This could result in an
excessive memory consumption in stroke rendering when strokes are composed of many
short visible segments (for instance by means of dashed lines and/or blueprint geometry
modifiers).
Now mesh objects represent individual strokes instead of stroke segments, which tends to
reduce the number of generated mesh objects by an order of magnitude.
Now that Freestyle employs a separate Main, this workaround is no longer necessary.
Reviewers: sergey
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D513
Legacy texture shaders from the original stand-alone Freestyle program are also
declared as deprecated, in favor of Blender's new line style textures.
Patch contribution by Paolo Acampora. Thanks!
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.