Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
When loading huge images (30k) blender crashed with a buffer overflow.
The reason is that determine the length of a buffer was done in 32bit
precision and afterwards stored in 64 bit precision.
This patch adds a new function to do the correct calculation in 64bit.
It should be added to other sections in blender as well. But that should
be tested on a per case situation.
Instead of submitting tons of tiny IO syscalls, we can speed things up
significantly by `mmap`ing the .blend file into virtual memory and directly
accessing it.
In my local testing, this speeds up loading the Dweebs file with all its
linked files from 19sec to 10sec (on Linux).
As far as I can see, this should be supported on Linux, OSX and BSD.
For Windows, a second code path uses `CreateFileMapping` and
`MapViewOfFile` to achieve the same result.
Reviewed By: mont29, brecht
Differential Revision: https://developer.blender.org/D8246
With Blender 2.80 we introduced a more flexible matcap system. One
change we did was to multiply the matcap with the base color that was
shaded. As matcaps contains diffuse and specular lighting in a single
texture this lead to rendering artifacts. Artists were complaining that
everything looked to metalic.
We now support a separate `diffuse` and `specular` pass for matcaps.
`shaded_color = diffuse_light * base_color + specular_light`
For matcaps to support this feature they need to be multilayer openexr
files with 2 renderpasses (named `diffuse` and `specular`). In the future
we can change this to first pass/second pass in stead of this naming
convention.
Reviewed By: fclem, brecht
Differential Revision: https://developer.blender.org/D5335
This patch implements new cache system.
Aim is to give user more control over cache, so it can be maximally
utilized. This is done through sequencer timeline side panel
in category proxy & cache.
Cached images are also visualized in timeline, controled by
sequencer timeline view->cache menu
Functional changes:
- NOT use IMB_moviecache API
- refactor names of cached image types
- each scene owns 1 sequencer cache
- merge preprocess cache into per-sequencer cache
- cache links images rendered per frame in order as they are created
- add cache content visualization tool
- add RNA properties to control the cache
More info can be found in design notes in blenkernel/intern/seqcache.c
and in https://developer.blender.org/D4443
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4443
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.
- Metadata handling is now separate from `ImBuf *`, allowing it to be
used with a generic `IDProperty *`.
- Merged `IMB_metadata_add_field()` and `IMB_metadata_change_field()`
into a more robust `IMB_metadata_set_field()`. This new function
doesn't return any status (it now always succeeds, and the previously
existing return value was never checked anyway).
- Removed `IMB_metadata_del_field()` as it was never actually used
anywhere.
- Use `IMB_metadata_ensure()` instead of having
`IMB_metadata_set_field()` create the containing `IDProperty` for
you.
- Deduplicated function declarations, moved `intern/IMB_metadata.h` out
of `intern/`. Note that this does mean that we have some extra
`#include "IMB_metadata.h"` lines now, as the metadata functions are
no longer declared in `IMB_imbuf.h`.
- Deduplicated function declarations, all metadata-related declarations
are now in imbuf/IMB_metadata.h.
Part of: https://developer.blender.org/D2273
Reviewed by: @campbellbarton
Noisy change, but safe, and better do it sooner than later if we are to
rework copying code. Also, previous commit shows this *is* useful to
catch some mistakes.
`IMB_remakemipmap` may 'shrink' the mipmap list without actually freeing
anything, so we need to check all possible levels in `imb_freemipmapImBuf`
to avoid memory leaks, not only those currently used.
The issue was caused by the image save operator ignoring Z-Buf if the input
buffer due to the way how IMB_dupImBuf() worked. There's no reason to to
ignore z-buf on imbuf duplication, it only asks for issues in the future.
Windows-only bug, mmap & co are not threadsafe by default on this platform, so we have to add a dedicated
spinlock for them in win32.
Note that we may try to get rid of those mmap later, but not for 2.76!
To be backported to final 2.76...
ImBuf types were getting stored as bitflags in a 32bit integer which had
already run out of space. Solved the problem by separating file type to
an ftype enum, and file specific options to foptions.
Reviewed by Campbell, thanks a lot!
transform.
IMB_makeSingleUser makes a copy and destroys metadata. I am not sure if
this is the safest way to make a single user ImBuf (setting the refcount
to 0 is simpler and there's less, but no zero, risk of dangling
pointers) but I will leave this as is for now in case there is an actual
need for a copy here. The alternative approach should be tested at some
point.
Moral of the story: Make sure that size_t is used whenever pointer
arithmetic is involved. For images, that basically means whenever any
squared dimensions are involved. Casting an operand to size_t early in
the operation is usually sufficient to force the entire operation to
size_t.
There might still be places lurking where we don't support this
correctly. This has been tested with render pipeline, quite a few image
functions (meaning we can paint on such images now, albeit somewhat
slowly ;) ) and export to jpeg. Too many places in code to check so I
guess we'll be handling cases as they come.
Don't try this at home unless you have an immense ammount of RAM.
First GPixel render of suzanne in the multiverse can be found here:
http://download.blender.org/demo/test/suzanne-billion-pixel.jpg
Can be viewed from blender (takes about 3.3 GB after loading but may
take more during loading so 8GB might be more safe to try this).
Issue is likely caused by thread-unsafe nature of IMB_freeImBuf
which might lead to race condition in some circumstances.
Now made it thread-safe and from Sebastian's tests seems crash is
gone now, so hopefully the root of the issue is finally nailed down.
