This is not limited to normal maps, it's just that normal maps cause a
mix of interleaved vertex arrays + non interleaved vertex arrays + GLSL,
which could confuse the GL. Possible explanation is that it may be
clobbering the vertex index of the shader somehow but this is difficult
to know without extensive tests and the Mac is needed by Francesco in
the morning :).
Do brute force solution instead, just force legacy drawing on Macs when
VBOs is off. On the plus side VBOs work fine, so we should be fine when
we update.
Issue was caused by b62c2a9 and root of it goes to the fact that text
info is stored in the "main" scene, not the currently rendering one.
This is a bit annoying but making it so text and result are coming
from the same scene is a bit dangerous to do now. Will re-visit this
change after the release and see if it might be done in a more clear
fashion.
The smoke obstacle detection was using a maximum distance for BVH
checks to find mesh elements that define boundary cells in the grid.
This BVH test was using an arbitrary value of 0.6 cell units. It should
be `sqrt(3)*0.5` to account for the maximum possible distance of mesh
elements inside a cell. Otherwise some cells that should form the
boundary are not detected as such (no closest mesh element found inside
the radius), so you get gaps in the smoke obstacle.
The issue seems to be caused by the integer overflow. It's actually
still needed to investigate why exactly buffer contained such a huge
value, but the patch is still legit and seems to be solving the issue
just nicely.
This was a regression caused by attempts to fix T42844 and there were
some red-herrings which lead me to the wrong way to fix it. It's some
deeper issue than just interpolation offset, it's mainly how the node
resolution is being mapped to each other.
It could be actually a part of canvas awareness project..
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.
