Blender Git Commits

And one more fix to particle distribution!

As pointed by Brecht, previous fix in rB61b49de44940 was actually incomplete,
we could still hit float rounding issue and hence same value in more than one consecutive
items of element_sum.

New solution is a bit different, we remove the 'minimal weight' check, and rather simply
ignores an item when the sum of its normalized weight to previous item's sum does not add
anything. Shall be safe and 100% effective this time!

Fix bmesh test after recent refactor.

BI Viewport(GLSL): support for envmap in Texture node

This patch is another step to achieve BI and it's Viewport consistency for cubemap textures.
{F318879}

To test world_space_shading flag D2072 is required.

Alexander (Blend4Web Team)

Reviewers: campbellbarton, brecht

Subscribers: homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov

Differential Revision: https://developer.blender.org/D2074

Fix input for Texture node (envmap+world_space_shading)

This patch fixes shortcoming of D2046.
The original behavior without world_space_shading flag is that Texture node expects the reflected vector in view space. But with world_space_shading it should be in world space.

In attached file you will see a simple material setup and a node material analogue.

Simple material must have the same behavior regardless world_space_shading flag.

{F318866}

Alexander (Blend4Web Team)

Reviewers: brecht

Reviewed By: brecht

Subscribers: campbellbarton, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov

Differential Revision: https://developer.blender.org/D2072

Environment lighting for the GLSL mode

Environment lighting (aka ambient) is a key component of any renderer.
It's implemented like the Environment lighting of BI render for Approximate Gather mode. It support "Sky Color" and "White" Environment lighting modes.

It would be great if the user could see actual lighting conditions right in the Blender viewport instead of waiting for the renderer to complete the final image, exporting for external renderer or for a game engine.

Before:
{F113921}

After:
{F113922}

Example file: {F319013}

Original author: valentin_b4w

Alexander (Blend4Web Team)

Reviewers: valentin_b4w, campbellbarton, merwin, brecht

Reviewed By: brecht

Subscribers: panzergame, youle, duarteframos, AlexKowel, yurikovelenov, dingto, Evgeny_Rodygin

Projects: #rendering, #opengl_gfx

Differential Revision: https://developer.blender.org/D810

Quiet warnings w/ USE_VERIFY define

Curve: utility to evaluate entire curve

Update pacman pkgbuild

Fix T48783: OSL render errors after recent refactoring.

Fix use of uninitialized variable in Cycles OpenCL image textures.

Fix typo in bgl.Buffer report function

A GL_INT buffer was reported as GL_BYTE.

Install Deps: Use OSL 1.7.3, latest bugfix release.

Correction for MSVC

BMesh: utility function to resize bmesh elements

This can be used to re-allocate bmesh data with/without tool flags.
Needed for Symmetrize since it uses bmesh operators from dyntopo.

Cleanup: comment blocks

Cleanup: style

Fix Cycles OpenCL not taking Extend and Clip extension types into account.

(See T48720).

"Fix" crash when deleting linked object which has indirect usages.

This is in fact very hairy situation here... Objects are only refcounted by scenes,
any other usage is 'free', which means once all object instanciations are gone Blender
considers it can delete it.

There is a trap here though: indirect usages. Typically, we should never modify linked data
(because it is essencially useless, changes would be ignored and ost on next reload or
even undo/redo). This means indirect usages are not affected by default 'safe' remapping/unlinking.

For unlinking preceeding deletion however, this is not acceptable - we are likely to end with
a zero-user ID (aka deletable one) which is still actually used by other linked data.

Solution choosen here is double:
I) From 'user-space' (i.e. outliner, operators...), we check for cases where deleting datablocks
should not be allowed (indirect data or indirectly used data), and abort (with report) if needed.
II) From 'lower' level (BKE_library_remap and RNA), we also unlink from linked data,
which makes actual deletion possible and safe.

Note that with previous behavior (2.77 one), linked object would be deleted, including from linked data -
but then, once file is saved and reloaded, indirect usage would link back the deleted object,
without any instanciation in scene, which made it somehow virtual and unreachable...

With new behavior, this is no more possible, but on the other hand it means that in situations of dependency cycles
(two linked objects using each other), linked objects become impossible to delete (from user space).

Not sure what's best here, behavior with those corner cases of library linking is very poorly defined... :(

Outliner: pass operator's reports to all operation callbacks.

Also define single callback func typedef, cleaner this way!

Note: maybe we want to do that for the other callbacks too (data, etc.), but will be enough for now.

Fix T48666: Segfault on boolean operation when exiting edit mode of instanced operand

This is quite tricky situation which combined:

- Boolean modifier which accesses other object's derived mesh
(in fact, it's nothing to do with boolean modifier, any other
modifier which uses other's DM will have same bug).

- Dependency cycles in the scene which is rather russian-roulette
from the cycle solver point of view.

- Multiple instanced objects used as boolean operand.

With all this things combined boolean modifier was accessing operand's derived
mesh which was referencing data from Mesh datablock. The issue is that those
references are becoming invalid after EDBM_mesh_load().

This function already had code to make sure object itself does not end up with
dangling pointers from derived mesh. Make it now so no possible instanced objects
are left with dangling pointers.

And who said it's a good idea to reference something from derived mesh..