Idea is to replace hard-to-track (id->lib != NULL) 'is linked datablock' check everywhere in Blender
by a macro doing the same thing. This will allow to easily spot those checks in future, and more importantly,
to easily change it (see work done in asset-engine branch).
Note: did not touch to readfile.c, since there most of the time 'id->lib' check actually concerns the pointer,
and not a check whether ID is linked or not. Will have a closer look at it later.
Reviewers: campbellbarton, brecht, sergey
Differential Revision: https://developer.blender.org/D2082
Checking if faces exist was a bottleneck,
use a simpler version of this function for triangles.
Gives approx 1.6x overall speedup (when many edges are being collapsed).
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.
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!
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.
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.
So the error seems to be in cubic_tangent_factor_circle_v3(),
which was introduced with D2001.
I've tweaked the most obvious culprit here - the epsilon factor.
It used to be 10^-7, but I've reduced it down to 10^-5 now,
and it's looking a lot more stable now :)
---------
BTW, about the derivation of the magic 0.390464 factor I briefly subbed back
as a workaround for this bug, see:
http://www.whizkidtech.redprince.net/bezier/circle/
It's probably some numeric precision issue, but until we figure out exactly what's
going wrong here, let's just revert back to the hardcoded value that was used here
successfully for years without issues.
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.
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 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).
A new option for Font/Text objects vertical alignment:
* Top Base-Line (current mode)
* Top
* Center
* Bottom
The Top is the equivalent as the Top-Baseline with an empty line at the begin of the
text. It's nice to have this option too though, since if we are driving
the alignment via Python we don't want to add extra lines to the text
only to accomodate to the desired vertical alignment.
The Center and Bottom are as intuitive as their name suggest.
When working with text boxes, the vertical alignment only work for
paragraphs that are not vertically full.
Many thanks to Campbell Barton (ideasman42 / @campbellbarton) for the
code review, code comments, and overall suggestions and changes :)
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D2061
rB046adde64f16 was actually pretty useless (and broken), since issue ends up not being
in binary search code, but in generation of the 'summed weights' array used to distribute
particles over mesh items - looks like very small weights could lead to null accumulated
weights, wich was breaking binary search.
Fixed simply by adding a minimal, non-zero weight for mesh items to be allowed to emit particles.
Hopefully we are done with this distribution mess!
Some area were still not in sync with readfile.c, now should be better.
Note that readfile.c has been used as référence here re us refcounting,
not sure how accurate it is, time will say :|
Optimization in binary search could lead to equality instead of expected strictly greater than value.
Harmless but noisy, and better be strict here.
reported by sergey on irc (with koro cycles benchmark file), thanks.
The purpose of the patch is to replace deprecated glShadeModel.
To decrease glShadeModel calls I've set GL_SMOOTH by default
Reviewers: merwin, brecht
Reviewed By: brecht
Subscribers: blueprintrandom, Evgeny_Rodygin, AlexKowel, yurikovelenov
Differential Revision: https://developer.blender.org/D1958
