* EXR layers with names like 'Z' without any pass name were not loaded at all
and would break the Combined pass as well.
* EXR pass names longer than 16 characters where writing past the end of the
array and getting invalid names.
Until now, the "vertex group" limit method in the modifier
only worked for "vertex only" bevels. With this change,
edges with both ends in a vertex group will be beveled
in the non-"vertex only" case.
Also changed the test for being in a vertex group from
"any nonzero weight" to "weight >= 0.5". This is because
cascaded bevels on disjoint vertex groups did not give
disjoint bevels, because weight interpolation would give
non-zero weights to newly created vertices in earlier bevels.
Chose 0.5 because that won't result from interpolation, but
still allows some dilution (e.g., cascaded bevels on the
same vertex group).
libraries view not working.
This was disabled in the operator, there may have been a reason for this at
some point, but I can't see any reason to disallow it in the current code or
find a good reason why it was done in the commit logs.
The method for calculating points on the profile for non-circles
and non-lines meant that the segments making up an edge had
uneven widths.
Use a numeric search technique to find superellipse evaluation
points that lead to equal-sized chords across the profile.
Also calculate the actual profile points sooner, so that they
don't have to be recalculated again and again.
This also sets up for a possible later feature of arbitrary
profile shapes, set by user.
Previously the divider was using the region background and the region text, leading to bad outlines with custom themes. This makes the outline behave more expectedly and allows better control.
This is rather a workaround which only works because curve evaluation is only called
for a temporary object. Not a big deal if we'll skip path creation for such objects.
Still would need to think of general solution.
For example for vector displacement, you may have an EXR texture that has
negative colors values. Blender clamps these by default, now the Colors panel
for textures has a Clamp option to disable this clamping.
This option affects all texture types and is enabled by default, you need
to disable it if you want negative values to have an influence.
Patch by Fredrik Hansson with modifications by me.
it is possible that different windows shares scene but displays different
layers. And it's also possible that different areas in the same window will
show different layers.
First case was violated in `dag_current_scene_layers()` which only checked
scene layers only once and if multiple windows shares the same scene only
one window was handled. Now made it so layers from all windows will be
squashed together into a single `DagSceneLayer`. This mainly solves issue
with `DAG_on_visible_update()` which didn't work reliable with multiple
open windows.
Second case required call of `DAG_on_visible_update()` when changing space
are type.
This commit slows things a bit actually because `dag_current_scene_layers()`
is actually called on every main WM loop iteration. It is possible to speed
some logic up perhaps. Not sure it's so much critical to do now because there
are unlikely to be more than few windows open anyway.
Will rather think of skipping all that flushing things if no objects are
tagged for update actually.
- Made them receive number of channels rather than number of planes.
This matches to how ImBuf structure stored planes and channels.
- IMB_premultiply_rect_float() was called with channels passed instead
of planes already :S.
Issue is caused by the race condition between getting custom data layers
from target's derived mesh (for vertices and faces) and releasing this
derived mesh from other threads.
When one releases the derived mesh it'll free temporary data from it,
and it'll also update data layers mapping.
General rule for threading is that no one is ever allowed to modify
data he doesn't own. This means that no temp layers are to be allocated
in derived mesh and making it so `CustomData_free_temporary()` doesn't
update mapping if nothing was freed will solve the race condition.
It is still possible to do other improvements, namely detect which
additional data/layers are to be present in derived mesh and create
it as a part of `object_handle_update()`, but this is to be solved
separately.
This was storing the original object matrix, which builds on the
assumption that obmat is modified during dupli construction, which is a
bad hack.
Now the obmats are still modified, but this only happens outside of the
dupli system itself and the original ("omat") is stored as local
variables in the same place where the obmat manipulation takes place.
This is easier to follow and avoids hidden hacks as much as possible.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D254
patch D234 from Jonathan Williamson with edits
- de-duplicate rna_def_userdef_theme_space_gradient and rna_def_userdef_theme_space_generic
- ui_theme_init_new_do now always sets theme settings (no need to test),
used by bpy.ops.ui.reset_default_theme()
Own bug from rBc691551249f3. Now at least I understand why `test_index_face()` is needed for tessellated quads!
Added a bunch of comments to explain the issue, as it's far from an obvious one...
We loose some performances, but it's still much quicker than org code.
Issue was caused by curve object really scale up. It was
caused by 677f519 to make scaled down curves work fine.
After some tweaks to epsilon value scaled up curves seems
to work as well.
Issue was caused by wrong PTS calculation. This commit
makes this calculation closer to what's happening in
FFmpeg itself.
Seems everything is working now including newer FFmpeg,
but there's one thing which still doesn't work: writing
avi files with h264 codec and Vorbis audio doesn't play
correct in mplayer here. But didn't manage to get this
working even using FFmpeg CLI, so this might be just a
bug in FFmpeg/mplayer. Since this file works fine in
blender just fine wouldn't consider this is crucial thing
to look into at this moment.
(@plasmasolutions): When the particle emitter is parented to a fast
moving object, the emission locations will not be interpolated over
subframes. This works if the particle emitter is animated itself.
Particle system evaluates the emitter location for each subframe, but
has to do this for the parent objects as well to get reliable results.
The area-of-interest calculation for that node didn't work reliably.
It tries to estimate the distorted rectangular area based on min/max
distortion and dispersion values, but this fails in some cases and
leaves uninitialized buffer chunks. So now simply use the full input
rect as the area, even though it may not be as efficient - at least it
works ...
Also cleaned up the code somewhat to make it understandable, using
separate functions for common stuff instead of cryptic walls of math.
FileGlobal structure in write_global() didn't initialize
the while build_hash property and only placed there null
terminated meaningful content, leaving trailing uninitialized.
This made valgrind complain about using uninitialized memory
later in undo stack.
Evaluating the animation is causing the object to get tagged as changed, but in
this case it's not a permanent change so no one should be notified. Also found
a case where the persistent ID for duplis wasn't unique, fixed that as well.
The main idea is to store (during tessellation) or recreate (during tessdata update) a tessfaceverts-to-loops mapping, and then update all tessdata
in one pass, instead of calling `BKE_mesh_loops_to_mface_corners` repeatedly for all tfaces!
Differential Revision: https://developer.blender.org/D226
Reviewed by Campbell, thanks a lot!
Ref: http://en.wikipedia.org/wiki/XOR_swap_algorithm, modern compilers/CPUs are much more efficient with "naive" algo than XOR one.
Doubled check, for me in an optimized build, XOR is several times slower than naive algo.
It was using the modified mesh for the vertex coordinates, and the unmodified mesh
for the vertex weights, which can't work and crashed in some cases, now it used the
modified mesh for both.
Perhaps an option should be added to indicate if you want to transfer from the
unmodified mesh or transfer to the modified mesh, but I think this fix makes it
works as intended when this was implemented.
