| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This was because the shader had wrong output slot order.
This also add a note about why the order is reversed compared to the
texture binding.
|
|
Viewports where cleared explicitly due to compatibility reasons with Intel iGPUs.
This slowed down other platforms as well, this wasn't noticeable on all platforms.
This patch will be more selective when to enable the workaround.
Currently only for iGPUs on Mac + Linux.
|
|
|
|
Mistake from 1d49293b80446b89b5b12fa0eeefaf14e5051e48.
|
|
This avoid potential shader recompilation and is more in line
with vulkan design.
|
|
|
|
Due to the freeing and re-creation of textures performed when binding
offscreen viewports, VR viewport textures would be needlessly
re-created every drawing iteration, leading to a negative impact on VR
frame rate.
This was brought to light by 6738ecb64e8b, which introduced an
additional texture clear operation on initialization and was
prohibitively costly on some systems when performed every frame.
Now, the textures for VR viewports will not be always re-created
during offscreen binding, but only when necessary using a pre-drawing
step (`wm_xr_session_surface_offscreen_ensure()`).
Reviewed By: jbakker, fclem
Differential Revision: https://developer.blender.org/D14059
|
|
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
|
|
Clearing using GPU_texture_create_2d for unorm texture needs to use
GPU_DATA_FLOAT to match the conversion requirements.
|
|
The VSE and node editor only uses an overlay buffer to draw to the screen. The
GPUViewport assumes that platforms clears all textures during creation, but
they do not on selected platforms. What would lead to drawing from
uncleared memory.
This patch fixes this by clearing all viewport textures during creation.
|
|
Ref T92709
|
|
turned on
This was caused by the drawing not being done on the right frammebuffer.
|
|
This is a necessary step for EEVEE's new arch. This moves more data
to the draw manager. This makes it easier to have the render or draw
engines manage their own data.
This makes more sense and cleans-up what the GPUViewport holds
Also rewrites the Texture pool manager to be in C++.
This also move the DefaultFramebuffer/TextureList and the engine related
data to a new `DRWViewData` struct. This struct manages the per view
(as in stereo view) engine data.
There is a bit of cleanup in the way the draw manager is setup.
We now use a temporary DRWData instead of creating a dummy viewport.
Development: fclem, jbakker
Differential Revision: https://developer.blender.org/D11966
|
|
|
|
This shows the text as part of the assertion message.
|
|
|
|
|
|
During viewport rendering the color values were clamped in order to
apply the overlay on top of it. This clamping would show the scene
colors washed out.
This patch adds a work around to skip the clamping when the overlays are
turned off.
Parial fix for {T77909}
|
|
Fix T83415: 3D View is red when using stereo
The red view was caused by SRGB not being enabled for an SRGB texture attached to the framebuffer.
Currently, when configuring a framebuffer, the first texture attachment needs to be an SRGB format in order for the framebuffer to be binded with SRGB enabled.
Thus, simply changing the SRGB texture attachment as the first texture attachment removes the red color in the view.
Reviewed By: #eevee_viewport, jbakker
Maniphest Tasks: T83415
Differential Revision: https://developer.blender.org/D9845
|
|
This patch allows the user to type a property name into the
Attribute node, which will then output the value of the property
for each individual object, allowing to e.g. customize shaders
by object without duplicating the shader.
In order to make supporting this easier for Eevee, it is necessary
to explicitly choose whether the attribute is varying or uniform
via a dropdown option of the Attribute node. The dropdown also
allows choosing whether instancing should be taken into account.
The Cycles design treats all attributes as one common namespace,
so the Blender interface converts the enum to a name prefix that
can't be entered using keyboard.
In Eevee, the attributes are provided to the shader via a UBO indexed
with resource_id, similar to the existing Object Info data. Unlike it,
however, it is necessary to maintain a separate buffer for every
requested combination of attributes.
This is done using a hash table with the attribute set as the key,
as it is expected that technically different but similar materials
may use the same set of attributes. In addition, in order to minimize
wasted memory, a sparse UBO pool is implemented, so that chunks that
don't contain any data don't have to be allocated.
The back-end Cycles code is already refactored and committed by Brecht.
Differential Revision: https://developer.blender.org/D2057
|
|
Following the most widely used convention for including todo's in
the code, that is: `TODO(name):`, `FIXME(name)` ... etc.
|
|
|
|
This is to modernize the API:
- Add meaningful name to all textures (except DRW textures).
- Remove unused err_out argument: only used for offscreen python.
- Add mipmap count to creation functions for future changes.
- Clarify the data usage in creation functions.
This is a cleanup commit, there is no functional change.
# Conflicts:
# source/blender/gpu/GPU_texture.h
|
|
This follows the GPU module naming of other buffers.
We pass name to distinguish each GPUUniformBuf in debug mode.
Also remove DRW_uniform_buffer interface.
|
|
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/gpu` module.
No functional changes.
|
|
|
|
Groundwork for upcoming fix (D8472)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Caused by framebuffer initialized in the wrong context.
|
|
When drawing the viewport to the screen the draw calls were not batched.
This resulted in measurable slowdown on Windows Intel 10th gen
platforms.
This patch would cache the last draw calls per viewport. Our API does
support partial redrawing of the viewport, but that isn't used anywhere.
This patch does not include stereoscopy rendering. This still uses the
imm approach and would still be slow on certain hardware.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D7357
|
|
The root cause is that viewport can draw cached version of themself but
the scene can have been updated and the pointed curvemapping could have
been freed.
To workaround this we just keep a copy of the curvemap at the viewport
level.
|
|
This reverts commit 862ec829422241878b3345661476d8551935aed2. It causes crashes
on some systems, see T75584.
|
|
When drawing the viewport to the screen the draw calls were not batched.
This resulted in measurable slowdown on Windows Intel 10th gen
platforms.
This patch would cache the last draw calls per viewport. Our API does
support partial redrawing of the viewport, but that isn't used anywhere.
This patch does not include stereoscopy rendering. This still uses the
imm approach and would still be slow on certain hardware.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D7357
|
|
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
|
|
|
|
Stereoscopic viewport didn't support Color Manangement due recent
changes in the color management pipeline. In order to solve the issue we
will migrate the strereo rendering into the GPUViewport. This will share
some textures and reduce required GPU memory.
Reviewed By: fclem, dfelinto
Differential Revision: https://developer.blender.org/D6922
|
|
NOTE: While most of the milestone 1 goals are there, a few smaller features and
improvements are still to be done.
Big picture of this milestone: Initial, OpenXR-based virtual reality support
for users and foundation for advanced use cases.
Maniphest Task: https://developer.blender.org/T71347
The tasks contains more information about this milestone.
To be clear: This is not a feature rich VR implementation, it's focused on the
initial scene inspection use case. We intentionally focused on that, further
features like controller support are part of the next milestone.
- How to use?
Instructions on how to use this are here:
https://wiki.blender.org/wiki/User:Severin/GSoC-2019/How_to_Test
These will be updated and moved to a more official place (likely the manual) soon.
Currently Windows Mixed Reality and Oculus devices are usable. Valve/HTC
headsets don't support the OpenXR standard yet and hence, do not work with this
implementation.
---------------
This is the C-side implementation of the features added for initial VR
support as per milestone 1. A "VR Scene Inspection" Add-on will be
committed separately, to expose the VR functionality in the UI. It also
adds some further features for milestone 1, namely a landmarking system
(stored view locations in the VR space)
Main additions/features:
* Support for rendering viewports to an HMD, with good performance.
* Option to sync the VR view perspective with a fully interactive,
regular 3D View (VR-Mirror).
* Option to disable positional tracking. Keeps the current position (calculated
based on the VR eye center pose) when enabled while a VR session is running.
* Some regular viewport settings for the VR view
* RNA/Python-API to query and set VR session state information.
* WM-XR: Layer tying Ghost-XR to the Blender specific APIs/data
* wmSurface API: drawable, non-window container (manages Ghost-OpenGL and GPU
context)
* DNA/RNA for management of VR session settings
* `--debug-xr` and `--debug-xr-time` commandline options
* Utility batch & config file for using the Oculus runtime on Windows.
* Most VR data is runtime only. The exception is user settings which are saved
to files (`XrSessionSettings`).
* VR support can be disabled through the `WITH_XR_OPENXR` compiler flag.
For architecture and code documentation, see
https://wiki.blender.org/wiki/Source/Interface/XR.
---------------
A few thank you's:
* A huge shoutout to Ray Molenkamp for his help during the project - it would
have not been that successful without him!
* Sebastian Koenig and Simeon Conzendorf for testing and feedback!
* The reviewers, especially Brecht Van Lommel!
* Dalai Felinto for pushing and managing me to get this done ;)
* The OpenXR working group for providing an open standard. I think we're the
first bigger application to adopt OpenXR. Congratulations to them and
ourselves :)
This project started as a Google Summer of Code 2019 project - "Core Support of
Virtual Reality Headsets through OpenXR" (see
https://wiki.blender.org/wiki/User:Severin/GSoC-2019/).
Some further information, including ideas for further improvements can be found
in the final GSoC report:
https://wiki.blender.org/wiki/User:Severin/GSoC-2019/Final_Report
Differential Revisions: D6193, D7098
Reviewed by: Brecht Van Lommel, Jeroen Bakker
|
|
This call to memset relied on PassList having a single,
zero sized struct member.
Pass the passes array instead for readability.
|
|
Reviewed By: brecht sergey jbakker
Differential Revision: http://developer.blender.org/D6729
|
|
This is the unification of all overlays into one overlay engine as described in T65347.
I went over all the code making it more future proof with less hacks and removing old / not relevent parts.
Goals / Acheivements:
- Remove internal shader usage (only drw shaders)
- Remove viewportSize and viewportSizeInv and put them in gloabl ubo
- Fixed some drawing issues: Missing probe option and Missing Alt+B clipping of some shader
- Remove old (legacy) shaders dependancy (not using view UBO).
- Less shader variation (less compilation time at first load and less patching needed for vulkan)
- removed some geom shaders when I could
- Remove static e_data (except shaders storage where it is OK)
- Clear the way to fix some anoying limitations (dithered transparency, background image compositing etc...)
- Wireframe drawing now uses the same batching capabilities as workbench & eevee (indirect drawing).
- Reduced complexity, removed ~3000 Lines of code in draw (also removed a lot of unused shader in GPU).
- Post AA to avoid complexity and cost of MSAA.
Remaining issues:
- ~~Armature edits, overlay toggles, (... others?) are not refreshing viewport after AA is complete~~
- FXAA is not the best for wires, maybe investigate SMAA
- Maybe do something more temporally stable for AA.
- ~~Paint overlays are not working with AA.~~
- ~~infront objects are difficult to select.~~
- ~~the infront wires sometimes goes through they solid counterpart (missing clear maybe?) (toggle overlays on-off when using infront+wireframe overlay in solid shading)~~
Note: I made some decision to change slightly the appearance of some objects to simplify their drawing. Namely the empty arrows end (which is now hollow/wire) and distance points of the cameras/spots being done by lines.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6296
|
|
BIF_gl.h included hacks like redefining glew functions and a constant.
The named constant `GLA_PIXEL_OFS` has been moved to `GPU_viewport.h`
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5860
|
|
Reviewers: brecht
Differential Revision: D4997
|
|
This reverts commit ce34a6b0d727bbde6ae373afa8ec6c42bc8980ce.
|
|
Reviewers: brecht
Differential Revision: D4997
|
