The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
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
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
Main goal is to make API simpler to follow (at least ion terms what
is defined/declared where, as opposite of handful big headers which
includes all the declarations), and also avoid a big set of long and
obscure functions.
Now C-API files are split into smaller ones, following OpenSubdiv
behavior more closely, and also function pointers in structures
used a lot more, which shortens functions names,
UV integration part in GL Mesh is mainly stripped away, it needs
to be done differently. On a related topic, UV coordinates API in
converter needs to be removed as well, we do not need coordinates,
only island connectivity information there.
Additional changes:
- Varying interpolation in evaluator API are temporarily disabled,
need to extend API somewhere (probably, evaluator's API) to inform
layout information of vertex data (whether it contains varying
data, width, stride and such).
- Evaluator now can interpolate face-varying data.
Only works for adaptive refiner, since some issues in OpenSubdiv
itself.
Planned changes:
- Remove uv coordinates from TopologyConverter.
- Support evaluation of patches (as opposite to individual coordinates
as it happens currently).
- Support more flexible layout of varying and face-varying data.
It is stupid to assume varying is 3 floats and face-varying 2 floats.
- Support of second order derivatives.
- Everything else what i'm missing in this list.
