| Age | Commit message (Collapse) | Author |
|---|
|
Performance is about the same or slightly better for typical IK chains.
In extreme cases with many bones and multiple targets, of which some are
unreachable, I've seen 2x speedups.
|
|
|
|
currently for bmesh
|
|
Eigen3 bug report: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1131
|
|
In practice this hardly ever happened.
|
|
Avoid double lookup on insertion ghash
|
|
The main purpose of this is to get MSVC 2015 fixes
|
|
|
|
|
|
|
|
This commit introduces a few operators to make it easier to perform a few common
layer-manipulation operations. Some of these have been sorely needed for quite
a while now...
* Lock/Unlock All - Just as their names suggest, these operators will lock and unlock
all layers in the GP datablock. This is a quick way to unlock all layers previously
locked. These can be found in the new dropdown which replaces the old "Duplicate"
below the +/- (for adding/removing layers); also featured in the dropdown are
the "Duplicate Layers" operator, as well as the show/hide ones.
* Isolate Layer - This operator makes it easy to focus on just a single layer (e.g. the
outlines for a particular character). The "star" button affects editability, while the
"eye" below it toggles editability + visibility.
If any layer is visible/unlocked, this operator will lock and/or hide all; otherwise,
it will unlock/unhide all (to reverse the previous operation).
|
|
Differential Revision: https://developer.blender.org/D1662
|
|
|
|
Those stupid ones only have one version of llvm (obviously not 3.4 one ;) ), so we have to build again
LLVM3.4 in those cases. Thing is,
* I did not update LLVM magic number when fixed a stupid typo breaking OSL building (the terminfo thing),
so many people were still using previously-built LLVM.
* Even worse, options passed to OSL to specify own LLVM from /opt/lib were wrong (not sure when this got
out of sync...).
Thanks to mib2berlin and slikdigit for the report & testings!
|
|
RPM-based distro...
|
|
|
|
|
|
with OPM and 3.5.0).
|
|
command line.
Avoid user to have to edit themselves their CMake config.
Thanks a bunch @campbellbarton for the tip! :D
|
|
|
|
Isolate edge-net splitting in preparation for other functions to be added here.
|
|
|
|
|
|
|
|
need it.
|
|
|
|
FBOs are a GL 3.0 feature but enjoy nearly universal support via
extensions.
The newer ARB extension brings these features to GL 2.1 without needing
an ARB suffix.
The older EXT extensions *do* use a suffix. Since we don’t know which
is used until runtime, I added the suffix to all functions & enums.
Also updated the check to look for the FBO feature set instead of the
specific EXT extension.
|
|
Maybe this is pedantic but I read it’s best to explicitly set the
desired component size.
Also append “_ARB” to float texture formats since those need an
extension in GL 2.1.
|
|
Comment says this is from the MacOS 10.5 era. Surely it’s been fixed by
now. If nobody complains in the next few months let’s delete this.
|
|
It’s still immediate mode, but at least it’s shorter & clearer.
|
|
This class did nothing but print out extensions if they were found.
Instead, the code from bge.logic.PrintGLInfo() is now printed as the
Rasterizer is initialized. This gives better information, and it removes
some GL code from KX_PythonInit.cpp (the PrintGLInfo method now calls
the Rasterizer to print the information).
Differential Revision: https://developer.blender.org/D438
|
|
The only use we had for RAS_StorageIM was to render derived meshes using
Blender's mesh drawing. This is now handled as a special case in
RAS_OpenGLRasterizer instead of in RAS_StorageIM.
We are now left with RAS_StorageVA and RAS_StorageVBO. At the moment
vertex arrays are still the default since our vertex array with display
lists implementation is still much faster than our VBO code in a lot of
cases. As we improve our VBO code, we can drop vertex arrays since
Blender's minimum OpenGL version is being bumped up to 2.1, which
supports VBOs.
|
|
The work that was being done in IndexPrimitiveMulti() is now done by
IndexPrimitive() and we always assume multitexture support.
|
|
|
|
|
|
|
|
In modern usage this means the conjugate transpose, but we stick to
the classical usage (i.e. adjugate matrix), like Eigen does.
|
|
|
|
all in the 3D View!
|
|
in the 3D View
|
|
|
|
Use new GPU_legacy_support() function.
Determine GLSL version once instead of per shader.
For Texture Buffers, allow ARB or EXT version of the extension. Either
one will do.
|
|
+ minor cleanup
|
|
Is current context compatible with legacy GL (version 2.1)?
My earlier approach -- checking for GLEW_ARB_compatibility -- was not
enough.
This should always return true if we set our GL context up properly. It
will return false when we switch to core profile.
|
|
In practice this gives us a context that is *compatible* with GL 2.1. On
my machine it gives a GL 3.3 or 4.3 compatibility profile context,
depending on graphics card installed.
Also fixed enum for core profile (not used yet).
Also added option for GL 3.2 compatibility profile. This will be useful
during Blender 2.8 development, until we are able to use the core
profile. On my machine this gives exactly a GL 3.2 compatibility profile
context, not 3.3 or 4.
|
|
My previous edit to this check was too lax.
OSD's shader for the Transform Feedback evaluator declares itself
#version 410 so disable the feature if user's GL < 4.1.
|
|
This way, connecting Value or RGB node to e.g. a Math node will still allow folding.
Note: The same should be done for the ConvertNode, but I leave that for another day.
|
|
|
|
Would be true in most cases (and in particular with own generated geometry),
but in case one would be using original geometry this could have crashed badly.
|
|
Note that I tried to parallelize the loops porting result of the simulation to the
DM data itself, but that ended up being 20% slower than non-threaded code!
|
