Blender 2.78 Release Candidate 2

Hello Blender community, the second release candidate of Blender 2.78 is now available and can be downloaded here:

Here you can read the release notes:

Blender 2.78 Release Notes
and if you find a bug let the developers know in the bug tracker (you’ve to be registered to submit a ticket):

Blender Bug Tracker

Happy blending!

Thank you!


Thank you very much!!

Something is wrong with todays build:
Every render I had is darken. What’s wrong?
On the right is render result and on the left is viewport with 32 sampling.

share your problematic scene… :eyebrowlift: …

… ehm, no problems here

Here it is burnin. Thanks
s2.blend (547 KB)

Something I was curious about if anyone knows: on Linux, is there any reason not to use the glibc219 version rather than the 211 version? I assume that the 211 version exists to support distros based on older versions of glibc?

f12 VS shift+z >>> looks OK here

I tried it multiple times and the same dark render result happens.

If I render with CPU, it’s OK. Only GPU rendering gives such black image.

What gpu do you have?

MSI AMD Radeon HD 7870 2 GB

Oh, could be drivers…
& needs to be tested on another system with AMD card.

Can’t help you here, sorry.

I get the same problem with my amd 390x when enabling experimental.

I get black image on supported GPU render also. Which drivers do you have ? I think there was some drivers related problems in past months.
I have Crimson Edition 16.9.1

does anybody else lost image thumbnails in the file browser
this was fixed in a new buildbot build

This blend seems to crash (hang) the Blender versions I have tried it on. Can anybody confirm?
Steps to reproduce:

  1. Initiate screen render in lower right window with shift+z.
  2. In the material window, switch from radial mode to UV map.
    Instant hang, the selection doesn’t even update. If render was not initialized, Blender will allow switching to UV based, but will hang once you start rendering.

CPU/GPU doesn’t matter. Something went kind of awry when I made of the “lamps”, in that when I enabled subsurf (>0) some faces just wouldn’t show up. Normals seemed okay, no doubles, everything unhid, no verts seemed loose, and I could select and move the face. I had to delete a few loops and recreate them to get it back. That’s the first time that has ever happened to me (I build it on the Disney version, not sure if it matters), and I’ve had no issues before using UV based tangents. That’s no guarantee though that I didn’t mess up this time.

Both objects was previously operated like this:

  1. Part of tube was separated to own object.
  2. Merged loops to form single points, points merged.
  3. Converted the mesh (now basically a curve of vertices) to a curve object.
  4. Reshaped, points added, smoothed etc.
  5. Added thickness to it and converted back to mesh.
  6. Merged with object it came from.
  7. UV Unwrapped to form a nice square suitable for UV tangents.
  8. Added subsurf (not 100% sure I did it here of if it existed beforehand). Now I noted the missing part and fixed that.

The converting mesh->curve->edit&refine->mesh process has caused frequent crashes, and also did it this time. On next restart everything seem normal again and conversion process will work. I believe the full mesh isn’t UV unwrapped, but it would still crash if I select all and did a simple unwrap.

Can anybody confirm?

@aermartin: Both blends and textures show thumbnails when I enable it. Didn’t try anything else.

^ can confirm
looks as never-ending loop - blender becomes unresponsive while WTM show process runs on CPU / single core :spin:

thumbnails are still here - on win check> “c:\Users\username.thumbnails”

Not just experimental with GPU. But also with experimental with CPU. Did it with BMW27.blend(benchmark blend). Maybe it’s just not backwards compatible??

EDIT: Enabled with adaptive subdiv too

Edit 2: It seems when enabling adaptive subdiv the highlight disappear.

Edit 3: Disabling the bump texture makes the highlight works again in the scene.

Do you compile yourself ? Try this patch:

diff --git a/intern/mikktspace/mikktspace.c b/intern/mikktspace/mikktspace.c
index 7e5861e..ca398b1 100644
--- a/intern/mikktspace/mikktspace.c
+++ b/intern/mikktspace/mikktspace.c
@@ -680,7 +680,7 @@ static void MergeVertsFast(int piTriList_in_and_out[], STmpVert pTmpVert[], cons
                // only need to weld when there is more than 1 instance of the (x,y,z)
                if (iL_in < iR)
                        MergeVertsFast(piTriList_in_and_out, pTmpVert, pContext, iL_in, iR);    // weld all left of fSep
-               if (iL < iR_in)
+               if (iL && iL < iR_in)
                        MergeVertsFast(piTriList_in_and_out, pTmpVert, pContext, iL, iR_in);    // weld all right of (or equal to)

This fixes the crash/hang, post an bugreport anyway pls.


Bug has been reported and confirmed, but as suspected it is the mesh itself that had issues from the way it was edited (NaN vertices apparently). I didn’t know you could even spot it as Brecht kindly points out. Probably hard to reproduce the events that lead to the mesh, but how would I go about fixing a mesh with NaN verts? As mentioned I had a situation where some faces would not show where everything else (that I know of) appeared normal, and I had to delete some loops and recreate them.