We've got quite comprehensive BMesh based implementation, which is way easier
for maintenance than abandoned Carve library.
After all the time BMesh implementation was working on the same level of
limitations about manifold meshes and touching edges than Carve. Is better
to focus on maintaining one boolean implementation now.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D3050
This brings separate initialization for libcuda and libnvrtc, which
fixes Cycles nvrtc compilation not working on build machines without
CUDA hardware available.
Differential Revision: https://developer.blender.org/D3045
nvcc is very picky regarding compiler versions, severely limiting the compiler we can use, this commit adds a nvrtc based compiler that'll allow us to build the cubins even if the host compiler is unsupported. for details see D2913.
Differential Revision: http://developer.blender.org/D2913
Deleting the old internal audaspace.
Major changes from there are:
- The whole library was refactored to use C++11.
- Many stability and performance improvements.
- Major Python API refactor:
- Most requested: Play self generated sounds using numpy arrays.
- For games: Sound list, random sounds and dynamic music.
- Writing sounds to files.
- Sequencing API.
- Opening sound devices, eg. Jack.
- Ability to choose different OpenAL devices in the user settings.
The Issue
=======
For a long time now MinGW has been unsupported and unmaintained and at this point,
it looks like something that we should just leave behind and move on.
Why Remove
==========
One of the big motivations for MinGW back in the day is that it was free compared to MSVC which was licensed based.
However, now that this is no longer true we have basically stopped updating the need CMake files.
Along with the CMake files, there are several patches to the extern libs needed to make this work. For example, see:
https://developer.blender.org/diffusion/B/browse/master/extern/carve/patches/mingw_w64.patch
If we wanted to keep MinGW then we would need to make more custom patches to the external libs and
this is not something our platform maintainers are willing to do.
For example, here is the patches needed to build python: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
Fixes T51301
Differential Revision: https://developer.blender.org/D2648
Avoid calculating a new split-index when re-fitting.
While checking if a knot can be removed, the index with the highest error
can be used as a candidate to replace the knot
(in the case it can't be removed).
MX (Multiple conteXt) support was dropped from the GLEW 2.0 library to make core profile support cleaner.
Our WITH_GLEW_MX build option was OFF by default already; this commit removes the inactive code paths.
I'm working on a plan for multiple GPUs, contexts, resource sharing, etc. This commit gives us a cleaner starting point for that upcoming work.
Tested on Mac, will test on Linux & Windows immediately after pushing.
It is disabled by default, so should not affect existing configurations.
Main benefits of this goes as:
- Linux distros can use that to avoid libraries duplication and link
blender package against gflags package from the system.
- It it easier to test whether Blender works with updated version of
Gflags prior to re-bundling the library.
Rewrite the current range-tree API used by dyn-topo undo
to avoid inefficiencies from stdc++'s set use.
- every call to `take_any` (called for all verts & faces)
removed and added to the set.
- further range adjustment also took 2x btree edits.
This patch inlines a btree which is modified in-place,
so common resizing operations don't need to perform a remove & insert.
Ranges are stored in a list so `take_any` can access the first item
without a btree lookup.
Since range-tree isn't a bottleneck in sculpting, this only gives minor speedups.
Measured approx ~15% overall faster calculation for sculpting,
although this number time doesn't include GPU updates and depends on how
much edits fragment the range-tree.
This is an alternative method for fitting a curve which incrementally simplifies the curve, then re-fits.
Generally gives better results, also improves corner detection.
This reverts commit f12204196f.
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.
When this flag is set - even when the curve error is under the threshold,
keep attempting a better fit.
Enable this for freehand drawing, since it gives nicer results and isn't noticeably slower.
Add a new fallback method that uses offset distance from the curve to the line between both points,
for freehand drawing it typically only fives minor improvements (1-3% fewer points),
for curve dissolve the improvements are more noticeable.
Take curvature into account when calculating handle length.
Gives significantly better results for curve dissolve and 10-20% more efficient freehand drawing.
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.
Solves following issues:
- Quite reasonable amount of paranoid warnings were solved by an upstream
- Upstream seems to have all fixes needed for FreeBSD and OSX already
- Brings all fixes and such from upstream
- Access with Shift-LMB or from the 'Create' toolbar tab.
- Uses curve fitting for bezier curves, with error and corner angle options.
- Optional tablet pressure to curve radius mapping.
- Depth can use the cursor or optionally draw onto the surface,
for the entire stroke or using the stroke start.
- Stroke plane can optionally be perpendicular to, or aligned to the surface normal.
- Optional radius tapering and for start/end points.
- Supports operator redo and calling from Python.
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.
The header which was put to the CMake project is not by any means used
during compilation, it is only used when manually updating CUDA wrangler
from CUDA headers.
The version of Recast that Blender ships with is from 2009. This patch updates the Recast version to the latest version, 1.5.0. The Detour version remains untouched.
Reviewers: campbellbarton, moguri
Reviewed By: moguri
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1747
There's no need to mix ints and size_t here at all
because all the values fits into integer.
It's unlikely we'll be re-bundling Carve, so didn't
bother with the patchset.
D1751, remove this library since its quite a specific - only supports an older version of this codec.
Also ffmpeg has added support for recent versions of the codec.
I tried to carefully preserve all patches since the last upgrade.
Improves T47195, cloth collision detection bug.
Differential Revision: https://developer.blender.org/D1739
I've been using this fix in another branch locally, so it seems to work fine.
The other #ifdef checks should be checked on too, as __MINGW32__ and __MINGW64__
do NOT seem to be defined when compiling that file
Previously several areas were calling TEST_SHARED_PTR_SUPPORT and
TEST_UNORDERED_MAP_SUPPORT which isn't that bad on it's own but
was causing some quite verbose output with same information line
printed multiple times. additionally, what's more worse, define flags
for Ceres were duplicated in main CMakeLists and Ceres's CMakeLists.
Now we've got a single place where checks for those classes are
happening and other areas are simply checking for variables set by
those check macros, keeping CMake output clean and nice.
The main purpose of such linking is to make Blender compatible with
NVidia's debuggers and profilers which are doing some LD_PRELOAD
magic to intercept some function calls. Such magic conflicts with
our CUDA wrangler magic and causes segmentation faults.
The option is disabled by default, so there's no affect on any of
artists.
In order to make Blender linked directly against CUDA library use
the WITH_CUDA_DYNLOAD CMake option (it's marked as advanced).
The idea is to split them into two separate targets and have dedicated include
directories list for each of them in order to avoid some annoying include header
modifications in comparison with upstream.
Reviewers: campbellbarton, juicyfruit
Differential Revision: https://developer.blender.org/D1706
While SCons building system was serving us really good for ages it's no longer
having much attention by the developers and started to become quite a difficult
task to maintain.
What's even worse -- there started to be quite serious divergence between SCons
and CMake which was only accumulating over the releases now. The fact that none
of the active developers are really using SCons and that our main studio is also
using CMake spotting bugs in the SCons builds became quite a difficult task and
we aren't always spotting them in time.
Meanwhile CMake became really mature building system which is available on every
platform we support and arguably it's also easier and more robust to use.
This commit includes:
- Removal of actual SCons building system
- Removal of SCons git submodule
- Removal of documentation which is stored in the sources and covers SCons
- Tweaks to the buildbot master to stop using SCons submodule
(this change requires deploying to the server)
- Tweaks to the install dependencies script to skip installing or mentioning
SCons building system
- Tweaks to various helper scripts to avoid mention of SCons folders/files
as well
Reviewers: mont29, dingto, dfelinto, lukastoenne, lukasstockner97, brecht, Severin, merwin, aligorith, psy-fi, campbellbarton, juicyfruit
Reviewed By: campbellbarton, juicyfruit
Differential Revision: https://developer.blender.org/D1680
It's quite small chance we'll be supporting suitesparse for Blender due to all
the complexity of 3rd party libraries, so removing implementation files which
are only needed when suitesparse is enabled.
The issue was caused by the following construction:
def = env['SOMETHING']
defs.append('SOMETHING_MORE')
Since first assignment was actually referencing environment option it was totally
polluted hawing weird and wonderful side effects on all other areas of Blender.
This commit contains all the remained parts needed for initial integration of
OpenSubdiv into Blender's subdivision surface code. Includes both GPU and CPU
backends which works in the following way:
- When SubSurf modifier is the last in the modifiers stack then GPU pipeline
of OpenSubdiv is used, making viewport performance as fast as possible.
This also requires graphscard with GLSL 1.5 support. If this requirement is
not met, then no GPU pipeline is used at all.
- If SubSurf is not a last modifier or if DerivesMesh is being evaluated for
rendering then CPU limit evaluation API from OpenSubdiv is used. This only
replaces the legacy evaluation code from CCGSubSurf_legacy, but keeps CCG
structures exactly the same as they used to be for ages now.
This integration is fully covered with ifdef and not enabled by default
because there are several TODOs to be solved first:
- Face varying data interpolation is not really cleanly implemented for GPU
in OpenSubdiv 3.0. It is also not implemented for limit evaluation API.
This basically means we'll have really hard time supporting UVs.
- Limit evaluation only works with adaptivly subdivided meshes so far, which
basically means all the points of CCG are pushed to the limit. This gives
different result from old code.
- There are some serious optimizations possible on the topology refiner
creation, which would speed up initial OpenSubdiv mesh creation.
- There are some hardcoded asumptions in the GPU and DerivedMesh areas which
could be generalized.
That's something where Antony and Campbell can help, making it so the code
is structured in a way which is reusable by all planned viewport projects.
- There are also some workarounds in the dependency graph to make sure OpenGL
buffers are only freed from the main thread.
Those who'll be wanting to make experiments with this code should grab dev
branch (NOT master) from
https://github.com/Nazg-Gul/OpenSubdiv/tree/dev
There are some patches applied in there which we're working on on getting
into upstream.
It gives issues with Glog compiled in release mode.
Need to revisit the directory layout here and compiler flag, because technically
libmv is now more an intern/ library and i'll actually prefer it to be covered
with strict flags as well. But it's a bit tricky because of libraries which we
don't maintain are in the libmv subfolder.
It is rather annoying attitude nowadays to use const qualifier all over the
place, including using it for multi-dimensional arrays. This isn't really
supported in GCC prior to version 5.0 because it considers such an arrays
to be a "pointer to a const pointer" which gives implicit casting errors.
It's not possible to disable this particular type of warnings treated as
errors in any GCC version prior to 5.0 as well, meaning currently usage of
-Werror globally in Blender code is not possible at all.
This commit makes it possible to use -Werror in areas which are complaint
with older GCC versions. New advanced CMake options are:
- WITH_COMPOSITOR_WERROR
- WITH_LIBMV_WERROR
- WITH_CYCLES_WERROR
Title says pretty much everything. For now, only thing available is a solver of eigen
values/vectors for self-adjoint matrices.
We can easily add more when needed.
Thanks to Sergey and Campbell for quick review.
For some reason recent change in avoiding non-aligned eigen vectors
was behaving differently for cmake and scons. Made it a bit different
now by storing scalars. This is more robust approach anyway, because
it's not really guaranteed Mat.col() gives a pointer inside data,
depending on column-major vs. row-major storage.
This is to be backported to 2.74 branch.
It was only happening on 32bit platforms because of alignment
differences when allocating class.
Now got rid of copy of eigen matricies stored by value in the
residual block which solves aligment issues and should also
give some unmeasurable speedup.
Main purpose of this is to bring new gflags library which is more likely
to have a fix for undefined order of static variables initialization and
also to bring new glog where some compilation error are fixed (which are
only visible with more strict checks with clang and c++11 enabled).
The main idea is to share as much code between cases when feature-full built
is done and only logging is needed, so all the defines and include directories
are guaranteed to be the same.
This would hopefully make it so MinGW compilation is all happy about Cycles
logging for both CMake and SCons.
Couple of issues:
- Fist/last frame calculation was wrong
- Keyframe selection might silently fail leading to unpredictable math
errors all over the place. Now if keyframe selection fails solver wouldn't
run.
This is mainly to address old issue when one need to have SDL library installed
in order to use our official builds. Some hip distros already installs SDL,
but it's not quite the same across all the variety of the distros.
We also now switching to SDL-2.0, most of the distros have it in repositories
already, so it shouldn't be huge deal to install it if needed.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D878
This was never ported to a new tracking pipeline and now it's done using
FrameAccessor::Transform routines. Quite striaghtforward, but i've changed
order of grayscale conversion in blender side with call of transform callback.
This way it's much easier to perform rescaling in libmv side.
The title actually tells it all, this commit switches Blender to use the new
autotrack API from Libmv.
From the user point of view it means that prediction model is now used when
tracking which gives really nice results.
All the other changes are not really visible for users, those are just frame
accessors, caches and so for the new API.
This starts the creating the new AutoTrack API. The new API will
make it possible for libmv to do full autotracking, including
predictive tracking and also support multiple motion models (3D
planes etc).
The first goal (not in this patch) is to convert Blender to use
the new API without adding any new functionality.
This API currently contanins:
- Frame accessor to access frames which are stored in Blender side.
- New Tracks implementation
- New Reconstruction implementation
Currently this API only tested on doing the same frame-to-frame
tracking as the old API allowed to do. But it also supports now
predictive tracking which is based on the Kalman filter.
The ones in extern/glew-es have been changed to NOTE instead of XXX
GHOST_ContextEGL.cpp: It really does seem that it is not possible to query the swap interval using EGL
GHOST_WidnowCocoa.h: The comment referring to Carbon is clearly out of date, so I removed it.
math_geom.c: The node about not using tmax again is correct, but the code is kept for a future maintainer who will need to know how to compute it if they modify that code.
paint_image_proj.c (2698): The question about integer truncation does not appear to have been resolved. It still seems to be an incorrectly implementation of rounding (I'd suggest using the round function instead of this hack).
Sergey Sharybin
Campbell Barton
Brecht Van Lommel
Ray Molenkamp
Dalai Felinto
Germano
Sybren A. Stüvel
Jörg Müller
Bastien Montagne
Aaron Carlisle
Mike Erwin
Nathan Letwory
Joshua Leung
Reinier de Blois
Martijn Berger
Martijn Berger
Ines Almeida
Keir Mierle
Jens Verwiebe
Jason Wilkins