| Age | Commit message (Collapse) | Author |
|---|
|
This new shader is able to emulate smooth wide lines drawing using a
geometry shader.
This shader needs viewportSize and lineWidth uniforms to be set.
There is multiple variants to replace the usage of wide lines for most
shaders.
This patch only fix the gizmo_types files and the navigation gizmo.
Other areas could be fixed afterward, I just limited the patch size.
Fix T57570.
Reviewed By: billreynish
Differential Revision: https://developer.blender.org/D7487
|
|
This allow to copy entire texture in a faster way than using framebuffer
blitting.
This uses ARB_copy_image extension if available and fallback to
glCopyTexSubImage2D for older gl version.
Both method should be as fast if not faster than the framebuffer blitting.
|
|
Should be no functional changes.
|
|
Actually the assert was incorrect. It tested for an active buffer, but
an batch would also be ok.
|
|
|
|
These values were hardcoded before Face Sets were enabled for Multires,
so enable the show_face_sets checks now.
Reviewed By: jbakker
Maniphest Tasks: T75329
Differential Revision: https://developer.blender.org/D7444
|
|
|
|
|
|
Caused by framebuffer initialized in the wrong context.
|
|
We used to have a single buffer that was shared between strict and
unstrict draw calls. This leads to many recreation events for the draw
buffers. This patch separates the Unstrict draw buffer from the strict
draw buffer.
This improves performance on Windows Intel 10th gen platform.
On a reference platfor before the patch I got 10 FPS, after this patch
it became 34fps. Note that the same test normally on a low end GPU can
get to 60fps so this does not solve all teh bottlenecks yet.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D7421
|
|
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.
|
|
Issue in 21c658b718b9b with function being defined twice.
|
|
This solution involves adding a uniform to each fragment shader that is
used by gizmo drawing and use the framebuffer state to set this uniform
accordingly.
This solution can also be carried to external shaders (addons).
A single line of code would then be enough to fix the issue.
The only trickery here is the dummy define:
`#define srgb_to_framebuffer_space(a)`
This is in order to avoid breaking other DRW shaders that use the same
fragment shader code but do not need the tranformation.
Related to T74139
Reviewed By: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D7261
|
|
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
|
|
|
|
This reverts commit 58e20b432a2bd7fbff7ebb7aa1f49a6662dc6e7c.
Was calling discard twice, tsk.
Although for some reason it did quiet the leak.
Reverting because this is causing a crash.
|
|
Memory leak from 60d873bd22121.
|
|
The GPU Batch for the panel drag widget wasn't freed anywhere. This
patch will free the GPUBatch.
|
|
The 10g Intel/Win driver doesn't work well with our emulated
intermediate mode. This patch alters the drawing of the drag widget of
the panels to reduce unneeded drawing.
The previous method would draw 16 boxes per widget. This new way would
cache this drawing in a GPU batch and just move the matrix around.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D7345
|
|
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
|
|
This was already the case in most parts of the GPU API.
Use full name for descriptive-comments.
|
|
|
|
This implements the Sculpt Mode API functions needed for Face Sets and
visibility management for PBVH_GRIDS. No major changes were needed in
the operators and the sculpt mode code. This implementation stores the
face sets in the base mesh, so faces created in higher subdivision
levels can't be modified individually. Also, we are not checking for
multiple face sets per vertex (that can be added in the future), so
relax tools don't work yet. The rest of the features (paint, undo,
visibility operators..) work as expected.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7168
|
|
|
|
On some drivers, the default values is not respected correctly.
To workaround this we create a small VBO that contains only 1 vec4 worth of
data and just bind it using glBindVertexBuffer to ensure 0 stride.
This fixes T75069 Instances not rendered correctly by workbench.
|
|
Using a float to store and render the mask seems like a waste of memory
without any noticeable difference in the viewport for its use case.
After this commit, the mask and the face sets combined should take the
same amount of GPU memory than only the mask in previous versions.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7148
|
|
SCULPT_FACE_SET_NONE default value is 0 and it is rendered hidden, so
the invert sign operation to show it was not working. Now the show all
function sets this face set to ID 1 before setting its sign.
I also refactored this check in gpu_buffers.
Not related to the reported issue, but the mesh in attached contains non
manifold geometry with hidden loose vertices, so the visibility state
was not syncing correctly to those vertices. Now the toggle operators
checks the current visibility only on the face sets, so no manifold
vertices are ignored (as they are in the rest of operations in sculpt
mode).
Reviewed By: jbakker
Maniphest Tasks: T74780
Differential Revision: https://developer.blender.org/D7188
|
|
The default face set color is white, so we can skip drawing the default
face set. This allows to enable again the optimization of not drawing
overlays in nodes where the mask is empty.
This will still slow down the viewport when a new face set is created
for the whole mesh or when inverting the mask, like in previous
versions.
I also renamed the function to make more clear that now it is checking
for both mask and face sets.
Reviewed By: brecht
Maniphest Tasks: T74692
Differential Revision: https://developer.blender.org/D7207
|
|
```
...\gpu_texture.c(466,7): warning C4555: result of expression not used
...\gpu_texture.c(559,7): warning C4555: result of expression not used
...\gpu_texture.c:1205:72: warning: pointer targets in passing argument 4 of ‘glGetTexLevelParameteriv’ differ in signedness [-Wpointer-sign]
```
|
|
This commit adds a `mipmaps` member to the `GPUTexture` struct and also
computes to the memory used by these mipmaps and the memory used for
textures that are created from an external bindcode.
So it solves the following inconsistencies:
- The memory value for mipmaps was not being computed.
- As `GPU_texture_from_bindcode` didn't call
`gpu_texture_memory_footprint_add`, it brought inconsistencies to the
value of the used memory, especially when the texture is freed.
Differential Revision: https://developer.blender.org/D3554
|
|
This patch adds ability to set up colors and size of background
(transparency) checkerboard pattern in viewport and 2d editors. No new
backgrounds, only changing colors in existing ones.
This is not the background of the viewport, it is a transparency
checkerboard that is turned on only in render mode, when the
transparency mode is on. And also in 2D-editors, (image, sequencer,
etc).
Reviewed By: Pablo Vazquez, Julian Eisel
Differential Revision: https://developer.blender.org/D6791
|
|
On some platforms the stereo viewport rendering was not working. The
issue was that the fragment shader and vertex shaded didn't match. Some
platforms will remove the non-matching in/out parameters and blender
needs to provide only the optimal set of parameters. Other platform
still want to receive data for the parameters that aren't used.
This fix uses the correct vertex shader that matches the fragment shader
making both platforms render the same result.
|
|
Use first texture if we dont have an ImageUser.
Maniphest Tasks: T74925
Differential Revision: https://developer.blender.org/D7181
|
|
|
|
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
|
|
Only the volume drawing part is really finished and exposed to the user. Hair
plugs into the existing hair rendering code and is fairly straightforward. The
pointcloud drawing is a hack using overlays rather than Eevee and workbench.
The most tricky part for volume rendering is the case where each volume grid
has a different transform, which requires an additional matrix in the shader
and non-trivial logic in Eevee volume drawing. In the common case were all the
transforms match we don't use the additional per-grid matrix in the shader.
Ref T73201, T68981
Differential Revision: https://developer.blender.org/D6955
|
|
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
|
|
The face set color variable needs to be declared inside of the loop in
order to reset it per iteration.
Reviewed By: jbakker
Maniphest Tasks: T74626
Differential Revision: https://developer.blender.org/D7096
|
|
This call to memset relied on PassList having a single,
zero sized struct member.
Pass the passes array instead for readability.
|
|
Part of the fix was to get gputexture to use an array to accomodate each
eye. This takes care of viewports showing individual Left or Right
views.
For the combined view the fix was in overlay_image.c:camera_background_images_stereo_setup.
Note 1: Referece images are still not supporting stereo.
Note 2: For painting, and getting image bindcode I'm hardcording a
single-view experience.
Note 3: Without D6922 stereo is too broken to even test this patch.
With D6922 + this patch the fullscreen modes work (anaglyph/interlace
not yet).
Differential Revision: D7143
|
|
The face set ID is sequential, so implementing this was straightforward.
Suggested by Jeroen Bakker
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7123
|
|
We implement cubemap array support for EEVEE's lightcache reflection probes.
This removes stretched texels and bottom hemisphere seams artifacts caused
by the octahedral projection previously used.
This introduce versioning code for the lightcache which will discard any
lightcache version that is not compatible.
Differential Revision: https://developer.blender.org/D7066
|
|
This has no user visible impact yet since smoke volumes only support a fixed
set of attributes, but will become important with the new volume object.
For GPU shader compilation, volume grids are now handled separately from
image textures. They are somewhere between a vertex attribute and an image
texture, basically an attribute that is stored as a texture.
Differential Revision: https://developer.blender.org/D6952
|
|
|
|
This is more in line with standard grids and means we don't have to make
many special exceptions in the upcoming change for arbitrary number of volume
grids support in Eevee.
The workbench shader was also changed to fix bugs where squared density was
used, and the smoke color would affect the density so that black smoke would
be invisible. This can change the look of smoke in workbench significantly.
When using the color grid when smoke has a constant color, the color grid
will no longer be premultiplied by the density. If the color is constant
we want to be able not to store a grid at all. This breaks one test for
Cycles and Eevee, but the setup in that test using a color without density
does not make sense. It suffers from artifacts since the unpremultiplied
color grid by itself will not have smooth boundaries.
Differential Revision: https://developer.blender.org/D6951
|
|
- Move gpuPush/Pop from GPU_draw.h into GPU_state.h
as this is for pushing/popping state.
- Add 'GPU_STANDALONE' define, to bypass use of user-preferences
for theme colors and pixelsize, as well as pbvh init/free functions.
Needed to get GHOST tests working again.
|
|
This introduces a variable to store a face set ID which is going to be
rendered white. When initializing a mesh or randomizing the colors, this
variable gets updated to always render a white face set. This way the
face set overlay can be enabled without adding colors to the mesh if
face sets are not in use. After creating the first face set, new colors
are generated randomly like usual.
The face set stored as default does not have any special meaning for
tools or brushes, it just affects the rendering color.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7035
|
|
This way we can change the color generation easily if we want to improve
it in the future. I also added more values to randomize a little bit the
saturation and value of the colors, as previously it was too easy to get
similar colors when creating new faces, forcing you to use the randomize
colors more than necessary.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7042
|
