This adds UDIM support to e.g. the Displacement modifier.
The implementation is straightforward: If the image is tiled, lookup the
tile based on UVs and shift the UVs into the tile's coordinates.
This patch contains the work that I did during my week at the Code Quest - adding support for tiled images to Blender.
With this patch, images now contain a list of tiles. By default, this just contains one tile, but if the source type is set to Tiled, the user can add additional tiles. When acquiring an ImBuf, the tile to be loaded is specified in the ImageUser.
Therefore, code that is not yet aware of tiles will just access the default tile as usual.
The filenames of the additional tiles are derived from the original filename according to the UDIM naming scheme - the filename contains an index that is calculated as (1001 + 10*<y coordinate of the tile> + <x coordinate of the tile>), where the x coordinate never goes above 9.
Internally, the various tiles are stored in a cache just like sequences. When acquired for the first time, the code will try to load the corresponding file from disk. Alternatively, a new operator can be used to initialize the tile similar to the New Image operator.
The following features are supported so far:
- Automatic detection and loading of all tiles when opening the first tile (1001)
- Saving all tiles
- Adding and removing tiles
- Filling tiles with generated images
- Drawing all tiles in the Image Editor
- Viewing a tiled grid even if no image is selected
- Rendering tiled images in Eevee
- Rendering tiled images in Cycles (in SVM mode)
- Automatically skipping loading of unused tiles in Cycles
- 2D texture painting (also across tiles)
- 3D texture painting (also across tiles, only limitation: individual faces can not cross tile borders)
- Assigning custom labels to individual tiles (drawn in the Image Editor instead of the ID)
- Different resolutions between tiles
There still are some missing features that will be added later (see T72390):
- Workbench engine support
- Packing/Unpacking support
- Baking support
- Cycles OSL support
- many other Blender features that rely on images
Thanks to Brecht for the review and to all who tested the intermediate versions!
Differential Revision: https://developer.blender.org/D3509
Usage of spinlock during heavy IO gave reduced performance
see D6267 for details.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D6267
This also replaces the Use Alpha setting. We now have these alpha modes:
* Straight: store RGB and alpha channels separately with alpha acting as a
mask, also known as unassociated alpha.
* Premultiplied: transparent RGB pixels are multiplied by the alpha channel.
The natural format for renders.
* Channel Packed: different images are packed in the RGB and alpha channels,
and they should not influence each other. Channel packing is commonly used
by game engines to save memory.
* None: ignore alpha channel from the file and make image fully opaque.
Cycles OSL does not correctly support Channel Packed and None yet, we are
missing fine control over the OpenImageIO texture cache to do that.
Fixes T53672
The basic idea is that such new images will be packed into the .blend file
when saving all modified images from the quit dialog. To make this workflow
nicer a number of changes were made to how this type of packed image is
handled.
* "Save Modified Images" now packs generated images into the .blend file.
* "Save As" for packed images now automatically unpacks the image, so that
it's easy to save automatically packed images. "Save Copy" keeps it packed.
* "Save" for packed images now re-saves the image into the .blend file, so
that it's effectively the equivalent of "Save" for non-packed images.
* Empty image filepaths are no longer remapped when saving the .blend file.
Previously it would become e.g. "//../../" which makes no sense for generated
images with no filepath yet.
* Hide unpack button and filepath for such packed images with no filepath.
Unpacking does not work in a predictable way without a filepath, better
to just "Save As".
This way float and multilayer images can now be packed without data loss. This
removes the as_png option and always uses the appropriate file format depending
on the image contents.
The `--render-format` CLI option takes `EXR` and `MULTILAYER`, whereas
the DNA image format render setting uses `OPEN_EXR` and
`OPEN_EXR_MULTILAYER`. This commit adds the DNA values to the CLI
argument, so that it is possible to take the selected value from DNA and
pass it as-is to the CLI. This is used in Flamenco, for example.
The `OPEN_EXR` and `OPEN_EXR_MULTILAYER` are now aliases, so both the
existing and the new options keep working.
Reviewers: campbellbarton, brecht
Reviewed By: brecht
Subscribers: fsiddi
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D4502
Use the term "AFTER" instead of "OFS" since it wasn't obvious these
macros operate on everything after the struct member passed.
Avoid casting to non-const types when only reading.
Convention was not to but after discussion on 918941483f we agree its
best to change the convention.
Names now mostly follow RNA.
Some exceptions:
- Use 'nodetrees' instead of 'nodegroups'
since the struct is called NodeTree.
- Use 'gpencils' instead of 'grease_pencil'
since 'gpencil' is a common abbreviation in the C code.
Other exceptions:
- Leave 'wm' as it's a list of one.
- Leave 'ipo' as is for versioning.
Previously metadata was only shown for images which are saved
to disk.
This change makes it so that it's possible to see metadata right
after pressing F12.
The dependency graph now handles updating image users to point to the current
frame, and tags images to be refreshed on the GPU. The image editor user is
still updated outside of the dependency graph.
We still do not support multiple image users using a different current frame
in the same image, same as 2.7. This may require adding a GPU image texture
cache to keep memory usage under control. Things like rendering an animation
while the viewport stays fixed at the current frame works though.
Is available when doing "View -> Show Metadata". Will draw all the
fields which are not part of the stamp at the bottom of the image.
Couple of hand-picked fields are ignored, since those are not very
useful to be seen.
Aimed to ease review of rendered shots.
Reviewers: brecht
Reviewed By: brecht
Subscribers: fsiddi
Differential Revision: https://developer.blender.org/D4316
This is a request by the studio here to make it possible to see how
many samples were used to render a specific shot or a frame. It is a
bit more tricky than simply stamping number of samples from a scene
since rendering is happening in multiple ranges of samples.
This change makes it so Cycles saves configured number of samples for
the specific view layer, and also stores start sample and number of
samples when rendering only a subrange of all samples.
The format used is "cycles.<view_layer_name>.><field>", which allows
to have information about all layers in a multi-layer EXR file.
Ideally we can store simplified "cycles.<field>" if we know that there
is only one render layer in the file, but detecting this is somewhat
tricky since Cycles operates on an evaluated scene which always have
single view layer.
The metadata is shown in the Metadata panels for clip, image and
sequencer spaces.
Example screenshot which shows the metadata:
{F6527727}
Reviewers: brecht
Reviewed By: brecht
Subscribers: fsiddi
Differential Revision: https://developer.blender.org/D4311
Quite straightforward: first, convert metadata from file to
stamp data which is stored in the render result, and then
for every requested layer/pass use that as a metadata.
