This makes no sense to have in the draw namespace.
Also take the opportunity for making the coordinates
a float2 and rename them to something more descriptive.
This unify the C++ and GLSL codebase style.
The GLSL types are still in the backend compatibility
layers to support python shaders. However, the C++
shader compilation layer doesn't have them to enforce
correct type usage.
Note that this is going to break pretty much all PRs
in flight that targets shader code.
Rel #137261
Pull Request: https://projects.blender.org/blender/blender/pulls/137369
They are actually already some literals with the `f` suffix
that are in our shader codebase and we never had problem in
the past 5 years (or even 8 years).
So I think it is safe to do and improves convergence of codestyles.
Pull Request: https://projects.blender.org/blender/blender/pulls/137352
This changes the include directive to use the standard C preprocessor
`#include` directive.
The regex to applied to all glsl sources is:
`pragma BLENDER_REQUIRE\((\w+\.glsl)\)`
`include "$1"`
This allow C++ linter to parse the code and allow easier codebase
traversal.
However there is a small catch. While it does work like a standard
include directive when the code is treated as C++, it doesn't when
compiled by our shader backends. In this case, we still use our
dependency concatenation approach instead of file injection.
This means that included files will always be prepended when compiled
to GLSL and a file cannot be appended more than once.
This is why all GLSL lib file should have the `#pragma once` directive
and always be included at the start of the file.
These requirements are actually already enforced by our code-style
in practice.
On the implementation, the source needed to be mutated to comment
the `#pragma once` and `#include`. This is needed to avoid GLSL
compiler error out as this is an extension that not all vendor
supports.
Rel #127983
Pull Request: https://projects.blender.org/blender/blender/pulls/128076
When GLSL sources were first included in Blender they were treated as
data (like blend files) and had no license header.
Since then GLSL has been used for more sophisticated features
(EEVEE & real-time compositing)
where it makes sense to include licensing information.
Add SPDX copyright headers to *.glsl files, matching headers used for
C/C++, also include GLSL files in the license checking script.
As leading C-comments are now stripped,
added binary size of comments is no longer a concern.
Ref !111247
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
This contains the basis of the new overlay engine.
Only a few overlays are ported for proof of concept of the new design.
This new design unifies the selection drawing with the overlay-next engine.
It now becomes responsible of selection in object mode.
For this we create a dedicated shader module that patches the shaders
for selection.
Note that the gizmo selection still uses the occlusion queries and edit-mode
the current selection engine (select_engine.c).
Related task #102179
Related task #102177
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/107734
#### Summary
Occlude edit mode selection behind objects in object mode.
#### Problem
When doing retopology, you want to be able to select your edit mesh,
but only when you can see it.
Being able to select geometry behind reference objects is not
desirable.
#### Solution
Make it so reference objects occlude selection, while the edit mesh is
pushed towards the view using retopology offset.
#### Limitations
Poly Build is not supported, because it doesn't use the depth buffer.
It behaves the same as normal, unoccluded by reference meshes.
#### Notes
Selection occlusion is not used when xray is enabled. This is
intentional.
Pull Request: https://projects.blender.org/blender/blender/pulls/105498
Simple port with a few cosmetic changes:
- Attribute named "color" for indices VBO is now called "index"
- The indices VBO is now composed of `int`s instead of `uint`s (this simplifies the source)
Differential Revision: https://developer.blender.org/D14800
This commit moves the API of selecting faces, vertices and edges to a DRW manager engine.
Reviewers: campbellbarton, fclem
Subscribers: jbakker, brecht
Differential Revision: https://developer.blender.org/D5090
