Also, fix own stupidity, no need to define ID callback in case we only have objects,
calling code knows to fallback to `foreachObjectLink()` when `foreachIDLink()` is missing...
For now simply show warning in the interface and fallback to regular subsurf
code. Supporting OpenSubdiv in edit mode in possible but not high priority
currently.
Mirror modifier was reporting that it depends on geometry of the object
used for mirror center which is incorrect -- only object matrix is needed
for modifier evaluation.
The idea of this commit is to make it so we can enable OpenSubdiv by default
for the release builds but keep it limited to the viewport only for a specific
meshes. This is a temporary solution for until all the needed features are
supported on the OpenSubdiv side.
Flag itself is done as a dedicated field in modifier DNA so we can easily
remove it in the future without ending up with some temporary flag hanging
around forever.
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.
Note that the collision modifier doesn't have any use for Loop indices,
so to avoid duplicating the loop array too,
MVertTri has been added which simply stores vertex indices (runtime only).
This commit contains all the remained parts needed for initial integration of
OpenSubdiv into Blender's subdivision surface code. Includes both GPU and CPU
backends which works in the following way:
- When SubSurf modifier is the last in the modifiers stack then GPU pipeline
of OpenSubdiv is used, making viewport performance as fast as possible.
This also requires graphscard with GLSL 1.5 support. If this requirement is
not met, then no GPU pipeline is used at all.
- If SubSurf is not a last modifier or if DerivesMesh is being evaluated for
rendering then CPU limit evaluation API from OpenSubdiv is used. This only
replaces the legacy evaluation code from CCGSubSurf_legacy, but keeps CCG
structures exactly the same as they used to be for ages now.
This integration is fully covered with ifdef and not enabled by default
because there are several TODOs to be solved first:
- Face varying data interpolation is not really cleanly implemented for GPU
in OpenSubdiv 3.0. It is also not implemented for limit evaluation API.
This basically means we'll have really hard time supporting UVs.
- Limit evaluation only works with adaptivly subdivided meshes so far, which
basically means all the points of CCG are pushed to the limit. This gives
different result from old code.
- There are some serious optimizations possible on the topology refiner
creation, which would speed up initial OpenSubdiv mesh creation.
- There are some hardcoded asumptions in the GPU and DerivedMesh areas which
could be generalized.
That's something where Antony and Campbell can help, making it so the code
is structured in a way which is reusable by all planned viewport projects.
- There are also some workarounds in the dependency graph to make sure OpenGL
buffers are only freed from the main thread.
Those who'll be wanting to make experiments with this code should grab dev
branch (NOT master) from
https://github.com/Nazg-Gul/OpenSubdiv/tree/dev
There are some patches applied in there which we're working on on getting
into upstream.
defvert_find_index() & co now assert when '-1' invalid vgroup index is passed.
We used to rely on NULL value returned in this case, but with the assert...
The assert completely stalls blender actually (repeated for every vertex!).
So much better to not call that func when vgroup index is invalid.
This allows to match and transfer data between two meshes with similar shape but complete arbitrary different transform.
Note that the result will be best if the meshes (more precisely, their vertices) are exact copies of each other.
Otherwise, method used can only perform an approximated best match, which means you'll likely get better
results if you 'visually' make them match in 3D space (and use 'Object Transform') instead.
Have reconsidered and feel it best to try matching previous behavior
(doing "loop slides" where possible) as default. This will avoid the
need to change regression tests, among other things.
Current behavior of bevel is to 'loop slide' along unbeveled edges
when possible, but this produces uneven bevel widths sometimes,
so this option lets user choose between having the loop slide effect
or having more even bevel widths. Trying it out with default being
'no loop slide', so different from current behavior. May reverse this
choice later, depending on user reactions.
- place return args last position
- move crazyspace function out of DerivedMesh header
- use bool for args
- flow control on own lines to ease debugging
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.
Add slider to adjust the influence of weights relative to geometry distortion.
This allows subtle influences to be applied - without drastic changes in behavior.
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 :)
