Generic ID management code can now do those local temp copy handling, so
no need for duplicated own code for that.
No behavioral changes expected here.
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
Remove redundantly nested `#if` and `#ifdef` statements.
One nested `#if 0` block was left untouched, as it's in particle code
that's no longer maintained. Furthermore, that block also has some
explanation as to the differences between the enabled & disabled parts.
One nested `#if 0` construct was completely removed, leaving only the
actually used bit of code. There was no explanation as to the usefulness
of the disabled code, and it hasn't been touched in years.
No functional changes.
Is not only the values of translation/scale/rotation which are to be inverted,
but also the order of operations.
Differential Revision: https://developer.blender.org/D8518
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
The final render will use scene resolution in this case.
For example, when Color Input is plugger to preview and composite output
nodes, final render will flood-fill the final image which is a size of
scene resolution with this color. Before this fix the node preview was
empty. After this fix the node preview will be flood-filled with the
color.
Fixes T78586
Differential Revision: https://developer.blender.org/D8263
Were two issues:
- Divider was calculated in integer domain, causing rounding issues in
general case, and causing singularity in a corner case when input is
smaller than the preview size.
- The resolution was scaled down by 1 pixel for no obvious reason.
The issue was caused by wrong conversion happening after some of the
proxies are removed. Easiest solution is to first remove proxies and
then add required converter operations.
Thanks Jeroen for the review!
Happens when some of the color correction terms are mathematically
undefined: foe example, when pow() is to be calculated and the X
argument is negative.
There is no ground-truth result in such cases, so ignore such terms
entirely.
This is a generalization of D6696 from Jacques.
Differential Revision: https://developer.blender.org/D7966
Surrounding includes with an 'extern "C"' block is not necessary anymore.
Also that made it harder to add any C++ code to some headers, or include headers
that have "optional" C++ code like `MEM_guardedalloc.h`.
I tested compilation on linux and windows (and got help from @LazyDodo).
If this still breaks compilation due to some linker error, the header containing
the symbol in question is probably missing an 'extern "C"' block.
Differential Revision: https://developer.blender.org/D7653
While it might be handy to have type-less functionality which is
similar to how C++ math is implemented it can not be easily achieved
with just preprocessor in a way which does not have side-effects on
wrong usage.
There macros where often used on a non-trivial expression, and there
was at least one usage where it was causing an actual side effect/bug
on Windows (see change around square_f(sh[index++]) in studiolight.c).
For such cases it is handy to have a function which is guaranteed to
have zero side-effects. The motivation behind actually removing the
macros is that there is already a way to do similar calculation. Also,
not having such macros is a way to guarantee that its usage is not
changed in a way which have side-effects and that it's not used as an
inspiration for cases where it should not be used.
Differential Revision: https://developer.blender.org/D7051
This is a more correct fix to the issue Brecht was fixing in D6600.
While the fix in that patch worked fine for linking it broke ASAN
runtime under some circumstances.
For example, `make full debug developer` would compile, but trying
to start blender will cause assert failure in ASAN (related on check
that ASAN is not running already).
Top-level idea: leave it to CMake to keep track of dependency graph.
The root of the issue comes to the fact that target like "blender" is
configured to use a lot of static libraries coming from Blender sources
and to use external static libraries. There is nothing which ensures
order between blender's and external libraries. Only order of blender
libraries is guaranteed.
It was possible that due to a cycle or other circumstances some of
blender libraries would have been passed to linker after libraries
it uses, causing linker errors.
For example, this order will likely fail:
libbf_blenfont.a libfreetype6.a libbf_blenfont.a
This change makes it so blender libraries are explicitly provided
their dependencies to an external libraries, which allows CMake to
ensure they are always linked against them.
General rule here: if bf_foo depends on an external library it is
to be provided to LIBS for bf_foo.
For example, if bf_blenkernel depends on opensubdiv then LIBS in
blenkernel's CMakeLists.txt is to include OPENSUBDIB_LIBRARIES.
The change is made based on searching for used include folders
such as OPENSUBDIV_INCLUDE_DIRS and adding corresponding libraries
to LIBS ion that CMakeLists.txt. Transitive dependencies are not
simplified by this approach, but I am not aware of any downside of
this: CMake should be smart enough to simplify them on its side.
And even if not, this shouldn't affect linking time.
Benefit of not relying on transitive dependencies is that build
system is more robust towards future changes. For example, if
bf_intern_opensubiv is no longer depends on OPENSUBDIV_LIBRARIES
and all such code is moved to bf_blenkernel this will not break
linking.
The not-so-trivial part is change to blender_add_lib (and its
version in Cycles). The complexity is caused by libraries being
provided as a single list argument which doesn't allow to use
different release and debug libraries on Windows. The idea is:
- Have every library prefixed as "optimized" or "debug" if
separation is needed (non-prefixed libraries will be considered
"generic").
- Loop through libraries passed to function and do simple parsing
which will look for "optimized" and "debug" words and specify
following library to corresponding category.
This isn't something particularly great. Alternative would be to
use target_link_libraries() directly, which sounds like more code
but which is more explicit and allows to have more flexibility
and control comparing to wrapper approach.
Tested the following configurations on Linux, macOS and Windows:
- make full debug developer
- make full release developer
- make lite debug developer
- make lite release developer
NOTE: Linux libraries needs to be compiled with D6641 applied,
otherwise, depending on configuration, it's possible to run into
duplicated zlib symbols error.
Differential Revision: https://developer.blender.org/D6642
