While it's not something we'll be using for the official release,
it's nice to support new libraries at least on "it compiles" level,
so it's not that many frustrated developers around.
Nexyon, please have a look into Audaspace changes :)
BKE_main_id_tag_/BKE_main_id_flag_ were horrible naming now that we split those
into flags (for presistent one) and tags (for runtime ones).
Got rid of previous 'tag_' functions behavior (those who were dedicated shortcuts
to set/clear LIB_TAG_DOIT), so now '_tag_' functions affect tags, and '_flag_'
functions affect flags.
This made byte & float images behave differently, where other modifiers remain the same.
Also remove scene from the modifier (should have been passed as arg but no longer needed).
Python name could include ABI-flags after the version,
since checking for all combinations of ABI flags can expand into many possibilities,
take the executable name from the build system.
On undo, sculpting regular meshes would update _all_ GPU VBO's.
Avoiding the update gives noticeably faster undo.
This is also a fix/workaround for strange behavior with NVidia's driver (T47232),
Where locking and unlocking all buffers for updating
slows down redraw speed permanently after the first undo.
However the problem isn't avoided entirely since a single brush stroke might modify most of the mesh.
When pasting text, the style (bold, material, ...) is maintained, if it was originally copied from Blender.
This fixes the issue of missing copy/paste options for font objects
(they were present back in Blender 2.49)
Reviewers: Severin, campbellbarton, brecht
Really annoying bug, the code was not forward compatible at all and
resulted in crash. And it is really good to keep at least one release
forward compatibility so possible regressions could be verified easily.
The idea now is to use new property name for the pixel filter type,
but keep old property around for a couple of releases, so we have at
least some forward compatibility.
Don't like this situation at all, but seems it's least of the evil
we can choose.
Thanks Brecht for the review!
* Added a new API function to test if a GPencil layer is visible or not
* Replaced all editability checks with this new "super check"
* Replaced all magic number thresholds for opacity visiblity with a single define
Corrects mirror syncing for invert, levels & smooth.
Note that the code changed to process mirroring even if both verts are selected,
since group flipping can mean that is still meaningful.
The bake system had a 200ms sleep for each frame substep, to give the UI time
to redraw. I don't think there is a good reason to have this, with fair thread
scheduling this will give UI thread 2x more time at best, and the UI doesn't
need to be that responsive during bake.
This change the following values:
- World settings:
- Use MIS: On
- MIS Samples: 1
- MIS Resolution: 1024
Enabling World MIS per default won't make simple backgrounds (flat background color) slower,
see previous commit. This gets disabled internally if World MIS is not actually needed.
Issue was caused by update RNA callbacks freeing the dependency
graph, which is only needed to tag depsgraph for rebuild.
Solved by using a flag for the depsgraph which indicated that it
is to be rebuilt.
The issue was caused by fix for 31017 which resulted in some
missing intersecitons recorded which screwed inner/outer checks.
This is an old bug, so didn't bother with forcing re-distribution
to happen on file open to avoid possible other regressions.
Such configuration used to cause quite confusing situation when
stamp will use actual scene's statistics but metadata from strip
will be used for the saved file (basically, causing different
information stamped and saved as metadata).
Don't think it was desired behavior and it's something what
artists here in the studio wants to be fixed.
This way it's possible to have some color-correction modifications on
top of the render result and yet still have proper metadata stored.
Usecase: Access per-frame render-time of the movie frames from the
final export.
That was the main issue (in both T46455 and T46690), solved by 'flattening' those chains (v1 -> v2 ->v3 etc.)
before calling `CDDM_merge_verts()`.
Also added note to `CDDM_merge_verts()` that it does not support chained mapping, along with
a basic assert that should catch most of those cases in future.
The logic of 'following mapping' was also rather broken, making a special case here when using
object-controlled offset is very weak. Further more, blindly following mapping in this case
was far from ideal, this could end to merging vertices rather far from each other.
To address this issue, we now always follow mapping, but only as long as 'final' vertex remains
close enough from mapped one.
Finally, the search of 'closest' vertex to merge with was also quite bad, would just pick the first
one matching distance limit, instead of using the actual closest one - could lead to rather ugly
geometry deformations in case one would use not-so-small merge threashold!
Seems i was the only one who was really up to using it and
i do have gcc-5 finally backported and installed here so
such a fine-tune flags are no longer needed.
Should be the last bit of sculpt/paint code, now this is fully using BLI_task.
Note that PBVH normals update is now about 20% quicker than with OMP code
(from 27ms to 21ms with a big stroke over a 500k vertices monkey), even though
a missing thread-protection was added... atomic primitives ftw!
For the records, with the missing `#pragma omp critical` section added,
previous code was like four times slower (above 100ms).
Issue was that the domain matrix was not initialized properly on the
first frame (in smokeModifier_init), which caused OpenVDB to throw an
exception for trying to create a VDB grid with non-affine transform.
This patch supports "Image or Movie" and "Environment map" types of world texture for the viewport.
It supports:
- "View", "AngMap" and "Equirectangular" types of mapping.
- Different types of texture blending (according to BI world render).
- Same color blending as when it lacked textures (but render via glsl).
{F207734}
{F207735}
Example: {F275180}
Original author: @valentin_b4w
Regards,
Alexander (Blend4Web Team).
Reviewers: sergey, valentin_b4w, brecht, merwin
Reviewed By: merwin
Subscribers: campbellbarton, merwin, blueprintrandom, youle, a.romanov, yurikovelenov, AlexKowel, Evgeny_Rodygin
Projects: #rendering, #opengl_gfx, #bf_blender:_next
Differential Revision: https://developer.blender.org/D1414
Not so useful now that we use BLI_task! Not sure why those were ever added actually,
readng carefully that code only modified data here is the PBVHNode, which is only
used/affected by one thread at a time ever. And shared read data (PBVH itself) is
not modified during brush execution itself, so it's safe to use it threaded too.
