| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Was only visible with new dependency graph.
Changing emit_from still doesn't behave fully reliably tho, that needs some
closer investigation.
|
|
|
|
Issue was caused by blender internal accessing data from DNA during rendering.
There's no simple solution to make stuff thread safe, so for now simply restart
rendering on frame update.
|
|
|
|
new DEG
|
|
* Resolved some todo's where FModifier paths were getting identified using the
wrong pattern.
* Added the missing animation -> modifier link. The "hacky" part here is just
to do with how we check if that link is needed; the link though should exist
in the graph.
|
|
|
|
|
|
Cases like using subsurfed object as a boolean operand can't be evaluated
on GPU and needs to have all the CCG on CPU.
This commit resolves existing configuration to survive, but new configurations
would need to have some sort of forced object update so all the data is being
moved on CPU if it was previously on GPU.
|
|
Two issues fixed in this commit:
- Clearing or adding animation via python should ensure relations are valid.
- Animation component animation data might be null caused by removing animation
from python.
|
|
|
|
It's quite tricky to see if the driver actually depends on time or not,
so currently used approach when we'll be doing some extra updates.
This seems to correspond to how old depsgraph was dealing with this.
|
|
|
|
|
|
test build
Was just a few missing dependencies.
|
|
|
|
|
|
It's not ideal and mimics weak legacy code, but so close to bcon4 we'd better
not start re-considering the way how particle works..
|
|
graph
|
|
|
|
|
|
|
|
Issue was caused by drivers which uses component of an array as a target,
this was not handled properly in the RNA path key.
|
|
evaluation
This way it is possible to have single threaded depsgraph but threaded other areas
which is handy for torubleshooting.
he argument is: --debug-depsgraph-no-threads
|
|
Also add depsgraph & physics
|
|
|
|
|
|
|
|
Simple highschool rated issue -- uninitialized variable :)
|
|
|
|
It has some weird incompatibility with the way how Boost and GCC C++11
function bindings works, resulting in compilation errors.
|
|
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
|
