| Age | Commit message (Collapse) | Author |
|---|
|
We recently added delay-loading of the openmp dll's so we no longer had to use
the stub loader, we however put these linker flags on the global linker flags
causing any sub projects not using openmp to spit linker warning 4199 while building,
```
Warning LNK4199 /DELAYLOAD:vcomp140.dll ignored; no imports found from vcomp140.dll datatoc k:\BlenderGit\build_windows_2015a\source\blender\datatoc\LINK 1
```
This patch makes the delay-load only apply to the blender project.
Reviewers: sergey
Subscribers: sergey
Tags: #bf_blender
Differential Revision: https://developer.blender.org/D2092
|
|
Applying cflags globally can be problematic especially with extern, intern libs.
Now flags from target named will be used when defined,
allowing for developers to define flags for modules they maintain.
Convention is CMAKE_CFLAGS_${UPPERCASE_TARGET_NAME}, (CXXFLAGS for C++).
eg: CMAKE_CFLAGS_BF_BLENDER, CMAKE_CFLAGS_MAKESDNA, CMAKE_CXXFLAGS_CYCLES_KERNEL
On Linux run `make help` for full list of names, MSVC shows these in the solution.
|
|
This reverts commit f12204196fb1ee985ab9745cf9c70877601145f9.
Campbell, sorry. have to revert this for the time being.
We've missed some very important bits, such as:
- FFmpeg is usually linked against OpenJPEG
- OIIO needs OpenJPEG as well.
For FFmpeg issues we can either disable OpenJPEG there (since
we don't really use it), or bump FFmpeg to version 3.1.1 which
can use either of OpenJPEG 1.5 or 2.1.
For OIIO we do need OpenJPEG support (otherwise Cycles will
not be able to use j2k/j2c textures) and currently there is
NO solution to make OIIO working with OpenJPEG 2.1.
According to Matthias Fauconneau (aka mfv) Larry is working
on the patch to get OIIO work with OpenJPEG 2.1, but it'll
take some time still.
I've tried to look into support of some sort of build system
flag and do ifdefs, but it all becomes quite nasty, especially
with bundled OpenJPEG bumped to 2.1.
Surely such an update is something we'll have to apply to
but at this exact moment it causes quite some pain for all
developers.
Suggest to wait for until OIIO supports OpenJPEG 2.1 and then
go with the updates for real.
|
|
Stream handling has changed so this required changes to how files & memory are accessed.
|
|
|
|
|
|
You can capture and stream video in the BGE using the DeckLink video
cards from Black Magic Design. You need a card and Desktop Video software
version 10.4 or above to use these features in the BGE.
Many thanks to Nuno Estanquiero who tested the patch extensively
on a variety of Decklink products, it wouldn't have been possible without
his help.
You can find a brief summary of the decklink features here: https://wiki.blender.org/index.php/Dev:Source/GameEngine/Decklink
The full API details and samples are in the Python API documentation.
bge.texture.VideoDeckLink(format, capture=0):
Use this object to capture a video stream. the format argument describes
the video and pixel formats and the capture argument the card number.
This object can be used as a source for bge.texture.Texture so that the frame
is sent to the GPU, or by itself using the new refresh method to get the video
frame in a buffer.
The frames are usually not in RGB but in YUV format (8bit or 10bit); they
require a shader to extract the RGB components in the GPU. Details and sample
shaders in the documentation.
3D video capture is supported: the frames are double height with left and right
eyes in top-bottom order. The 'eye' uniform (see setUniformEyef) can be used to
sample the 3D frame when the BGE is also in stereo mode. This allows to composite
a 3D video stream with a 3D scene and render it in stereo.
In Windows, and if you have a nVidia Quadro GPU, you can benefit of an additional
performance boost by using 'GPUDirect': a method to send a video frame to the GPU
without going through the OGL driver. The 'pinned memory' OGL extension is also
supported (only on high-end AMD GPU) with the same effect.
bge.texture.DeckLink(cardIdx=0, format=""):
Use this object to send video frame to a DeckLink card. Only the immediate mode
is supported, the scheduled mode is not implemented.
This object is similar to bge.texture.Texture: you need to attach a image source
and call refresh() to compute and send the frame to the card.
This object is best suited for video keying: a video stream (not captured) flows
through the card and the frame you send to the card are displayed above it (the
card does the compositing automatically based on the alpha channel).
At the time of this commit, 3D video keying is supported in the BGE but not in the
DeckLink card due to a color space issue.
|
|
|
|
|
|
|
|
|
|
way as cuda 6.0 does allow, disabling cuda kernels on buildbot for now
|
|
way as cuda 6.0 does allow, disabling cuda kernels on buildbot for now
|
|
Was using O(n^2) lookup on ID's with undo.
This caused undo to hang with 1000's of data-blocks
(especially with heavy scenes & outliner-space, which doesn't even need to be visible to cause a slow-down).
Internally this uses a ghash per id-type, which is lazy-initialized.
Each key uses the name and library since there may be name collisions between libraries.
Developer Notes:
- Adds small `BKE_main_idmap_*` API.
- Needed to change linking order for this to build.
|
|
string from python to cmake to nvcc is harder then it looks
|
|
|
|
|
|
Spotted by Campbell, thanks!
|
|
|
|
|
|
Only Linux needs a lib linked in (libspnav).
ghostndof3dconnexion refers to an obsolete Mac driver shim.
|
|
Differential Revision: https://developer.blender.org/D2016
|
|
Since version 6 G++ switched to C++11 by default, which breaks some logic
around WITH_CXX11 checks in out CMake files, leading to compilation errors.
This is easy to solve by explicitly enabling older C++ standard when C++11
was not explicitly enabled by CMake options.
However, G++-6 will also use new ABI by default even if older standard was
specified in the compiler options. This is being addressed by a special
define flag.
This tricks made it possible to use new G++-6 without need to recompile
any of pre-compiled libraries.
However, this might break compilation with existing system libraries, which
might already be using new ABI. We can't address this automatically, so
now we simply default WITH_C11 and WITH_CXX11 options to whatever defaults
of the current compiler are. This means, for G++-6 we'll set WITH_CXX11 to
truth. This should make linking with system libraries working just fine,
but to make pre-compiled libraries we still might need to disable CXX11.
This should work fine work for a new environments with G++-6 and install_deps
script run from scratch there, because C++ standard will be the same for
both Blender dependencies and Blender itself.
|
|
External libraries may need char to be signed.
|
|
installed
install_deps can fail due to conflict between gcc (referenced by base-devel) and
gcc-multilib if the latter is installed. This avoids the conflict by filtering
the contents of base-devel when needed.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D1944
|
|
|
|
|
|
|
|
Note that recent DEB-based distro have packages for this, even simpler!
Differential Revision: https://developer.blender.org/D1933
|
|
with OSD.
In case too old system glew is detected, use the one shipped with blender.
Part of D1933.
|
|
This commit mostly:
* removes some (very) old messages or hacks (like those for ubuntu 10.4...).
* Moves lib-specific dependencies installations to upper level
(simpler to manage, and those are small enough packages).
* Uses new dnf package manager for fedora (sigh, we now have tree different commands for fed/suse/rehl).
* fixes or enhances some options for commandline tools.
* Force anew building of oiio package, due to insane dependencies of this one in recent distro.
Part of D1933.
|
|
- BKE_blender_version.h (only version defines & versionstr).
- BKE_blender_copybuffer.h (currently only used for view3d copy/paste).
- BKE_blender_undo.h (global undo functions).
- BKE_blendfile.h (high level blend file read/write API).
|
|
|
|
This mainly touches extern libraries and few debug-only places in intern.
Some summary:
- External libraries are not strict at all about missing declarations,
so we can rather safely remove such warning together with other strict
flags.
- Bullet has some static functions which are not used.
Those were commented out.
- Carve now has some unused debug-only functions commented out as well.
While we're on the way of getting rid of Carve, it makes sense to make
things a bit cleaner for the time being.
- In LZMA we have some parts disabled which gives some set but unused
variables which is rather correct.
- Elbeem had quite some variables set and never used because their usage
is inside of debug-only code which is commented out.
Note about patching upstream libraries: surely one might say that we
have to make local patchset against this, but own experience says it
only gives extra work trying to merge such tweaks to a new upstream
version and usually it's just faster to re-apply such fixes again after
bundling new upstream library.
|
|
The script is updated for ArchLinux, since all dependencies are included in Arch's official repositories.
I've made a few changes, such as enabling OCIO and OSD without requiring locally installed lib-path, and a fix to ''get_package_version_ARCH()' so it ignores package epoch (as in the case of ffmpeg).
I intend to look at OpenVDB next.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D1901
|
|
This will be used for calculating bezier curves from freehand drawing,
may be used for other areas too.
Original code from GraphicsGems, 1990 (FitCurve.c),
with updates from OpenToonz, under 3 clause BSD license.
with own minor modifications for integration with Blender:
- support adding extra custom-data.
- improved handle clamping.
|
|
Also update ignore list.
|
|
|
|
|
|
They were never running anyway since there's no checkout of
tests folder. We should either make tweaks to buildbot master
to make it to send cloning commands for tests folder and keep
tests working (currently some of them are broken).
|
|
|
|
|
|
Ideally this would need to be fixed by nvcc itself. but they didn't
do that for a long time.
|
|
Looks like some distro still provide llvm-3.4-devel, while no more clang-3.4.
Since clang depends on llvm of same version, check clang only should ensure
us we also have matvhing llvm... *sigh*
|
|
Until we officially support llvm3.5 or more, only allow for 3.4 llvm packages,
and build own stuff otherwise...
|
|
While it was indirectly disabled already, it's handy to use the config
as template and enable certain features. In case of Cycles enabling it
would also enable OSL which is not very expected.
|
|
Also add note that these should be deprecated in favor of absolute libs.
|
|
This is a bit tricky, find_package(Git) was only used to check if git is installed
and actual git command was assumed to be in the PATH (while ideally it should have
been GIT_COMMAND variable).
This commit makes re-compile output cleaner, especially when using Ninja.
Adding proper GIT_COMMAND to buildinfo.cmake is also possible via argument.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1847
|
|
This patch enables libboost_iostreams and bumps the magic number to match.
Reviewers: dingto
Reviewed By: dingto
Subscribers: dingto
Projects: #bf_blender, #platform:_linux
Differential Revision: https://developer.blender.org/D1840
|
|
find_package(Git) will already print this.
|
