Two were actual bugs, though they existed only in unused code:
* In Freestyle it was unintentionally copying a scene rather than referencing it.
* In BLI_array_store_is_valid there was use of uninitialized memory.
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
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... :(
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.
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..
The Curves widget has buttons to zoom in on the curve. However the
click detection code doesn't take it into account, and at full zoom
in click on curve is detected very far from the actual visible curve.
Change it to compare the position to the actual line segments
in the UI coordinate space, i.e. with curve zoom applied.
changes in BLI_kdopbvh:
- `BLI_bvhtree_find_nearest_to_ray` now takes is_ray_normalized and scale argument.
- `BLI_bvhtree_find_nearest_to_ray_angle` has been added (use for perspective view).
changes in BLI_bvhutils:
- `bvhtree_from_editmesh_edges_ex` was added.
changes in math_geom:
- `dist_squared_ray_to_seg_v3` was added.
other changes:
- `do_ray_start_correction` is no longer necessary to snap to verts.
- the way in which the test of depth was done before is being simulated in callbacks.
Regression caused by own changes to make texture paint more efficient
from workflow point of view.
Now the idea is to use vertex color outside of paint mode, so we don't
break any compatibility here.
Remapping indirect usage of IDs is forbidden from user space, this is calling for
nice nightmare with libraries handling (and undo crash, among other things).
Not sure why I was 'laxist' about indirect usage cases detection like that,
for now just consider any ID used by another linked datablock as indirect usage case!
Also, added some error/warning reports to Outliner's remap code.
The "W" channel will get a yellowish colour (i.e. a blend between the X/R and
Y/G axis colours), while the XYZ will behave as they do for other transforms.
The create drivers operator should not use the "Transform Channel" variable type
when driving one transform with another on the same object/bone. Otherwise, you
end up with a situation which technically results in a bit of a pseudo-dependency
cycle.
The Ctrl-Shift-C operator to add constraints between a pair of selected items,
for example, between two objects, or between two bones (in the same armature).
This commit makes it possible to use this operator to add a constraint where the
target is a bone from another object - e.g. to make a deform bone follow the control
bone in another armature, or to make an object use a bone as a tracking target.
Usage:
1) Ensure you are in Pose Mode, then select the bone to use as the target
2) Shift-Select the other object and/or the bone that's going to get the constraint
3) Ctrl-Shift-C
Problem was in fact slightly wider, File space was nearly not taking into account
library navigation case and its 'virtual' directoris, except in a few places.
Add a wrapper around BLI_is_dir that also check for lib paths, and used it in
ED_file_change_dir(), such that we now always check path is a
valid directory - in the filebrowser context, not filesytem context. ;)
To get this working the least effort, I've had to expose the helper functions
used by the lasso and circle select keyframe-test callbacks (which are generic)
and expose them for use by the GP keyframe editing code too. Hopefully in time
we clean this all up and just write the code once to operate on "keyframes"
This only works in the Action and Dopesheet modes (which operate on FCurve keyframes).
Support for Grease Pencil and Mask Keyframes though is still pending.
This new operator will delete any GP frame it finds on the current frame, regardless
of whether it's on the active layer or not. It will only remove the frames if the
layer is editable, but otherwise, it will just go for it.
The existing operator is great for use in the panel (where it only applies to the active
frame), but it was not so good for all the other places where tools can be invoked
(e.g. D-X, or Delete) as you're typically thinking about the whole scene more holisticaly
than just caring about a particular layer.
Replaces `G.is_rendering` with `use_render_params` argument.
This is needed for Cycles, which attempts to restore render-preview settings from particles,
after it gets its own particle data, but fails to restore because
`G.is_rendering` was being checked in psys_cache_paths (and other places).
This commit adds operators and Outliner menu entries to reload or relocate a library,
and to delete or replace a datablock.
RNA ID API is also extended to allow ID deletion and remapping from python.
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
Getting a new edit-derived-bmesh was always creating a deform-vert array, even when it wasn't needed.
Since this was called on redraw, in many cases it was doing it unnecessarily.
Now pass in a custom-data mask and only fill in deform-verts when needed.
Gives noticeable drawing speedup (~10-30% here).
