Age | Commit message (Collapse) | Author |
|
exposes many incorrect and redundant stubs
|
|
|
|
only in "Material" viewport shading.
|
|
So now it's possible to copy-paste splines between layers.
Implementation is pretty much straightforward and duplicates
some logic which we've got in sequencer/tracking clipboards.
Will work on a common routine for clipboards later, for now
it's not so much crucial to have.
|
|
|
|
|
|
Patch D160, by Scott Petrovic with own modifications.
|
|
Changed curve active point from pointer to index. Allows curve active point to be saved to file and retained between modes for free. Also some small optimisations by removing pointer look up code.
- Made active point access functions into BKE API calls.
- Fixes operators where curve de-selection resulted in unsel-active point.
- Split curve delete into 2 functions
|
|
|
|
Found three cases where created bvhtree was not freed...
|
|
Don't assume all objects have a valid animdata...
|
|
Factorized a bit the code here, think it's more readable now... No performance enhancement though.
Reviewed by: campbellbarton
Differential Revision: https://developer.blender.org/D259
|
|
|
|
* 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.
|
|
Differential Revision: https://developer.blender.org/D248
|
|
|
|
Reflects previous commit that now allows this group to
control edge bevels too.
|
|
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).
|
|
FBX expect full bitangents, better to compute them in C than in python...)
|
|
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.
|
|
|
|
Did one tried building blender before commit even?
|
|
Reviewed By: moguri, kupoman
Differential Revision: https://developer.blender.org/D167
|
|
Hopefully this time all mismatches are fixed (quickly checked the whole BMesh API files,
found a few others in addition to those reported in T38150).
|
|
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.
|
|
its parent
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.
|
|
mode.
Only when in weight paint mode should it check the selected vertices and faces,
in object mode it should just affect the entire mesh.
|
|
to true/false in code using them).
|
|
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
|
|
After some investigation with mont29, seems like the best way to ensure
keymaps point to valid operators is using WM_keyconfig_update().
|
|
|
|
cases
Own stupid typo in rB28ca299d4dfc...
|
|
|
|
|
|
|
|
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.
|
|
Currently it's not supported to do viewport render of particles while in
particle edit mode, hide the particle instead of rendering halos.
|
|
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.
|
|
This would show as a line on the side of the 3D view with high DPI / retina,
not easy to notice.
|