If the active image node contributes to the final material shader
(meaning it's either directly or indirectly connected to an Output Node)
the user will receive an alert about circular dependency.
Similar to what we do for Blender internal the baking will still happen,
but the user will receive the alert which should prevent the image
saving to happen if the result was not intentional.
Core function to check for node output written by Lukas Toenne.
Reviewers: lukastoenne, campbellbarton
Differential Revision: https://developer.blender.org/D673
Rename UI_init_userdef_factory to BLO_update_defaults_userpref_blend
This closely matches BLO_update_defaults_startup_blend so makes sense for them to be together.
The issue was caused by the wrong objects order for
convertblender.c. Dependency graph totally missed
handling of this situation.
Fixed now, but it's not that pretty, don't try this
at home obviously. But consider this to be good enough
for the current dependency graph.
Details are in the build_dag_object().
Yep, at last it's here!
There are a few minor issues remaining but development can go on in
master after discussion at blender institute.
For full list of features see:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Painting
Thanks to Sergey and Campbell for the extensive review and to the
countless artists that have given their input and reported issues during
development.
The "Show All" and "Show Selected" operators in the Graph Editor was taking into
account all handles on keyframes, even when some of those would be invalid and/or
set to nonsense values (e.g. for any interpolation mode other than "Bezier")
There were several small issues/inconsistencies if how particles' org face index was checked,
leading in some cases to invalid indices and hence mem access, in RNA UV/VCol compute for particles.
Note org code RNA one was copied from (in BI's convertblender.s) is much more complicated,
and seems to never reach those breaking conditions.
Also deduplicated most code in those UV/VCol particles funcs, they were doing mostly the same thing!
Finally, also got rid of annoying `NO CD_ORIGSPACE, error out of range` error message in console,
was another case of not checking whether we did have any faces in final mesh!
Currently this gaussian blur implementation accumulates values in the
square kernel rather that doing X direction and then Y direction because
of the lack of using multiple-staged filters.
Once we can we'll implement a way to apply filter as multiple stages we
can optimize hell of a lot in here.
Another thing we can do is to use SSE2 instructions here.
BKE_scene_base_iter_next() was completely messing poor dupli objects' matrices...
Note this func should be reworked, but as stated in comments, it should not exist at all,
DAG should be used here, so until we have new shinny one we can live with this.
Also, mballs do not behave correctly when used as duplis (org object remains visible/rendered,
unlike any other object type). This will be fixed in a separate patch/commit,
since it proved to be rather tricky to handle.
BKE_mball_basis_find() was making a bunch of string manipulations for all MBall objects
(including duplis), and then making a (broken!) check to do nothing in case of duplis mball!
Now it makes correct check in early stage.
This is related to Task T34861 to increase up & track axis options for TrackTo actuator. I've just added it to differential to facilitate an easier review.
With the patch applied you can select X, Y and Z axis for the Up axis, and X, Y, Z, -X, -Y and -Z for the track axis.
Related to the implementation I have used the algorithm from Trackto constrain placed in constrain.c but adapted to be used with MOTO library.
The wiki docs are here (http://wiki.blender.org/index.php/User:Lordloki/Doc:2.6/Manual/Game_Engine/Logic/Actuators/Edit_Object#Trackto_Actuator).
Test file is here: {F97623}
I have also uploaded 2 screenshots showing the UI modifications to the TrackTo actuator:
{F91992} {F91990}
Reviewers: moguri, dfelinto
Reviewed By: moguri
CC: Genome36
Differential Revision: https://developer.blender.org/D565
This was a ToDo item, for mesh-based rigid body shapes (trimesh, convex)
the operator was simply using the bounding box volume, which can grossly
overestimate the volume and mass.
Calculating the actual volume of a mesh is not so difficult after all,
see e.g.
http://research.microsoft.com/en-us/um/people/chazhang/publications/icip01_ChaZhang.pdf
This patch also allows calculating the center-of-mass in the same way.
This is currently unused, because the rigid body system assumes the CoM
to be the same as the geometric object center. This is fine most of the
time, adding such user settings for "center-of-mass offset" would also
add quite a bit of complexity in user space, but it could be necessary
at some point. A number of other physical properties could be calculated
using the same principle, e.g. the moment of inertia.
correctly.
Problem was that object layers are defined by duplis as the top-level
duplicator layers. This happens //during// the duplilist construction,
which breaks group layer checks for subsequent instances and hides them.
Now the duplilist generators leave Object DNA untouched, the
modification of layers for drawing, rendering, etc. happens afterward
in the duplilist_apply/restore functions, as a kind of second pass.
To do so, matching BKE 'API' was also refactored a bit:
* Get Pose data instead of Object, as parameter;
* Removed some sanity checks not needed at such a low level (callers are supposed to do that);
* You can now remove an arbitrary bone group, not only the active one.
Based on patch by pkrime (Paolo Acampora), with own edits.
Reviewers: #python, pkrime, aligorith
Reviewed By: aligorith
Differential Revision: https://developer.blender.org/D522
Fix T39286: Display percentage ignored in Cycles viewport.
The threaded depsgraph update changes included a cleanup of the global
is_rendering flag, which was replaced by a general EvalContext being
passed to dupli functions.
Problem is that the global flag was true for viewport duplis before
(ugly hack), which was used as a check for generating dupli orco/UV from
mesh data layers. The new flag is stricter and only true for actual
renders, which disables these attributes and breaks the Cycles
Texture Coordinates and UVMap nodes.
The solution is to extend the simple for_render boolean to an enum:
* VIEWPORT: OpenGL viewport drawing (dupli tex coords omitted)
* PREVIEW: Viewport preview render (simplified modifiers)
* RENDER: Full render with all details and attributes
There are still some areas that need to be examined, in particular
modifiers seem to totally ignore the EvaluationContext!
Instead they generally execute without render params from the depsgraph
(BKE_object_handle_update_ex) and are built with render settings
explicitly.
Differential Revision: https://developer.blender.org/D613
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).
In rB78c491e the `initialize_particle` function was split into 2 parts for particle texture initialization.
The texture init part however also initializes birth times, which is now missing in the main init function
in some cases (notably when setting start/end directly without a subsequent time step).
Blender Internal only uses materials with non-zero user counter for SSS and new
mutable libblock copy was keeping users counter at zero.
Now it sets user counter to 1, which is a bit of arguable decision, but which
also kind of makes sense -- meaning callee owns the copied block.
A bit hackish solution for now, cleaner solution we'll look into as a
part of the new DAG project, when it's clear what kind of data is passed
to the evaluation callbacks.
