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
Quite handy for debugging.
Unfortunately, this doesn't support viewport tweaks yet since those
require GLSL for colorspace conversion. Maybe this will be implemented
as well one day in the future..
Was a ground work for some more improvements here, but got dragged
to some other studio maintenance job here.
The plan would be to enable exposure/gamma control for fallback mode
which will definitely be really handy for development and might be
handy for cases when OCIO config can not be read.
White the config itself could be loaded this way, lookup tables can not. Additionally,
that's not really clear how to solve the issue with search path which is multi-byte
only in the API.
Reverting for further investigation.
This reverts commit ab4307aa08.
Those warnings are trigerred by stl classes in OCIO's public interface.
To quote MSDN: "C4251 can be ignored if you are deriving from a type in
the Standard C++ Library"
This is the only instance where those warnings hunts us, so for now we
can keep it all local in intern/opencolorio but this might be changed
in the future.
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
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.
We queried the wrong value when looking for the bound 2D texture. This
is not totally robust because currently bound texture may not be a 2D
one, but this should work for now.
The GLSL function textureSize() is not supported here, only when we start using
OpenGL core profile will this work. For now check the supported GLSL version and
use a somewhat slower replacement.
Summary:
Uses some magic pseudo-random which is actually a
texture coordinate hashing function.
TODOs:
- Dither noise is the same for all the frames.
- It's different from Floyd's dither we've been
using before.
- Currently CPU and GPU dithering used different
implementation. Ideally we need to use the same
dither in CPU.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: http://developer.blender.org/D58
Summary:
Version of those libraries might be useful to know.
- OIIO and OCIO is exposed via bpy.app.oiio and bpy.app.ocio.
There're "supported", "version" and "version_string" defined
in those modules.
- OSL is available as _cycles.osl_version and _cycles.osl_version_string.
Reviewers: campbellbarton
Reviewed By: campbellbarton
CC: dingto
Differential Revision: http://developer.blender.org/D79
report by email and patch by Benoit Bolsee
"It is a basic compilation bug (variable defined in a c file and declared
in the c++ file: name decoration will change the name in the c++ file
and the linker will not find it)"
The title says it all, now having curve mapping
enabled in color management settings wouldn't
force fallback from GLSL to CPU based color space
conversion.
Also made libmv-capi use guarded objetc allocation.
Run into some suspecious cases when it was not so
clear whether memory is being freed or not.
Now we'll know for sure whether there're leaks or not :)
Having this macros in a guardedalloc header helps
using them in other areas (for now it's OCIO and libmv,
but in the future it'll be more places).
This commit implement's OCIO's Looks idea which
is about applying some color correction on the
buffer before it get's affected by a display
transform.
This is mainly used to modify images in an
artistics way.
Currently we've got looks generated from film
response curves for all sorts of cameras.
Patch by both of me and Brecht.
shader for converting colors from linear to display space, based on the scene
color management settings.
if engine.support_display_space_shader(scene): # test graphics card support
engine.bind_display_space_shader(scene)
# draw pixels ..
engine.unbind_display_space_shader()
Issue was caused by some mesa drivers does not support GL_RGBA16F.
Now added check around glTexImage2D to verify whether requested
internal format is actually supported. If not blender will fall
back to non-GLSL image display.
- GLSL shader wasn't aware of alpha predivide option,
always assuming alpha is straight. Gave wrong results
when displaying transparent float buffers.
- GLSL display wasn't aware of float buffers with number
of channels different from 4, crashing when trying to
display image with different number of channels.
This required a bit larger changes, namely now it's
possible to pass format (GL_RGB, GL_RGBAm GL_LUMINANCE)
to glaDrawPixelsTex, This also implied adding format to
glaDrawPixelsAuto and modifying all places where this
functions are called.
Now GLSL will handle both 3 and 4 channels buffers,
single channel images are handled by CPU.
- Replaced hack for render result displaying with a bit
different hack.
Namely CPU conversion will happen only during render,
once render is done GLSL would be used for displaying
render result on a screen.
This is so because of the way renderer updates parts
of the image -- it happens without respect to active
render layer in image user. This is harmless because
only display buffer is modifying, but this is tricky
because we don't have original buffer opened during
rendering.
One more related fix here was about when rendering
multiple layers, wrong image would be displaying when
rendering is done. Added a signal to invalidate
display buffer once rendering is done (only happens
when using multiple layers). This solves issue with
wrong buffer stuck on the display when using regular
CPU display space transform and if GLSL is available
it'll make image displayed with a GLSL shader.
- As an additional change, byte buffers now also uses
GLSL display transform.
So now only dutehr and RGB curves are stoppers for
using GLSL for all kind of display transforms.
Apparently C== allowed to have implementations of
OCIOImpl::setupGLSLDraw, OCIOImpl::finishGLSLDraw and
OCIOImpl::freeGLState in two different files.
STUPID!
Implemented using GLSL API from OpenColorIO library and
some general functions were added to it's c-api:
- OCIO_setupGLSLDraw prepares OpenGL context for GPU-based
transformation for a giver processor.
This function compiles and links shader, sets up it's
argument. After this transformation would be applied
on an image displaying as a 2D texture.
So, glaDrawPixelsTex called after OCIO_setupGLSLDraw will
do a proper color space transform.
- OCIO_finishGLSLDraw restores OpenGL context after all
color-managed display is over.
- OCIO_freeOGLState frees allocated state structure used
for cacheing some GLSL-related stuff.
There're some utility functions in IMB_colormanagent which
are basically proxies to lower level OCIO functions but
which could be used from any place in blender.
Chacheing of movie clip frame on GPU is also removed now,
and either glaDrawPixelsTex or glaDrawPixelsAuto are used
for display now. This is so no code duplication happens
now and no large textures are lurking around in GPU memory.
Known issues:
- Texture buffer and GLSL are no longer checking for
video card capabilities, possibly could lead to some
artifacts on crappy drivers/cards.
- Only float buffers are displaying using GLSL, byte
buffers will still use fallback display method.
This is to be addressed later.
- If RGB curves are used as a part of display transform,
GLSL display will also be disabled. This is also thing
to be solved later.
Additional changes:
- glaDrawPixelsTexScaled will now use RGBA16F as an
internal format of storing textures when it's used
to draw float buffer. This is needed so LUT are
applied without precision loss.
- move object_iterators.c --> view3d_iterators. (ED_object.h had to include ED_view3d.h which isn't so nice)
- move projection functions from view3d_view.c --> view3d_project.c (view3d_view was becoming a mishmash of utility functions and operators).
- some some cmake includes as system-includes.