| Age | Commit message (Collapse) | Author |
|---|
|
A volume shader should be able to request attributes, and still be rendered
as homogeneous if no volume attributes are available for the object.
|
|
|
|
|
|
|
|
correctly.
|
|
|
|
Those are stored in blender-buildbot repository now, so having them in
Blender only causes extra work to keep files in sync.
|
|
|
|
Wraps menutype poll, no functional changes.
|
|
Wrapps keymap poll, no functional changes.
|
|
|
|
|
|
|
|
When you were using autosmooth to generate some custom normals, and
created empty custom loop normal data, you would go back to an 'all
smooth' shading, cancelling some sharp edges generated by the mesh's
smooth threshold.
Now we will first tag such edges as sharp, such that shading remains the
same. This is not crucial in current master, but it is for clnors
editing gsoc branch!
|
|
|
|
Regression caused by earlier commits to improve the automerge behaviour.
In this case, the problems only occurred when moving a selected keyframe
forwards in time to overlap an unselected keyframe.
|
|
While it is necessary to ignore duplicates when doing Deselect/Column Select
(where double-updates may result in nothing being selected), for borderselect,
not including the duplicates meant that sometimes, nothing would happen
if you were trying to borderselect keyframes originating from hidden channels.
This was first noticed in the greasepencil-object branch, but affects all
animation channel types.
|
|
|
|
|
|
|
|
Makes it easier to add or remove fields needed to update relations.
|
|
This allows us to:
- Not mock around with tags stored in a global space,
and not to iterate over all datablocks in the database
to clear the tags.
- Properly deal with datablocks which might not be in main database.
While it sounds crazy, it might be handy when dealing with preview,
or some partial scene updates, such as motion paths.
- Avoids majority of places where depsgraph construction needed bmain.
This is something what could help in blender2.8 branch.
From tests with production file here did not see any measurable slowdown.
Hopefully, there is no functional changes :)
|
|
Currently unused, actual logic change will come in the next commit.
|
|
Was printing some tagging/evaluation prints when only building
messages were requested.
|
|
|
|
|
|
This mainly helps with dense volumes, rendering can be 30% faster with
little noise increase in such scenes.
|
|
We now continue transparent paths after diffuse/glossy/transmission/volume
bounces are exceeded. This avoids unexpected boundaries in volumes with
transparent boundaries. It is also required for MIS to work correctly with
transparent surfaces, as we also continue through these in shadow rays.
The main visible changes is that volumes will now be lit by the background
even at volume bounces 0, same as surfaces.
Fixes T53914 and T54103.
|
|
|
|
|
|
|
|
Unify the path and branched path indirect SSS code. No performance impact
found on CUDA, for AMD split kernel the extra code was already there.
|
|
|
|
|
|
The other approach was causing too much error in some cases (e.g. favouring
the lower-valued keyframes). This fix should make the resulting curves less
bumpy/jagged.
|
|
|
|
This is to prevent problems with integer/enum properties getting invalid
values set.
|
|
|
|
unselected one would not merge the keys
This commit removes an earlier attempt at optimising the lookups
for duplicates of a particular tRetainedKeyframe once we'd already
deleted all the selected copies. The problem was that now, instead
of getting rid of the unselected keys (i.e. the basic function here),
we were only getting rid of the selected duplicates.
With this fix, unselected keyframes will now get removed (as expected)
again. However, we currently don't take their values into account
when merging keyframes, since it is assumed that we don't care so much
about their values when overriding.
|
|
tRetainedKeyframes
|
|
selected keys
that end up on the same frame
Currently, when scaling keyframes in the Dopesheet, if multiple
selected keyframes end up on the same frame post-scaling, they
would not get removed by the "Automerge" setting that normally
removes duplicates on the same frame.
This commit changes the behaviour so that when multiple selected
keyframes end up on the same frame, instead of keeping all these
around on the same frame (e.g. resulting in a column of keyframes
on different values), we will instead merge them into a single
keyframe (by averaging the values). This should result in a
smoother F-Curve with fewer "stair-steps" that need to be carefully
cleaned out afterwards.
Requested by @hjalti
|
|
This shouldn't affect anything currently, as this function doesn't appear
to get used anywhere.
|
|
name-based-filtering is enabled
This bug took a while to track down. In the test file with this report,
the Nla-Strip Control Curve for strip time would get disabled if you
changed the NLA Editor to a second Graph Editor instance.
It turns out that because this second Graph Editor would have the
"filter fcurves by name" option enabled, this would trigger a lookup
of the referenced property's name (in order to test whether it matched
the filtering criteria). However, since that filtering code was written
before the introduction of these curves, it still assumed that the names
for these Control Curves should be handled the same as for standard FCurves.
Unfortunately, that doesn't work, as the property lookups fail if the standard
method is used - when the lookups fail, the F-Curves get tagged as being
invalid/disabled (and need to be reset using the "Revive Disabled FCurves"
operator).
Note: The changes in this patch look complicated, as I've had to shuffle
a bit of code around so that the name-filtering check can have access to
the additional info it needs. In the process, I've also removed the earlier
(hacky) approach where the control curves were getting added to a temp
buffer to get changed from normal FCurves to special ANIMTYPE_NLACURVES.
|
|
Applying the same fixes as introduced in 98d797b67c07e85889768bf8ecde292e9e6f70e9
this time, for the Graph and NLA editors
|
|
Not sure why we need a relation from solver to a tip local transform, this
will be handled via parent relation.
Fixes remaining dependency cycles reported in T54083.
|
|
It is not possible to address transform at particular position of constraint
stack, and when constraint is being addressed is usually from driver variable.
This fixes some of dependency cycles reported in T54083.
|
|
Now it's possible to have debug messages for following things:
- Graph construction
- Graph evaluation
- Graph tagging
|
|
Was accessing past the array boundaries.
Should be safe for 2.79a.
|
|
Handy to quickly see if a fix fixed any of the cycles in a real rig,
or whether it's introduced new ones.
|
|
This would use uninitialized filename variable,
looked into supporting this however generating proxies currently only
works for movies.
|
