Thanks for Sergey for finding the bug & patching, This fix works a bit differently.
Theres no need to allocate the customdata in the first place - since its written into. So add a flag for vert/edge/face/loop creation functions so they can skip customdata creation.
- script stub printed resource warning with py3.3 (not closing a file).
- bmesh customdata layer access had bad docstring.
- float/double conversion warnings in sequencer code (use doubles since result is double)
- remove unused var
That was kind of a regression since fix for #32091: Crop and offset coordinates changes proxy
render settings on image strips, which is now fixed in other way.
Namely Offset/Crop values are filling in 100% scene resolution values, but getting scaled to
proxy / scene percentage values.
scanfill remove-doubles pass assumes ordered edges (as with curves), otherwise it can hang.
workaround this problem by skipping removing-doubles for mesh ngons, since this isnt such a common case as it is with curves and we can just not support it.
* Rename Legacy to Standard, it's not being deprecated as far as I know.
* Make option to toggle off Location solving work with Standard.
* Make it converge a bit better in some cases by enforcing a minimum number of
iterations before giving up.
* Move IK solver choice out of bone panel, it's an armature level setting and
should be set there.
Path rebuild may fail after certain editing operations. Instead of blindly
assuming that path rebuilds will always succeed, we now give up trying to
evaluate in case of failure.
BKE_scene_update_for_newframe should be called before RE_BlenderFrame in
seq_render_scene_strip. It's not entirely nice, but bot sure about better
solution for now.
Patch by David M (erwin94), thanks!
Also made Vorbis codec using float sample_fmt, otherwise it didn't work
with new FFmpeg.
Perhaps we can make it more clear by explicitly separating audio_input_buffer
for float and integer buffers, but as far as it works i'm not so fussed about
this atm.
There were two issues in scene strip rendering:
- It will skip rendering if scene doesn't have camera but uses compositor
- G.is_break will cancel preview rendering
Also removed Use Sequencer from scene's strip settings, it's not supported.
update the function to calculate the derived mesh with bmesh data-mask each time.
resolves bug [#33205] Bmesh "from_object" gives "no usable mesh data".
also found 'mesh_build_data' could run with non mesh objects and fail silently - add an assert.
selected linked in face mode was crashing. (needs bmesh operator flags)
also some style edits, remove unused includes and change triangulate modifiers use_beauty to a flag.
Useful for bump map baking where a consistent triangulation should be enforced when baking/exporting/importing, to avoid artifacts caused by a different triangulation of the mesh by that which was used for baking by internal/external tools.
documentation is here http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.65/More_Features
Will probably add some pictures too to demonstrate the issue that is solved more clearly.
Currently using the skin modifier icon, will soon change that.
Review by Brecht, thanks!
or baking. This basically means you will only have access to bpy.data and
bpy.context.scene, not current window, active object, etc, as those are not
thread safe anyway and were likely to cause issues already.
This fixes#30858, where the UI would lose buttons due to context getting
corrupted when editing objects in pre/post render or using luxrender. The
context access they did (indirectly) was only using the current scene or
data so they still work.
This commit makes BKE_image_acquire_ibuf referencing result, which means once
some area requested for image buffer, it'll be guaranteed this buffer wouldn't
be freed by image signal.
To de-reference buffer BKE_image_release_ibuf should now always be used.
To make referencing working correct we can not rely on result of
image_get_ibuf_threadsafe called outside from thread lock. This is so because
we need to guarantee getting image buffer from list of loaded buffers and it's
referencing happens atomic. Without lock here it is possible that between call
of image_get_ibuf_threadsafe and referencing the buffer IMA_SIGNAL_FREE would
be called. Image signal handling too is blocking now to prevent such a
situation.
Threads are locking by spinlock, which are faster than mutexes. There were some
slowdown reports in the past about render slowdown when using OSX on Xeon CPU.
It shouldn't happen with spin locks, but more tests on different hardware would
be really welcome. So far can not see speed regressions on own computers.
This commit also removes BKE_image_get_ibuf, because it was not so intuitive
when get_ibuf and acquire_ibuf should be used.
Thanks to Ton and Brecht for discussion/review :)
