Handle sequences in a special case for dealing with
sequence sources.
Namely handle separate frames in separate threads,
but do disk read from a critical section since HDD
is not so friendly with lots threads requesting for
data from it.
Makes proxy building much faster than it was before.
This commit implements multi-threaded calculation of frames
when building proxies. Both scaling and undistortion steps
are now threaded.
Frames and proxy resolution are still handled one-by-one,
saving files after every single step. So if HDD is not so
fast, this commit could have not so much benefit.
Internal changes:
- Added IMB_scaleImBuf_threaded which scales given image
buffer in multiple threads and uses bilinear filtering.
- libmv's camera intrinsics now have SetThreads() method
which is used to specify how many OpenMP threads to use
for buffer distortion/undistortion.
And yeah, this code is using OpenMP for threading.
- Reshuffled a bit libmv-capi calls and added function
BKE_tracking_distortion_set_threads to specify number
of threads used by intrinscis.
use mpolys instead and simplify checks for wire edges.
Also rename BKE_mesh_from_curve() --> BKE_mesh_to_curve() since this function converts a mesh into a curve.
I've added a separate camera unit type. It's a bit strange to have an exception for
this but it ensures units are shown in familiar millimeters and it also ensures
backwards compatibility.
The previous implementation of Freestyle edge/face marks was refactored
based on suggestions from the latest code review by Campbell. The new
implementation relies on mesh CustomData to store edge/face marks, instead
of introducing extra flags in the core Mesh and BMesh data structures.
The CustomData-based implementation will allow further additions of new
edge/face attributes because of the independence from Mesh/BMesh.
This revision is work in progress, mainly intended to address the review
comments and ask for further code review in view of the trunk merger in
the upcoming 2.67 release.
ALERT! POSSIBLE BREAKING COMMIT, ESPECIALLY FOR SCULPT!
Separate the sculpt sampling function so that it can be reused
from other paint systems. This includes updating of the relevant
coordinates for anchored and rake style brushes, which are now
being updated as part of the stroke system.
I left only code for area-style brush texture mapping in sculpt
code, since it requires a few data structures not present on other
paint systems.
This commit makes it almost as easy to support rake on other systems as
exposing the python UI for it. Also it makes it totally possible to
have texture painting capabilities in vertex paint too :) These commits
will follow very soon.
Also, even if I did my best to keep the code from breaking, (even fixed a
leftover bug from coordinate changes) this is a big change. Please test!
Patch by Jehan Pages (pardon for mis-typing, emacs-nox works not so good with
urf-8 buffers here), with some own modifications. Thanks!
From the patch tracker:
The problem is because of several versions of ffmpeg, but even more because of
the fork situation libav/ffmpeg. So there are some installed versions out there
where you *must* use a float sample for some codec; whereas oppositely on some
other installations, you *must* use the int sample. So for some people, one
works not the other, and reciprocally.
As a consequence, you can't just have a switch codec-based, like in current
code, which decides on the float or int implementation, you must necessarily
have a runtime test because you won't know until then if ogg vorbis will use
one or another sample (note: that's true also for AC3 as I fixed the exact same
bug in DVDStyler for AC3 encoding a few months ago; and I guess it would be same
for AAC).
Some notes from self:
- New FFmpeg requires using FLTP for AAC, AC3 and Vorbis, it's not supported
by audaspace and result in this case would be just wrong. Throw an error
in cases FLTP is trying to be used.
- Moved strict_std_compliance a bit upper. When we'll support FLTP both
FLT and FLTP for AAC would need to be using FF_COMPLIANCE_EXPERIMENTAL.
- It is nice to have such check of supported by codec formats anyway.
Dudes, please try building blender with all default features
before doing such a commits. It helps just a lot when bisecting
issues later.
Also solved const qualifier discard happens in recent monofont
commit.
This patch allows Blender to display i18n monospace font in the text
editor and the Python interactive console. Wide characters that occupy
multiple columns such as CJK characters can be displayed correctly.
Furthermore, wrapping, selection, suggestion, cursor drawing, and
syntax highlighting should work.
Also fixes a bug [#34543]: In Text Editor false color in comment on cyrillic
To estimate how many columns each character occupies, this patch uses
wcwidth.c written by Markus Kuhn and distributed under MIT-style license:
http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c
wcwidth.c is stored in extern/wcwidth and used as a static library.
This patch adds new API to blenfont, blenlib and blenkernel:
BLF_get_unifont_mono()
BLF_free_unifont_mono()
BLF_draw_mono()
BLI_wcwidth()
BLI_wcswidth()
BLI_str_utf8_char_width()
BLI_str_utf8_char_width_safe()
txt_utf8_offset_to_column()
txt_utf8_column_to_offset()
We have a glicth with colormanagement's spaces descriptions, though, looks like they are clamped at 64 chars (see raw space), will see that later, if it’s solvable.
absolute coordinates. This allows an artist to lower the brush radius
while keeping the spread of the brush constant. A toggle under the
jitter slider provides the option to switch between relative/absolute.
- remove unused block from before blender was opensourced (BKE_library_make_local)
noticed by Lawrence D'Oliveiro (ldo)
- remove text_idbutton() unused function.
- test_idbutton(name) was taking (name + 2), then checking 2 bytes before the pointer, this is error prone so better just take the name including the ID prefix.
from Lawrence D'Oliveiro (ldo)
check_for_dupid comments:
- correct comment about in_use array
- note name-truncation code will never be executed
---
Added asserts to ensure comments are correct - ideasman42.
This is as close as I can get to keeping the old code intact. After this
commit, I will have to change existing code paths, making testing of
functionality harder.
Changes:
* Keep only projective texturing code in paint_image_proj.c
* Move 2D code to paint_image_2d.c. This needed the introduction of
allocation/cleanup functions for the relevant structures.
* Common code interface for both modes stays in paint_image.c (which
still includes all old code, system should work as it did with the
exception of non-projective 3D paint mode) and is made public. This is
not a lot of code, only rectangle invalidation and undo system.
* Changed the naming in the new code slightly: imapaint_ prefixed functions refer to
common functions used by both systems, paint_2d_ prefixed to 2d
painting. There will be an interface for the projection painting as
well. Probably there is some leftover naming conversions to do.
TODO:
* Move operator init/exec/modal to common interface file
* Get rid of old BKE_brush_painter_paint, now brush_painter_2d_paint.
All code uses stroke system for the stroke management
* Write space pressure management for the paint stroke system (for other
systems to access as well :) )
* Move texture paint tablet presssure exception code for old bugs to
stroke system (makes me wonder...aren't other systems also influenced by
these pressure issues?) or up in the function hierarchy inside texture
paint. This code is still not there so users with tablets may notice
some issues.
* possibly change other systems to pre-multiply pressure with the
relevant influenced attributes in the stroke function. This could get
tricky though and it's possible that it could backfire.
- Dopesheet need to be updated when adding or switching
between objects.
- After removing object it shall also be tagged for update,
otherwise crash will likely happen.
This was from initial BMesh merge, but should not have been added in since face normals are calculated and stored in the DerivedMesh.
Toggling editmode would remove poly-normals so its unlikely anything relies on this custom-data.
