I heard that the actual solution would be to remove #include <pthread.h> from BLI_threads.h
But in the mean time is not fair to CMake/MSVC to be the only system not building ;)
* Division by zero fix for TNT SVD code.
* Sound fix, in case ffmpeg decode fails, don't use the samples.
* Fix for incorrect bounds of transformed objects in new raytracing code.
* Gave memory arena's a name used for allocations for easier memory
usage debugging.
* Dupligroup no_draw option was using layers but not restrict view/render
setting. (not a bugfix exactly but would do display list context switching
while drawing for no reason).
* Fix objects instanced on hair particles not giving consistent results
when the object is transformed.
* New math functions: madd_v4_v4fl, len_squared_v3v3, interp_v4_v4v4v4,
mul_v4_m4v4, SH and form factor functions, box_minmax_bounds_m4.
* mul_m4_m4m4 and mul_m3_m3m3 now accept the same pointers for multiple
arguments.
* endjob callback for WM jobs system.
* Geometry node uv/color layer now has search list/autocomplete.
* Various small buildsystem tweaks, not strictly needed yet in trunk.
The problem was present in Blender 2.49, but it didn't produce any side effect.
glScale was changing the texture matrix and the matrix was never been reset. That messes up with UI drawing.
Note, this is not like GE ffmpg, but Blender Image Texture
display for GLSL materials. Speed can be disappointing,
use smaller images for realtime edits.
set the draw method to triple buffer or overlap depending on the
configuration. Ideally I could get all cases working well with triple
buffer but it's hard in practice. At the moment there are two cases
that use overlap instead:
* opensource ATI drives on linux
* windows software renderer
Also added a utility function to check GPU device/os/driver.
the texture would crash because the VBO was still bound. As I
understand it this is not necessarily against the opengl spec,
but might as well unbind it, the driver bug seems to have been
fixed but has not trickled down everywhere yet.
http://bugs.freedesktop.org/show_bug.cgi?id=23859
* Added detection if VBO extension is supported.
* Redraw other 3d views after sculpting.
* Fix brush sometimes punching through mesh with very small polygons,
added an extra epsilon to the ray-triangle intersection.
* Fix#19785: curves not drawing with VBO enabled
* Fix#19553: duplicate Window crashes with VBO's
The convention in Blender was to have GL_VERTEX_ARRAY and GL_NORMAL_ARRAY
enabled by default, and other arrays disabled. The VBO drawing code did
not take this into account. I've made these now disabled by default, since
that makes the code clearer in other places too.
* Multithread parts of multires and subsurf. Only loops working on
face grid data and do no memory allocation have been multithreaded,
others would be more complicated.
* Force some CCGSubsurf functions to be inlined, gives a small overall
speedup in subsurf code.
* Fix sculpting not working correct with transformed objects.
* Fix a few cases of "spikes" on lower level multires levels. There's
still cases where it happens, usually on boundary cornders. The
problem is that in such cases the limit surfaces can be very different
from the low res surface, so the tangent space is very different too..
* Fix crash deleting multires higher levels with level set to 0.
* Fix crashes that happened sometimes when adding faces in editmode.
After testing and feedback, I've decided to slightly modify the way color
management works internally. While the previous method worked well for
rendering, was a smaller transition and had some advantages over this
new method, it was a bit more ambiguous, and was making things difficult
for other areas such as compositing.
This implementation now considers all color data (with only a couple of
exceptions such as brush colors) to be stored in linear RGB color space,
rather than sRGB as previously. This brings it in line with Nuke, which also
operates this way, quite successfully. Color swatches, pickers, color ramp
display are now gamma corrected to display gamma so you can see what
you're doing, but the numbers themselves are considered linear. This
makes understanding blending modes more clear (a 0.5 value on overlay
will not change the result now) as well as making color swatches act more
predictably in the compositor, however bringing over color values from
applications like photoshop or gimp, that operate in a gamma space,
will give identical results.
This commit will convert over existing files saved by earlier 2.5 versions to
work generally the same, though there may be some slight differences with
things like textures. Now that we're set on changing other areas of shading,
this won't be too disruptive overall.
I've made a diagram explaining the pipeline here:
http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png
and some docs here:
http://www.blender.org/development/release-logs/blender-250/color-management/
* PBVH can now be created contain both from face grids or standard
meshes. The former is much quicker to build for high res meshes.
* Moved some drawing code into pbvh (mostly for the frustum test).
* Moved ray intersection code into pbvh.
* GPU buffers also can be built from either mesh or grids now.
* Updated sculpt code to work with this. The ugly part is that there
is now a macro for iterating over vertices, to handle both cases,
and some duplicated code for e.g. undo.
* Smooth brush does not work yet with grids.
GLEW update to version 1.5.1 [11-03-08]
this opens room for Geometry Shader support.
* - Brecht, Campbell told me you did some local changes in order to make it right in Linux. I get to you in order to know what those changes are (or feel free to commit them directly)
* Convert all code to use new functions.
* Branch maintainers may want to skip this commit, and run this
conversion script instead, if they use a lot of math functions
in new code:
http://www.pasteall.org/9052/python
I tried to make it integrate more with regular render but couldn't
do it well, it still needs a 3D view to take the settings from, and
can't run in a separate thread due to OpenGL.
However, it is now rendering to an offscreen buffer which then gets
displayed in the image window. This requires FBO's to be available, so
a fallback creating a new window is still needed. Currently available
from the Render menu in the top header.
