| Age | Commit message (Collapse) | Author |
|---|
|
OSD Lists as 0, 0, 0 this is due to opensubdiv_capi.cc not actually including
the OSD version header, so it's not getting the version define, and the code
in openSubdiv_getVersionHex is really well prepared to deal with any or no
version at all of OSD, catches the problem and returns 0, 0, 0
Given this file is only build when OSD is enabled we can just blindly include
opensubdiv/version.h here
Reviewed by: brecht
Differential Revision: https://developer.blender.org/D16398
|
|
OpenSubdiv OpenMP detection was interfering, but we don't use it there
anymore so just remove that code.
|
|
This is already the case for most CMake usage.
Although some find modules are an exception to this, as they were
originally maintained externally they use some different conventions.
Also corrected bad indentation in: intern/cycles/CMakeLists.txt
|
|
Switch to target_ functions to avoid this.
|
|
|
|
This cleans up the OpenGL build flags and linking.
It additionally also removes some dead code.
One of these dead code paths is WITH_X11_ALPHA which actually never was
active even with the build flag on. The call to use this was never
called because the default initializer for GHOST was set to have it off
per default. Nothing called this function with a boolean value to enable it.
These cleanups are needed to support true headless OpenGL rendering.
Without these cleanups libepoxy will fail to load the correct OpenGL
Libraries as we have already linked them to the blender binary.
Reviewed By: Brecht, Campbell, Jeroen
Differential Revision: http://developer.blender.org/D15554
|
|
With libepoxy we can choose between EGL and GLX at runtime, as well as
dynamically open EGL and GLX libraries without linking to them.
This will make it possible to build with Wayland, EGL, GLVND support while
still running on systems that only have X11, GLX and libGL. It also paves
the way for headless rendering through EGL.
libepoxy is a new library dependency, and is included in the precompiled
libraries. GLEW is no longer a dependency, and WITH_SYSTEM_GLEW was removed.
Includes contributions by Brecht Van Lommel, Ray Molenkamp, Campbell Barton
and Sergey Sharybin.
Ref T76428
Differential Revision: https://developer.blender.org/D15291
|
|
|
|
openSubdiv_init() would detect available evaluators before any OpenGL context
exists, causing a crash with libepoxy. This test however is redundant as we
already check the requirements on the Blender side through the GPU API.
To simplify things, completely remove the device detection in the opensubdiv
module and reduce the evaluators to just CPU and GPU. The plan here is to move
to the GPU module abstraction over OpenGL/Metal/Vulkan and so all these
different backends no longer make sense.
This also removes the user preference for OpenSubdiv compute device, which was
not used for the new GPU subdivision implementation.
Ref D15291
Differential Revision: https://developer.blender.org/D15470
|
|
|
|
When multiple objects are in edit mode, UVs for the objects, except for
the first one (in rendering order) appear corrupted. The corruption is
because the UVs are not evaluated as the compute shader is not bound,
thus we read unitialized memory.
We keep track of the currently bound shader in the GPU context in order
to avoid unnecessary shader switches in case the same shader is used in
consecutive calls. However, the shader used by the OpenSubdiv evaluator
is not part of Blender and therefore not tracked via the GPU context.
When extracting UVs for multiple objects, we only ever run a single
shader (FVar evaluation). However, between the compute calls, we also
call the OpenSubdiv stencil evaluation shader, which uses `glUseProgram`
modifying the current program, outside of our control, which then also
unbinds the Blender compute shader making the compute dispatch fail ("No
active compute shader").
The fact that extracting the UVs for the first rendered object works is
because another (Blender) shader was bound in the GPU context prior to
our binding of our evaluation shader.
To fix this, we remember, in the OpenSubdiv evaluator, the current
program so that it can be reset after the stencil program is done.
Differential Revision: https://developer.blender.org/D15064
|
|
|
|
Building problem introduced on 24e74f8bef813820. It affects `make lite`
and other builds that skip OpenSubdiv.
|
|
|
|
|
|
Contributed by luzpaz
Differential Revision: https://developer.blender.org/D15057
|
|
Subdivision did not properly update when evaluating first without and then with
orco coordinates. Now update the subdivision evaluator settings every time, and
reallocate the vertex data buffer when needed.
there is an additional issue in this file where orco coordinates are not
available immediately on the first frame when they should be, and only appear
on the second frame. However that is an old limitation related to the depsgraph
not getting re-evaluated on viewport display mode changes, here we just fix the
crash.
|
|
This uses the recently introduced evaluator's vertex
data to smoothly interpolate original coordinates instead
of using linear interpolation.
The orcos are interpolated at the same time as positions
and as such, the specific subdivision routine for the
orco extractor has been removed. The patch evaluation
shader uses a definition to enable code specific to
orco evaluation.
Since the orco layer may not have been requested on first
render, and since orco data is now stored in the OpenSubDiv
evaluator, the evaluator needs to be recreated if an
orco layer is suddenly available. For this, a callback
to check if the evaluator has the data was added. This is
added to the evaluator as the `Subdiv` cache stored in the
modifier is invalidated less often than the Mesh batch cache
and so leads to fewer evaluator recreations.
Differential Revision: https://developer.blender.org/D14999
|
|
|
|
This makes changes to the opensubdiv module to support additional vertex data
besides the vertex position, that is smootly interpolated the same way. This is
different than varying data which is interpolated linearly.
Fixes T96596: wrong generated texture coordinates with GPU subdivision. In that
bug lazy subdivision would not interpolate orcos.
Later on, this implementation can also be used to remove the modifier stack
mechanism where modifiers are evaluated a second time for orcos, which is messy
and inefficient. But that's a more risky change, this is just the part to fix
the bug in 3.2.
Differential Revision: https://developer.blender.org/D14973
|
|
|
|
Also add missing task-ID reference & remove colon after \note as it
doesn't render properly in doxygen.
|
|
The fix does not fix the case of shaders comming from the OpenSubdiv API.
This reverts commit f5191b87608f6607aa1dbd4b9409174db351984b.
|
|
This was caused by the use of a reserved keyword macro that is not
directly used but causes an error on some compiler.
Change the occurences to not match the macros.
|
|
|
|
|
|
|
|
|
|
|
|
`uint` is POSIX type, use `GLuint` like for the rest of the code.
|
|
|
|
Coarse meshes with high polycount would show as corrupted when GPU
subdivision is used with AMD cards This was caused by the OpenSubdiv
library not taking `GL_MAX_COMPUTE_WORK_GROUP_COUNT` into account when
dispatching computes. AMD drivers tend to set the limit lower than
NVidia ones (2^16 for the former, and 2^32 for the latter, at least
on my machine).
This moves the `GLComputeEvaluator` from the OpenSubdiv library into
`intern/opensubdiv` and modifies it to compute a dispatch size in a
similar way as for the draw code: we split the dispatch size into a 2
dimensional value based on `GL_MAX_COMPUTE_WORK_GROUP_COUNT` and
manually compute an index in the shader.
We could have patched the OpenSubdiv library and sent the fix upstream
(which can still be done), however, moving it to our side allows us to
better control the `GLComputeEvaluator` and in the future remove some
redundant work that it does compared to Blender (see T94644) and
probably prepare the ground for Vulkan support. As a matter of fact,
this patch also removes the OpenGL initialization that OpenSubdiv would
do here. This removal is not related to the bug fix, but necessary to not
have to copy more files/code over.
Differential Revision: https://developer.blender.org/D14131
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D13532
|
|
std::min was used without including the algorithm
header. Seems to be implicitly included by
something in newer MSVC versions and GCC, however
vs16.4 needed a little help here.
|
|
Stubs were missing for functions added to opensubdiv_evaluator_capi.h
|
|
This evaluator is used in order to evaluate subdivision at render time, allowing for
faster renders of meshes with a subdivision surface modifier placed at the last
position in the modifier list.
When evaluating the subsurf modifier, we detect whether we can delegate evaluation
to the draw code. If so, the subdivision is first evaluated on the GPU using our own
custom evaluator (only the coarse data needs to be initially sent to the GPU), then,
buffers for the final `MeshBufferCache` are filled on the GPU using a set of
compute shaders. However, some buffers are still filled on the CPU side, if doing so
on the GPU is impractical (e.g. the line adjacency buffer used for x-ray, whose
logic is hardly GPU compatible).
This is done at the mesh buffer extraction level so that the result can be readily used
in the various OpenGL engines, without having to write custom geometry or tesselation
shaders.
We use our own subdivision evaluation shaders, instead of OpenSubDiv's vanilla one, in
order to control the data layout, and interpolation. For example, we store vertex colors
as compressed 16-bit integers, while OpenSubDiv's default evaluator only work for float
types.
In order to still access the modified geometry on the CPU side, for use in modifiers
or transform operators, a dedicated wrapper type is added `MESH_WRAPPER_TYPE_SUBD`.
Subdivision will be lazily evaluated via `BKE_object_get_evaluated_mesh` which will
create such a wrapper if possible. If the final subdivision surface is not needed on
the CPU side, `BKE_object_get_evaluated_mesh_no_subsurf` should be used.
Enabling or disabling GPU subdivision can be done through the user preferences (under
Viewport -> Subdivision).
See patch description for benchmarks.
Reviewed By: campbellbarton, jbakker, fclem, brecht, #eevee_viewport
Differential Revision: https://developer.blender.org/D12406
|
|
Using the `MEM_*` API from C++ code was a bit annoying:
* When converting C to C++ code, one often has to add a type cast on
returned `void *`. That leads to having the same type name three times
in the same line. This patch reduces the amount to two and removes the
`sizeof(...)` from the line.
* The existing alternative of using `OBJECT_GUARDED_NEW` looks a out
of place compared to other allocation methods. Sometimes
`MEM_CXX_CLASS_ALLOC_FUNCS` can be used when structs are defined
in C++ code. It doesn't look great but it's definitely better. The downside
is that it makes the name of the allocation less useful. That's because
the same name is used for all allocations of a type, independend of
where it is allocated.
This patch introduces three new functions: `MEM_new`, `MEM_cnew` and
`MEM_delete`. These cover the majority of use cases (array allocation is
not covered).
The `OBJECT_GUARDED_*` macros are removed because they are not
needed anymore.
Differential Revision: https://developer.blender.org/D13502
|
|
|
|
|
|
No functional changes.
|
|
This change transitions libmv/osd tests to our
blender_add_test_executable macro that explicitly
takes the include directories as a parameter.
This is in preparation for future clean-up of
global include directories.
Differential Revision: https://developer.blender.org/D12012
Reviewed By: sergey
|
|
|
|
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
|
|
This makes subdivision surfaces compatible with the old subdivision
surface modifier and other applications that do not use the limit surface.
This option is available on the Subdivision Surface modifier.
Differential Revision: https://developer.blender.org/D8413
|
|
|
|
Ref {D8855}
Unix and Apple platform files use find_package(OpenSubdiv) which sets
`OPENSUBDIV_INCLUDE_DIR` as an advanced variable, as well as
`OPENSUBDIV_INCLUDE_DIRS` which should be used usually.
Windows sets `OPENSUBDIV_INCLUDE_DIR` which is used by the rest
of the code.
This patch renames it to `_DIRS` everywhere, for it to be like other
similar variables.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8917
|
|
This change makes it so vertices of edge are only stored when edge
has non-zero crease. This allows to lower memory footprint of 1.5M
faces from 78 MiB to 54 MiB in the case all creases are zero.
Meshes with crease are more hard to predict due to array-based
storage, so it all depends on index of edge with crease. Worst case
(all edges are creased) still stays at 78 MiB.
|
|
Makes it possible to set adjacent vertices after edge sharpness.
Initially it seemed like useful sanity check, but with time it
became rather a burden.
|
|
Avoid per-face pointer and allocation: store everything as continuous
arrays.
Memory footprint for 1.5M faces:
- Theoretical worst case (all vertices and edges have crease) memory
goes down from 114 MiB to 96 MiB (15% improvement).
This case is not currently achievable since Blender does not expose
vertex crease yet.
- Current real life worst case (all edges have crease) memory goes
down from 108 MiB to 90 MiB (17% improvement).
- Best case (no creases at all) memory goes down from 96 MiB to 78 MiB
(19% improvement).
|
