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.
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!
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.
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.
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.
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.
