| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Caused by use of the uninitialized shape_ variable in Resize().
|
|
|
|
|
|
|
|
|
|
The issue was caused by RedCode library printing binary string to the terminal.
|
|
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.
|
|
|
|
|
|
Also add depsgraph & physics
|
|
|
|
|
|
also use const
|
|
|
|
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.
|
|
Optionally use systems eigen3 library.
T41989 by @hasufell with edits
|
|
|
|
Patch T41989 by @hasufell
|
|
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.
|
|
|
|
|
|
D888 by @sambler
|
|
Seems different distros might have different naming rules, so need
to adopt our code for that.
|
|
|
|
No idea why standalone libmv remo was all fine with the code..
|
|
|
|
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.
|
|
Basically, title says ti all, the option is called WITH_BF_CYCLES_LOGGING
|
|
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
|
|
|
|
SCons is currently broken on my laptop, so can't test if it works for sure,
so please do tests of that.
|
|
|
|
|
|
|
|
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.
|
|
Pretty much straightforward changes, nothing to be mentioned specially.
|
|
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.
|
|
to variables and functions
|
|
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).
|
|
|
|
just to be sure we're dealing with the latest git version when troubleshooting
one annoying OSX issue..
|
