| Age | Commit message (Collapse) | Author |
|---|
|
Useful for cases when topology does not need to have any
crease or UV layers. Now instead of assigning callbacks
which returns zero data is possible to simply assign the
callback itself to NULL.
|
|
|
|
This is a more correct fix to the issue Brecht was fixing in D6600.
While the fix in that patch worked fine for linking it broke ASAN
runtime under some circumstances.
For example, `make full debug developer` would compile, but trying
to start blender will cause assert failure in ASAN (related on check
that ASAN is not running already).
Top-level idea: leave it to CMake to keep track of dependency graph.
The root of the issue comes to the fact that target like "blender" is
configured to use a lot of static libraries coming from Blender sources
and to use external static libraries. There is nothing which ensures
order between blender's and external libraries. Only order of blender
libraries is guaranteed.
It was possible that due to a cycle or other circumstances some of
blender libraries would have been passed to linker after libraries
it uses, causing linker errors.
For example, this order will likely fail:
libbf_blenfont.a libfreetype6.a libbf_blenfont.a
This change makes it so blender libraries are explicitly provided
their dependencies to an external libraries, which allows CMake to
ensure they are always linked against them.
General rule here: if bf_foo depends on an external library it is
to be provided to LIBS for bf_foo.
For example, if bf_blenkernel depends on opensubdiv then LIBS in
blenkernel's CMakeLists.txt is to include OPENSUBDIB_LIBRARIES.
The change is made based on searching for used include folders
such as OPENSUBDIV_INCLUDE_DIRS and adding corresponding libraries
to LIBS ion that CMakeLists.txt. Transitive dependencies are not
simplified by this approach, but I am not aware of any downside of
this: CMake should be smart enough to simplify them on its side.
And even if not, this shouldn't affect linking time.
Benefit of not relying on transitive dependencies is that build
system is more robust towards future changes. For example, if
bf_intern_opensubiv is no longer depends on OPENSUBDIV_LIBRARIES
and all such code is moved to bf_blenkernel this will not break
linking.
The not-so-trivial part is change to blender_add_lib (and its
version in Cycles). The complexity is caused by libraries being
provided as a single list argument which doesn't allow to use
different release and debug libraries on Windows. The idea is:
- Have every library prefixed as "optimized" or "debug" if
separation is needed (non-prefixed libraries will be considered
"generic").
- Loop through libraries passed to function and do simple parsing
which will look for "optimized" and "debug" words and specify
following library to corresponding category.
This isn't something particularly great. Alternative would be to
use target_link_libraries() directly, which sounds like more code
but which is more explicit and allows to have more flexibility
and control comparing to wrapper approach.
Tested the following configurations on Linux, macOS and Windows:
- make full debug developer
- make full release developer
- make lite debug developer
- make lite release developer
NOTE: Linux libraries needs to be compiled with D6641 applied,
otherwise, depending on configuration, it's possible to run into
duplicated zlib symbols error.
Differential Revision: https://developer.blender.org/D6642
|
|
Switch to Gregory basis patches which are tangent continuous across their
boundaries.
Originally we've used BSpline basis patches to be more compatible with the
old subdivision code, but a lot of things changed anyway.
|
|
The idea is to give multiple coordinates to evaluator and evaluate them
all at once, avoiding any possible overhead.
|
|
Allows to pass multiple patch coordinates for evaluation.
|
|
Saves another unnecessary temporary data copy during evaluation.
|
|
Consider that all builders have face-varying evaluation now.
|
|
|
|
Make evaluator itself to write directly to the output buffer.
Brings unmeasurable speedup and makes it possible to simplify
some buffer class logic.
|
|
We currently don't support interleaved varying data, so can make
some buffer smaller.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 7c9f64d00835:
"Fix T63766: Multiresolution behavior when using crease edge"
|
|
Switch to Gregory basis patches which are tangent continuous across their
boundaries.
Originally we've used BSpline basis patches to be more compatible with the
old subdivision code, but a lot of things changed anyway.
|
|
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
No functional change, this adds LIB definition and args to cmake files.
Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS'
since there are many platforms/configurations that could break when
changing linking order.
Manually add and enable WITHOUT_SORTED_LIBS to try building
without sorted libs (currently fails since all variables are empty).
This check will eventually be removed.
See T46725.
|
|
Caused by missing vertex sharpness comparison in the topology
comparator.
|
|
Following removal from C source code.
See: 8c68ed6df16d8893
|
|
|
|
|
|
Fix T60502: Creasing behavior on 2.8 seams wrong
Was a mistake in a boundary vertices sharpness calculation.
|
|
|
|
It is no longer used and has some issues in corner cases
which are not handled in a way which OpenSubdiv expects.
|
|
|
|
This fixes following errors:
- The code didn't work correctly for edges reconstructed by
the OpenSubdiv's topology refiner (due to indexing
difference).
- Sharpness of non-manifold and boundary edges was not
working correctly.
|
|
Replaces direct access to std.
|
|
|
|
|
|
Only affects internal API, bout could be exposed as an option for
the compatibility reasons with other software.
Is a part of some ongoing development of multires, but might or
might not be used.
|
|
|
|
|
|
|
|
|
|
We currently don't use those. Skipping creation of stencils for
them gives about 7% speedup of evaluation creation.
|
|
|
|
C-API is way smaller than the rest of the code which uses it.
So better to conditionally compile stub implementation than
to keep adding ifdef everywhere.
|
|
|
|
Enabled infinite sharp patches for topology refiner and evaluator,
which allows to have sharp edge at first subdivision level.
Also tweaked crease export from Blender to OpenSubdiv to have more
artistic control over the whole 0..1 range.
|
|
Before that it was only first UV layer which was properly evaluated,
the rest were ignored. Now all layers are being properly handled.
|
|
Currently unused, added for the future and API completeness.
|
|
The idea is simple: do not provide full topology to OpenSubdiv, leave
edges creation to OpenSubdiv itself. This solves issues with non-manifold
meshes which were known to fail, including the ones from T52059.
On a positive side we can simplify our side of converter, keeping code
shorter.
it is still possible that we'll need to ensure all loops has same
winding, but that is less things to worry about.
|
|
Seems it's behaving correct now, surely more tests needed, but
this is required for now to move forward.
|
|
Applies to vertices and edges. Biggest annoyance here is that OpenSubdiv's
topology converter expects that there is no loose geometry, otherwise it
is getting confused.
For now solution is to create some sort of mapping from real Mesh vertex
and edge index to a non-loose-index. Now the annoying part is that this
is an extra step to calculate before we can compare topology, meaning FPS
will not be as great as if we knew for sure that topology didn't change.
Loose edges subdivision is different from what it used to be with old
subdivision code, but probably nice feature now is that endpoints of loose
edges are stay at the coarse vertex locations. This allows to have things
like plane with hair strands, without need to duplicate edge vertices at
endpoints.
All this required some re-work of topology refiner creation, which is now
only passing edges and vertices which are adjacent to face. This is how
topology refiner is supposed to be used, and this is how its validator
also works. Vertices which are adjacent to loose edges are marked as
infinite sharp. This seems to be good-enough approximation for now. In the
future we might tweaks things a bit and push such vertices in average
direction of loose edges, to match old subdivision code closer.
|
