When the object we iterate over is not part of the depsgraph, we cannot
get the evaluated copy to export. This workaround is temporary to avoid
a BLI_assert() failure getting the evaluated mesh of this object.
This will be handled more elegantly in the new AbstractHierarchyIterator
that I'm working on, but that requires a bigger change than we should
allow this close to the 2.80 release candidate.
This fixes a problem described in T58686.
Blender 2.8 features significant improvements in the creation of particles.
Removed hard limit and increased soft limit.
Patch by Gottfried Hofmann.
Differential Revision: https://developer.blender.org/D5120
The issue was caused by modifications to planar track tagging clip for
copy-on-write, which was invalidating its cache and forcing current
frame in 3D viewport to be re-load.
Ideal solution would be to share movie cache across original and
evaluated movie clips which will reduce memory usage. However, doing
such ownership changes so close to the code freeze is not something
comfortable to do.
When accessing evaluated objects, make sure access to an
evaluated dependency graph is done. This solves possible
access to NULL data on redo.
See https://developer.blender.org/D5209
I don't know if it was the intended behavior or not, but having brush
and canvas data at the same time with dymanic paint, would lead to the
object trying to act as a brush and a canvas at the same time.
We can't currently handle this with the new depsgraph, and it could
legitimately lead to bad feedback loops.
So now, to be more consistent with the GUI, I've made it only use the
current set type (brush or canvas) as the final type of the object.
That is, you can only have a object be a brush or a canvas, not both at
the same time.
The operator was using a non-evaluated depsgraph to get the evaluated
scene, which caused the crash.
This fixes the crash reported in T66605, but not the problem where
sometimes object origins aren't set.
We check if the previous iteration (sample) was using a valid double buffer.
If it wasn't, we request another iteration.
This fix the issue for viewport,viewport render and image render.
Related to T65761 Eevee render inconsistency between 3D View, Viewport render, and F12 Render
The AMD PRO driver on linux PROXY check also fails. Now the
configuration ATI/Unix/Official driver will also bypass the
Proxy test.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D5205
The `tselem->id` pointer can also be used for non-ID data (according to
this comment in DNA_outliner_types.h:
```
/* XXX We actually also store non-ID data in this pointer for identifying
* the TreeStoreElem for a TreeElement when rebuilding the tree. Ugly! */
```
As such, I don't mind adding a `NULL`-check in the
`is_object_data_in_editmode()` function. After all, when there is no
object, its data certainly is not in edit mode.
Allows to disable keyframes from movie clips in dopesheet.
Reviewers: brecht
Reviewed By: brecht
Subscribers: sebastian_k
Differential Revision: https://developer.blender.org/D5203
Don't update animdata after rendering scene
Rendering host scene from sequencer is not supported, removed code is unnecessary.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5199
Previously in 2.79 we were using a specialized drawing using derivedMesh.
Now the subsurf modifier tag each center vertex as facedot and let the
DRWManager pick it up.
Some modifiers (deforming ones) do not clear the tag so we can use this
technique even if there is deforming modifiers after subsurf modifiers.
Looks like that code was not updated when we switched to unicode, it was
still returning axtended ascii codes (iso-8859-15 ones I think)...
That was breaking some chars, which have a very different value in
unicode. Found while working on Text section of the Manual! ;)
Moved the caching code from direct calls in DNA to dependency graph.
In fact, not much was needed to be done apart form removing the direct
cache updates. The rest seemed to work fine.
Possible to avoid full sound file re-load, but doesn't seem this is
causing any issues.
