| Age | Commit message (Collapse) | Author |
|---|
|
To prepare for future changes {T92613}.
|
|
Previously, `ImageTile->ok` and `ImageUser->ok` were used to indicate
whether an image failed to load. There were three possible values
which (probably) had the following meanings:
* `0`: There was an error while loading the image. Don't try to load again.
* `1`: Default value. Try to load the image.
* `2`: The image was loaded successfully.
This image-wide flag did not make sense unfortunately, because loading
may work for some frames of an image sequence but not for others.
Remember than an image data block can also contain a movie.
The purpose of the `->ok` flag was to serve as an optimization to avoid
trying to load a file over and over again when there is an error (e.g. the
file does not exist or is invalid). To get the optimization back, the patch
is changing `MovieCache` so that it can also cache failed load attempts.
As a consequence, `ibuf` is allowed to be `NULL` in a few more places.
I added the appropriate null checks.
This also solves issues when image sequences are used with the
Image Texture node in Geometry nodes (also see D12827).
Differential Revision: https://developer.blender.org/D12957
|
|
Improve texture painting/uv editing performance when limited scale is active.
Cause of the slow down is that the image editor draws the image in maximum resolution,
but the 3d viewport uses the limited scale. The variation reuses the same GPU texture
and needed to be uploaded/scaled twice to the GPU.
This patch will adds texture slots that can hold the scaled down and the maximum
resolution image. This would allow better cache hits and reuse of existing caches.
Maximum resolution textures are reused for limited scale when they fit to reduce memory
and CPU footprint.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D12388
|
|
Removes the artificial requirement that UDIM tile sets start at 1001.
Blender was already capable of handling sparse tile sets (non-contiguous
tiles) so the restriction around starting at 1001 was unnecessary in
general.
This required fixing a few UDIM-related python bugs around manually
updating the `tile_number` field on images as well. See the differential
for details. No script changes are necessary but they will now work,
correctly, in many more cases.
Differential Revision: https://developer.blender.org/D11859
|
|
|
|
|
|
This patch will show textures in the image editor with the maximum
available resolution determined by the GPU Hardware/Driver.
Currently the size is limited by the user preference texture size limit.
An image user can set the `IMA_SHOW_MAX_RESOLUTION` flag to request
gpu textures in the max supported resolution. When this flag isn't
set the gpu texture is limited by the user preference setting.
When the gl resolution limit is disabled the GPU texture is always
created for the max supported resolution.
Reviewed By: Clément Foucault
Maniphest Tasks: T81206
Differential Revision: https://developer.blender.org/D9160
|
|
The `image_get_gpu_texture` didn't use the iuser->view_index but
recalculated the requested view again. This lead to inconsistent
behavior when switching between multi view textures or stereo textures.
This has been fixed by ensuring that the `iuser->view_index` is always
used.
An Image has only place to store 2 view textures. This is done for
right/left eye compositing. A multi view texture can have more views.
This would lead to reading and writing to unallocated space.
When a multiview texture is requested that is larger than 1. It will
always be cached as being the first eye. The `gpu_view` of the Image is
also used as a cache key to check this.
|
|
This patch introduces a partial update of GPUTexture. When rendering
a large image the GPUTexture could have been scaled. The old implementation
would rescale the image on CPU and create a new GPUTexture. This
resulted in flooding the PCI bus.
The new solution would only scale and upload the parts of the GPUTexture
that has been changed. It does this by keeping track of areas of 256x256
pixels. When something changes the tiles that cover that changes will be
rescaled and uploaded the next time the GPUTexture is requested.
Test situation: Default Cube, 4 samples, 19200x10800 tile size 512.
Blender 2.83.9: 4m27s.
Blender 2.91: 20+m (regression)
This patch: 1m01s.
There is still room for more optimizations:
* Reduce the time that an image is locked.
** Use task scheduling to update the tiles of an image.
** Generic optimization of the ImBuf scale method.
Maniphest Tasks: T82591
Differential Revision: https://developer.blender.org/D9591
|
|
Issue was that not all code paths were taken to determine if
the GPU Texture was premultiplied or not. In this case the result
was set to unpremultiplied what is incorrect.
This fixes broken test case image alpha blend from image_colorspace.
|
|
|
|
Regression introduced by {b17cca6966}. When centralizing the gpu texture
premultiplication setting it was assumed that generated images
(`IMA_TYPE_UV_TEST`) were stored as premultiplied. That assumption was
totally wrong as the alpha association is determined by the existing of
the float/byte buffer.
NOTE: This change will render generated images with pure emissive
colors (show colors when alpha=0.0) what might add more reports. Any
reports could be merged in the next report {T82790}.
Reviewed By: Clément Foucault, Philipp Oeser
Differential Revision: https://developer.blender.org/D9585
|
|
With the new image editor drawing there were was some mutual exclusive
functionality. When rendering the alpha was shown correctly or the pure
emissive colors were shown correctly, but never both. The cause of this
is that the image_gpu did not used the correct alpha mode when generating
gpu textures for non-images (render results, compositors viewer)
The implementation always checked the alpha_mode. Alpha mode is an
attribute for images, but aren't set for non images. This patch adds
a more detailed check to ensure that the gpu texture is premultiplied.
The issue has been tested using several bug report files and production
files.
Reviewed By: Brecht van Lommel
Differential Revision: https://developer.blender.org/D8978
|
|
Introduced by D8234. Added active render slot to determine if the GPUTexture is still up to date.
|
|
Regression introduced by {D8234}; GPU textures can be requested without
an image user.
|
|
This project moves the current UV/Image editor drawing to the draw manager.
Why would we do this:
**Performance**:
Current implementation would draw each texel per time. Multiple texels could be
drawn per pixel what would overwrite the previous result. You can notice this
when working with large textures. Repeat image drawing made this visible by
drawing for a small period of time and stop drawing the rest. Now the rendering
is fast and all repeated images are drawn.
**Alpha drawing**:
Current implementation would draw directly in display space. Giving incorrect
results when displaying alpha transparent images.
This addresses {T52680}, {T74709}, {T79518}
The image editor now can show emission only colors. See {D8234} for
examples.
**Current Limitations**
Using images that are larger than supported by your GPU are resized (eg larger
than 16000x16000 are resized to 8k). This leaves some blurring artifacts. It is
a low priority to add support back of displaying individual pixels of huge
images. There is a design task {T80113} with more detail.
**Implementation overview**
Introduced an Image Engine in the draw module. this engine is responsible for
drawing the texture in the main area of the UV/Image editor. The overlay engine
has a edit_uv overlay which is responsible to draw the UV's, shadows and
overlays specifically for the UV Image editor. The background + checker pattern
is drawn by the overlay_background.
The patch will allow us to share overlays between the 3d viewport and UV/Image
editor more easily. In most cases we just need to switch the `pos` with the `u`
attribute in the vertex shader.
The project can be activated in the user preferences as experimental features.
In a later commit this will be reversed.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D8234
|
|
This was caused by rBe749643793809248dfc6ffd078be04aec3eeab82 which
removed the texture repeat from Image texture.
|
|
This makes more sense as this module has more to it than just
GL extensions.
|
|
# Conflicts:
# source/blender/gpu/intern/gpu_framebuffer.cc
|
|
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 is going to be unecessary after the GPU opengl texture backend refactor.
For now add a save/restore mechanism to leave the state untouched.
Also remove some calls where the caller would bind to particular binding
point and set the shader uniform.
|
|
Also order sizeof(..) first to promote other values to size_t.
|
|
As far as I can see, this problem was introduced with the gpu_free_unused_buffers() changes in rB97b597c.
The code checks the returned pointer to stop looping, but the last iteration will return the last GPUTexture and set the queue to NULL, meaning that the next pop() will crash.
Differential Revision: https://developer.blender.org/D8468
|
|
This was causing compiler error on MSVC and is not a good idea
in general.
|
|
|
|
|
|
This is in order to disolve GPU_draw.h into more meaningful code blocks.
All the Image related function are in `image_gpu.c`.
All the MovieClip related function are in `movieclip.c`.
The IMB module now has a connection with GPU. This is not strickly
necessary and the code could be move to `image_gpu.c` if needed.
The Image garbage collection is also ported to `image_gpu.c`.
|
