This fixes the first case mentioned in the report. Has to do some ugly
DNA access to SpaceNode, unless we'd allow a bad level call there to do
it in ED_node ...
The second case has been fixed by @sergey in D274:
https://developer.blender.org/D274?vs=838&id=879#toc
So actually asan just did its job here, good to know!
It was intended to work actually using particle cache's stack index
but this index might have been calculated incorrect in special case:
* With default cube scene, add particle system to the cube
* Add disk cache to the particle system
* Save file and reload it
* Add another particle system and enable disk cache
This would lead to two point caches with the same stack index of zero.
This happened because point cache indices list wasn't stored in the
.blend file so once you've reload your file blender doesn't know anything
about number or point caches used.
And what was even more confusing is that point cache indices list was
trying to be load from the file, but this failed because it wasn't in the
file.
This commit solves the root of the issue which is ability of producing
.blend file with two point caches using the same disk cache. This is
done by making it sure that point cache indices list is stored in the
.blend file. And also made it so disabling disk cache will tag it to
recalculate stack index.
Old broken files wouldn't magically start working, but fixing them is
rather simple manually by toggling Disk Cache option.
Reviewers: lukastoenne, brecht
CC: sergof
Differential Revision: https://developer.blender.org/D286
This in fact seems some kind of video driver limitation, because it worked fine
on windows but failed on linux here. The guess is that textures doesn't always
work on display lists, or we simply do have some wrong OGL context somewhere.
This is a workaround for until bigger viewport draw refactor is done (as Brecht
mentioned display lists are deprecated in new OGL anyway).
Root of the issue goes to the order of particle initialization which does
texture evaluation (which does depend on particle coordinate) and particle
birth coordinate calculation. So basically what happened is:
* Changing number of particles re-allocated all the particles,
which sets their coordinate to (0,0,0)
* Texture evaluation used this non-initialized coordinate
* Coordinates were calculated for particles
Reshuffled code a bit so now texture evaluation happens after particles.
coordinate calculation. Basically moved texture evaluation to particle
reset function. Reset happens after initialization anyway and it does
know particle coordinates. Also, if reset is being called without init
then it's also kind of logical to re-evaluate texture because particle
coordinates might change.
As discussed in T38340 the solution is to use the current scene from
context whenever feasible.
Composite does not use node->id at all now, the scene which owns the
compositing node tree is retrieved from context instead.
Defocus node->id is made editable by the user. By default it is not set,
which also will make it use the contextual scene and camera info.
The node->id pointer in Defocus is **not** cleared in older blend files.
This is done for backward compatibility: the node will then behave as
before in untouched scenes.
File Output nodes also don't store scene in node->id. This is only needed
when creating a new node for initializing the file format.
Reviewers: brecht, jbakker, mdewanchand
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D290
COLOR widgets never get created with UI_GRAD_V_ALT values. This is
intended for HSVCUBE color sliders only so reverting this to old value
before it was substituted with a define, which was -1.
There's one case where COLOR buttons get defined with a1 value different
than -1 which is in ui_def_but_rna. There the step value of the RNA
property is used. However, that meant that if step equaled to 9, which
is UI_GRAD_V_ALT value (unlikely) or if UI_GRAD_V_ALT was changed to 10
in future, or we added check for e.g. UI_GRAD_L_ALT which is 10 in HCL
branch, color widget would not get a color selection menu spawned.
Support for tagging polygon numbers when adding scanfill data,
saves having to calculate connectivity afterwards (which can take approx half overall scanfill time for complex curves).
The documentation for the -b/--background option incorrectly states that it
takes a <file>, however it can run also without a file with e.g. a script.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D250
Issue was caused by NULL-pointer de-reference when post-processing
the frame without putting the frame to movie cache.
Differential Revision: https://developer.blender.org/D276
Issue was in fact in strip update code when transforming, in case we move both left and right
handles the strip is handled twice in the loop, but it was always updated at the end of the
first loop only...
Crash was caused by missing curve_cache due to cyclic dependency.
This commit is rather a workaround, but we couldn't really guarantee
proper behavior in cases with cyclic dependency. So rather than calling
object update directly as it used to be let's don't perform curve
deform and be safe for threading instead.
