This is a regression introduced by rBd8b00a3bf5c1 (Freestyle: memory
consumption optimization in stroke rendering).
The issue was caused by uninitialized MPoly::mat_nr values. Before the
stroke rendering optimization, individual Freestyle strokes were
represented by distinct mesh objects, and thus MPoly::mat_nr was left
unset (i.e., was always zero). Now that the stroke rendering optimization
has been done and mesh objects may represent multiple strokes of different
materials, MPoly::mat_nr had to be properly set to the material index that
refers to the material of the poly face.
Now we have an helper that will generate local/global paths and ensure they are valid.
Note: We currently have no way to 'generate' a valid extension in these cases, so just
using raw (file-safe) ID name.
screen.
Apparently the screen on the given file did not have a scene attached.
Not sure how this is possible exactly, but for now just guard against it
at load time by assigning default scene in that case.
It was only happening on 32bit platforms because of alignment
differences when allocating class.
Now got rid of copy of eigen matricies stored by value in the
residual block which solves aligment issues and should also
give some unmeasurable speedup.
This patch make it possible to export and import shadeless material.
Reviewers: sergey, sauraedron
Subscribers: sergey
Projects: #collada
Differential Revision: https://developer.blender.org/D1094
The issue was caused by AO operation reporting it's a color operation
(which means it's expected to output RGBA) but internally it's RGB
only in the render engine, which caused some memory to be uninitialized.
The issue was caused by numerical instability whrn having ray origin close to a huge
triangle, which could have aused bad ray distance check.
Watertight Woop intersection isn't really addressing such cases, it's dealing with
small triangles far away from the ray origin instead, so it's a bit tricky yo make
it working reliably.
While we're quite close to the release it's safer to do check in Pleaucker coordinates
if ray close to a huge triangle. Likely this additional check combined with some other
tweaks to the code doesn't cause measurable slowdown in the scenes tested here.
After the release we can play a bit more with this code in order to make it more
stable without Pleucker fallback.
Blender allows you to create a constraint without specifying its reference
object, even when the constraint requires such a reference. The BGE would
crash on this. This change simply ignores such a constraint.
