Cycles now uses the color space on the image datablock, and uses OpenColorIO
to convert to scene linear as needed. Byte images do not take extra memory,
they are compressed in scene linear + sRGB transfer function which in common
cases is a no-op.
Eevee and workbench were changed to work similar. Float images are stored as
scene linear. Byte images are compressed as scene linear + sRGB and stored in
a GL_SRGB8_ALPHA8 texture. From the GLSL shader side this means they are read
as scene linear, simplifying the code and taking advantage of hardware support.
Further, OpenGL image textures are now all stored with premultiplied alpha.
Eevee texture sampling looks a little different now because interpolation
happens premultiplied and in scene linear space.
Overlays and grease pencil work in sRGB space so those now have an extra
conversion to sRGB after reading from image textures. This is not particularly
elegant but as long as engines use different conventions, one or the other
needs to do conversion.
This change breaks compatibility for cases where multiple image texture nodes
were using the same image with different color space node settings. However it
gives more predictable behavior for baking and texture painting if save, load
and image editing operations have a single color space to handle.
Differential Revision: https://developer.blender.org/D4807
Workbench/Eevee now displays multiple multi-materials correctly.
Iterate over pbvh nodes when doing object iteration. This makes the
rendering process more streamlined and allow for using different materials.
This change will make possible to:
- Add culling pass of each pbvh leaf node. (speedup if zoomed on a small
area)
- Reduce number of lead node iteration.
- Reduce code complexity
If image buffer is not loaded and blender attempts to reload it (during
`BKE_image_acquire_ibuf`) over and over for each frame rendered.
When attempting this reload, image_load_image_file is calling
`BKE_image_free_buffers` and tag the Image to the (GPU) image_free_queue
(because this run on the rendering thread).
If the main thread decide to redraw the UI and go through `GPU_free_unused_buffers` they all get deleted and if that happens before the rendering thread use them ... segfault.
If I replace the environment textures with correct ones (the file does not seems to contain them), there is no crash when rendering.
I used a list of GPUTexture from blender Image to increase and decrease the
reference counter correctly.
This add very little memory and computation overhead.
Currently it is not possible to view the vertex colors of an object. To
optimize the workflow, workbench will need to support Vertex Colors.
The Vertex Colors is a new option in `shading->color_type`. When objects
do not have vertex color, the objects will be rendered with the
`V3D_SHADING_OBJECT_COLOR`.
In order to support vertex colors in workbench the current texture/solid
shading structure is migrated to a primary shaders and fallback shaders.
Fix: T57000
Reviewers: brecht, fclem
Differential Revision: https://developer.blender.org/D4694
The wrong transformation was used. Add a new matrix specially for this case.
This also fix the Node texture coordinate that was suffering the same issue.
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.
This introduce the wireframe batches. Creating the indices buffer does
not seems to slow down the sculpt in my testing (but it is kind of hard to
test reliably)
This includes a bit of cleanup in gpu_buffers.c.
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
The shader is way simpler and run way faster on lower end hardware
(2x faster on intel HD5000) but did not notice any improvement on AMD Vega.
This also adds a few changes to the way the wireframes are drawn:
- the slider is more linearly progressive.
- optimize display shows all wires and progressively decrease "inner" wires
intensity. This is subject to change in the future.
- text/surface/metaballs support is pretty rough. More work needs to be done.
This remove the optimization introduced in f1975a4639.
This also removes the GPU side "sharpness" calculation which means that
animated meshes with wireframe display will update slower.
The CPU sharpness calculation has still room for optimization. Also
it is not excluded that GPU calculation can be added back as a
separate preprocessing pass (saving the computation result [compute or
feedback]).
The goal here was to have more speed for static objects and remove
the dependency of having buffer textures with triangle count. This is
preparation work for multithreading the whole DRW manager.
This makes is easy to create nested drawcalls that will inherit all the
parents properties. This is usefull if only a few uniforms changes for that
drawcall.
Flat shaded grids are now rendered as a long triangle strip with
degenerate triangles.
Smooth shaded grids are not changed.
Also add back fast navigate. The only difference with 2.79 is that fast
navigate + flat shading will show slitly "incorrect" smooth face. But that's too
much effort to fix for what it is.
* Remove support for diffuse color in the pbvh buffers.
* Upload raw data to GPU.
* Only draw nodes that have mask data when drawing the overlay.
This should fix T56466
A lot of code in codegen was used by previous GLSL system.
Now most of it is not used due to all the things being written from scratch
in 2.8 and we can clean most of it.
As a side not this make the system a bit less flexible (no support for
cubemaps, preview image, etc...) but can be extended again.
