This is essentially adding that new callback, and using it only for already
existing Scene's 3DCursor.
Note that the place where this is called has been moved again, after all
have been lib-linked, such that those callbacks may also work on ID pointers.
Maniphest Tasks: T71759
Differential Revision: https://developer.blender.org/D9237
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
Those were only shallow wrappers around `BKE_id_copy`, barely used (even
fully unused in some cases), and we want to get rid of those ID-specific
helpers for the common ID management tasks. Also prevents weird custom
behaviors (like `BKE_object_copy`, who was the only basic ID copy
function to reset user count of the new copy to zero).
Part of 71219.
This is part of T76372.
It adds the `blend_write`, `blend_read_data`, `blend_read_lib`
and `blend_read_expand` which correspond to the various
steps when reading and writing .blend files.
Having these callbacks allows us to decentralize the blenloader
code a lot more. This has the affect that code related to any
specific ID type is less scattered.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D8670
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
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`.
A simulation data block has an embedded node tree, which requires
special handling in a couple of places. Some of those places were
missing beforehand.
This also adds a relation to make sure that the simulation is evaluated
after animations on the embedded node tree are evaluated.
For still images, always return 0 for the current frame number. This ensures
Cycles can detects that the image did not change.
Based on patch by Vincent Blankfield.
Differential Revision: https://developer.blender.org/D8242
Caused by recent own refactor of cache presevation handling in readfile,
EEVEE's lightcache are weird birds that can also be saved in .blend
files, need a special handling for those 'persistent' caches...
Some notes:
* `Image.cache` acts as some kind of 'main' cache, when it is NULL
(could not be restored), other caches should also be cleared. Oddly
enough, previous code was not clearing **all** caches, could not find
any reason for that behavior, so new code does a full clear.
* `imamap` is still used for Node previews from scenes' compositor,
however this is actually fully disabled in `direct_link_node()`.
* For render slots we cannot use offsetof as third part of the cache
key, so we are using a hash of the slot's name instead.
As far as I can tell, this fixes T76989: Visual glitches when undo after
reload multiple images by script (in Material Preview).
This is legacy code from before Eevee and Workbench rendering in background
mode was supported. Avoid memory leak by only queueing GPU textures to be
freed when we know they have been allocated.
Differential Revision: https://developer.blender.org/D8172
Issue was with setting of frame to load from an image sequence,
synchronization was not done properly at some point, leading to
generation of an invalid final filepath to be read.
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
Follow up of b2ee1770d4 and 10c2254d41, part of T74432.
Now the area and region naming conventions should be less confusing.
Mostly a careful batch rename but had to do few smaller fixes.
Also ran clang-format on affected files.
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
Instead of using anonymous booleans flags, also allows to keep the same
behavior in all cases, without needing special handling from calling
code for our beloved oddballs object proxies...
If the current frame was not in range, the ImageTile's 'ok' was stuck at
0. Similar to the ImageUser being reset to 'ok' in
BKE_image_user_frame_calc, we now do for ImageTiles as well.
note: the crasher part of T74225 was fixed in rB5c490d437743.
Maniphest Tasks: T74225
Differential Revision: https://developer.blender.org/D6939
This would happen if a tile is found on disk, painting would actually
request that tile (because corresponding uvs were in that range), but
that tile was not added in blenders list of tiles in that Image.
Need to also check tile in `image_quick_test` (regardless of iuser
having passed).
thx @lukasstockner97 for additional input!
Maniphest Tasks: T73110
Differential Revision: https://developer.blender.org/D6578
Based on @fclem's suggestion in D6421, this commit implements support for
storing all tiles of a UDIM texture in a single 2D array texture on the GPU.
Previously, Eevee was binding one OpenGL texture per tile, quickly running
into hardware limits with nontrivial UDIM texture sets.
Workbench meanwhile had no UDIM support at all, as reusing the per-tile
approach would require splitting the mesh by tile as well as texture.
With this commit, both Workbench as well as Eevee now support huge numbers
of tiles, with the eventual limits being GPU memory and ultimately
GL_MAX_ARRAY_TEXTURE_LAYERS, which tends to be in the 1000s on modern GPUs.
Initially my plan was to have one array texture per unique size, but managing
the different textures and keeping everything consistent ended up being way
too complex.
Therefore, we now use a simpler version that allocates a texture that
is large enough to fit the largest tile and then packs all tiles into as many
layers as necessary.
As a result, each UDIM texture only binds two textures (one for the actual
images, one for metadata) regardless of how many tiles are used.
Note that this rolls back per-tile GPUTextures, meaning that we again have
per-Image GPUTextures like we did before the original UDIM commit,
but now with four instead of two types.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6456
