Cannot reproduce the issue here on linux, but have the feeling windows builds are much
more easily broken with referencing bad data from bpy. So here guessing direct loop
over bpy.data.xxx when you do add and remove stuff from said xxx inside the loop
is not a good idea - which seems logical in the end. :P
was enabled.
Caused by an -unneeded now- fix for opensubdiv. Code caused the vertex
colors to be uninitialized. Thanks to Sergey for confirming that initial
issue is no longer a problem.
- wasn't checking subframe to see if the scene needed to be re-evaluated.
- unneeded int/float conversion storing original frame.
- moved cleanup block into one place to avoid confusion.
Basically filtering was happening twice, first time by applying weights of EWA
filter itself and then by applying subpixel offset while reading pixel values.
Primary goal of this commit is to fix an annoying issue - when processing and saving .blend
files in background mode you lose their thumbnails, since it can only be generated with
an OpenGL context.
Solution to that is to read .blend thumbnail while reading .blend file (only done in background
mode currently), and store it in Main struct.
Also, this lead to removing .blend file reading code from thumb_blend (no need to have doublons).
We now have a small interface in regular reading code area, which keeps it reasonbaly light
by only reading/parsing header info, and first few BHead blocks.
This makes code reading .blend thumbnail about 3 to 4 times slower than previous highly specialized
one in blend_thumb.c, but overall thumbnail generation of a big .blend files folder only grows
of about 1%, think we can bare with it.
Finally, since thumbnail is now optionally stored in Main struct, it makes it easy to allow user
to define their own custom one (instead of auto-generated one). RNA API for this was not added though,
accessing that kind of .blend meta-data has to be rethought a bit on a bigger level first.
Reviewers: sergey, campbellbarton
Subscribers: Severin, psy-fi
Differential Revision: https://developer.blender.org/D1469
Issue was caused by blender internal accessing data from DNA during rendering.
There's no simple solution to make stuff thread safe, so for now simply restart
rendering on frame update.
The issue was caused by uninitialized ray used for composite and AO evaluation.
Can;t really think of "proper" ray configuration here, it's all a bit arbitrary
but think initializing the ray in a way so we look at the surface in a negative
normal direction is much better alternative to uninitialized ray.
Open for alternative suggestions tho.
This is more like a workaround to prevent obvious cases fail, but in theory
if some other area will start updating object for subframes blender will
crash again.
Perhaps proper way to solve this will be to copy objects for subframe updates.
The issue was in fact caused by both preview and viewport renderers affecting
on the default material, conflicting with each other.
Preview render doesn't really need default material, so we can safely skip it's
initialization in the render pipeline for preview rendering.
Don't force re-distribution of cached particle systems, this doesn't
cause actual evaluation of particles and there was a reason why particles
are baked actually..
This isn't a Blender issue and the same bug happens with official OpenSubdiv
examples. For until it's either worked around from OpenSubdiv side or fixed
in the driver we'll force disable GLSL Compute for AMD hardware.
Uniform block data layout was different on CPU and GPU which caused wrong
data being used from shader.
In theory using layout(std140) is what we need to do, but for some reason
such layout specifier is being ignored. This is probably caused by the way
how we exploit extensions from older version of glsl.
For until we've upgraded our glsl pipeline used different approach which
is basically about removing unused fields form the struct manual in hope
that it'll keep memory layout consistent for both CPU and GPU.
This seems to work so far for both NVidia GTX580 and AMD FirePro W8000
here in the studio.
