This refactor modernise the use of framebuffers.
It also touches a lot of files so breaking down changes we have:
- GPUTexture: Allow textures to be attached to more than one GPUFrameBuffer.
This allows to create and configure more FBO without the need to attach
and detach texture at drawing time.
- GPUFrameBuffer: The wrapper starts to mimic opengl a bit closer. This
allows to configure the framebuffer inside a context other than the one
that will be rendering the framebuffer. We do the actual configuration
when binding the FBO. We also Keep track of config validity and save
drawbuffers state in the FBO. We remove the different bind/unbind
functions. These make little sense now that we have separate contexts.
- DRWFrameBuffer: We replace DRW_framebuffer functions by GPU_framebuffer
ones to avoid another layer of abstraction. We move the DRW convenience
functions to GPUFramebuffer instead and even add new ones. The MACRO
GPU_framebuffer_ensure_config is pretty much all you need to create and
config a GPUFramebuffer.
- DRWTexture: Due to the removal of DRWFrameBuffer, we needed to create
functions to create textures for thoses framebuffers. Pool textures are
now using default texture parameters for the texture type asked.
- DRWManager: Make sure no framebuffer object is bound when doing cache
filling.
- GPUViewport: Add new color_only_fb and depth_only_fb along with FB API
usage update. This let draw engines render to color/depth only target
and without the need to attach/detach textures.
- WM_window: Assert when a framebuffer is bound when changing context.
This balance the fact we are not track ogl context inside GPUFramebuffer.
- Eevee, Clay, Mode engines: Update to new API. This comes with a lot of
code simplification.
This also come with some cleanups in some engine codes.
This is a bit useless because gpu lamps are only used by the game engine
and it is planned to be "remove" in some way.
Doing this to clean gpu_framebuffer.c.
This was caused by 93936b8643
From GL spec :
GL_INVALID_OPERATION is generated if mask contains GL_DEPTH_BUFFER_BIT or GL_STENCIL_BUFFER_BIT and the source and destination depth and stencil formats do not match.
So blitting framebuffer with depth or stencil require the SAME FORMAT.
This bug (explained here https://github.com/dfelinto/opengl-sandbox/blob/downsample/README.md) is breaking eevee beyond the point it's workable.
This patch workaround the issue by making sure every fbo have mipmaps that are strictly greater than 16px. This break the bloom visuals a bit but only for this setup.
This should fixes the error message that a stall occured because of busy mipmap.
This happened on the minmax buffer generation and introduced a random 0.2ms latency.
I'm not sure of what was happening though.
This special case function enables rendering to a miplevel while using the miplevels above as texture input.
This is needed for some algorithm (i.e. creating a min-max depth pyramid texture).
This combines the Mesa fix (16e929e6ff by @brita_) with the Mac fix (89e23c743e by @merwin).
And uses the same fix for another call to glFramebufferTexture introduced in f1fb605ec9.
glFramebufferTexture() is only available from OGL 3.2, it is also not part of the ARB_framebuffer_object extension.
I don't know if there is a better way to check for mesa drivers or if using the 2D version will have issues with f2f16a256, but so far I had no problems
* Brings us closer to core profile, all matrices are working, and apart
from a problem with text drawing, Blender is working fine.
* Reduce the coding overhead of having to setup/teardown when
alternating between 2D and 3D drawing sessions.
* Gives us fewer modes and states we need to keep track of.
Unfortunatelly this also "rejects a fundamental change" the original
design was trying to make - that 2D is different from 3D and
deserves its own best implementation.
That said, it is still aligned with the function API design as
originally implemented (i.e., it still uses gpuTranslate2D, ...).
Finally, if you build with core profile and this patch you get:
https://developer.blender.org/F545352
[The text glitch is an unrelated issue].
Reviewers: merwin, sergey, brecht
Differential Revision: https://developer.blender.org/D2626
On Apple we use OpenGL 2.1 + an ARB extension for framebuffers.
The glFramebufferTexture function is part of OpenGL 3.0 but not part of the ARB extension. This commit fills that gap.
All other platforms are using GL 3.0+ already so it's not an issue there. All platforms (Mac too) will use GL 3.3+ soon so this workaround will be removed.
Using Texture Arrays to store shadow maps so less texture slots are used when shading. This means a large amount of shadows can be supported.
Support Projection Shadow Map for sun like in old BI/BGE.
Support Cube Shadow Map for Point/Spot/Area lights. the benefit of using it for spot light is that the spot angle does not change shadow resolution (at the cost of more memory used). The implementation of the cubemap sampling is targeted for 3.3 core. We rely on 2D texture arrays to store cubemaps faces and sample the right one manualy. Significant performance improvement can be done using Cubemap Arrays on supported hardware.
Shadows are only hardware filtered. Prefiltered shadows and settings comming next.
See intern/gawain for the API change. Other files are updated to use the new name. Also updated every call site to the recommended style:
unsigned int foo = VertexFormat_add_attrib(format, "foo", COMP_ ... )
Reference document: http://docs.gl/gl3/glPushAttrib
This patch only tackles the bits that are set by Blender with the
following exceptions:
1) Deprecated states (e.g., GL_STIPPLE) are not saved/restored
2) The exception being GL_ALPHA_TEST, which will be removed, but it may
affect drawing too much now. To be removed once we no longer set GL_ALPHA_TEST
elsewhere.
3) paint_cursor will be tackled separated, since it was abusing
glPush/PopAttrib in the first place.
4) Despite what the glPushAttrib page above may suggest, GL_DEPTH_WRITEMASK needs glGet, not glIsEnabled
5) BGE is still a problem since it relies on GL_ALL_ATTRIB_BITS which
would lead to a way more complete/lenghty solution. Since the BGE has
other (OpenGL deprecated) problems anyways, it can be handled on its own
time.
Finally, the original design for 2.8 was to implement a proper stack
system. However we need to move to core profile sooner than later. So
this is a pragmatic temporary (that may be permanent) solution.
Reviewers: merwin, campbellbarton
Differential Revision: https://developer.blender.org/D2600
