| Age | Commit message (Collapse) | Author |
|---|
|
|
|
already used elsewhere.
|
|
* Change Info in header, put more important info to the left
* API: Move Camera width/height to camera, add some film properties
* Add ESC key to help menu
|
|
* 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
|
|
when using Object or Group render type (since we always use duplicated objects' materials in this case!).
|
|
|
|
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.
|
|
This is very basic for now, but can be extended with more info (available devices for example) later.
Thanks to Bastien and Sergey for some help with the glRect coordinates stuff.
|
|
|
|
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()
|
|
|
|
On Windows we can only do mmap memory allocation up to 4 GB, which causes a
crash when doing very large renders on 64 bit systems with a lot of memory.
As far as I can tell the reason to use mmap is to get around address space
limitation on some 32 bit operating systems, and I can't see a reason to use
it on 64 bit. For the original explanation see here:
http://orange.blender.org/blog/stupid-memory-problems
Fixes T37841.
|
|
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.
|
