Blender Git Loki

Blenderin Git "master"-kehityshaaran kommitit.

Page: 3185 / 5574

May 20, 2013, 05:06 (GMT)
fix [#35434] Segmentation fault switching screen layout from python
May 20, 2013, 00:26 (GMT)
Code Cleanup / Cycles:
* Remove an unused parameter from Checker texture and correct a typo in license header.
May 19, 2013, 18:05 (GMT)
code cleanup: remove unneeded elements in uv NearestHit.
May 19, 2013, 17:45 (GMT)
code cleanup: bmesh/uv
- uv_mouse_select() move from BLI_array to alloca
- was unnecessarily looping over faces for an index lookup when an array is already created.
May 19, 2013, 17:20 (GMT)
code cleanup: remove some kludge from uv loop select
May 19, 2013, 16:52 (GMT)
code cleanup: uv_find_nearest_vert
was doing unneeded lookups on face uv's when the adjacent uv's are known.
May 19, 2013, 16:47 (GMT)
remove WITH_AVX_CPU, also used add_definitions incorrectly.
single cflags can be added manually and don't need their own options.
May 19, 2013, 15:11 (GMT)
style cleanup
May 19, 2013, 15:03 (GMT)
code cleanup: simplify fast_ray_nearest_hit()
May 19, 2013, 11:39 (GMT)
revert (ifdef) r54745. which enbabled alpha in the GL buffer.
looks to be the cause of bug [#35415]

we can make this optional.
Revision 196f7f0 by Gaia Clary
May 19, 2013, 09:45 (GMT)
fix memory corruption: allocated memory space did not match the needed space
May 19, 2013, 08:46 (GMT)
fix for mistake in r56903
May 19, 2013, 04:12 (GMT)
Fix for last fix, compile error in smoke code.
May 19, 2013, 04:07 (GMT)
Fix #35407: different particle behavior compared to 2.66, reverted part of 56073.
May 19, 2013, 03:15 (GMT)
BGE: Applying patch [#35416] "Missing python properties on ActionActuator: layer, layerWeight" from Florian Bantner (scheintodx).
May 19, 2013, 00:56 (GMT)
Fix for [#35245] Freestyle getting stuck on view map creation + memory leaks.

There were two issues:

- Line visibility computations are very slow in the case of the provided .blend file, which gave
an impression that the rendering process got stuck. The slowness can be explained by the present
data structures used for the line visibility computations, together with the specific mesh distribution
of the test scene. At the moment Freestyle uses a regular grid in the 2D image coordinate system
to divide tris/quads into small groups in order to accelerate the line visibility computations.
On the other hand, the test scene is populated a big plane (made of one quad) and a moderately
detailed mesh object (22K tris). The scale of the latter mesh is animated from nearly zero to
about 0.2 to make the object show up over time. When the scale is nearly equal to zero, all the
tris concentrate in one grid cell, so essentially there is no performance gain from the grid data
structure optimized for speed. It looks like a better grid data structure (possibly based on
adaptive grid refinement) is necessary to genuinely address the identified performance issue. For now
the progress bar of Blender is employed to better inform users of the amount of work done in the line
visibility computations.

- A crash was caused by an excessive memory allocation request. The X and Y dimensions of the grid
data structure are determined based on the average area of mesh faces in the given scene. When the big
plane in the test scene is excluded from the rendering, the average area is almost zero (on the order
of 1e-5). As a result of this extremely small average area, the X and Y dimensions were set to a very
large number, causing a fatal memory allocation error. The present revision has introduced a hard
upper limit to the dimensions of the grid data structure to avoid this kind of numerical instability.
May 18, 2013, 22:40 (GMT)
Cycles:
* Fix OSL compilation for scene_intersect(), when __Hair__ was disabled.
May 18, 2013, 19:18 (GMT)
Optimizations for dyntopo
- creating faces was unnecessarily checking if they already existed.
- deleting a face did edge-lookups, when the edges are already available from the face-loops.
May 18, 2013, 15:51 (GMT)
Fix crash due to shared paint cursor function. It is necessary to check
if we really are in sculpt mode context since the active object may be
in sculpt mode while cursor is in the 2d paint editor.
May 18, 2013, 15:24 (GMT)
Fix for #35373, calling any paint operator from operator search menu
with mouse crashes blender.

Issue here is that paint operator invocation, immediately calls modal,
which checks if event is the same as initialization event plus keyup.
Since using the mouse on amenu calls the operator on mouse button up,
the operator ended immediately and that cause immediate cleanup and
crash,

Worked around this by forbidding the operator to finish on first modal
call (which is expected by all the asserts on invoke anyway). This
prevents the crash but requires an extra up event to end.

Also, ported part of Jason Wilkins' patch to stroke code to allow for
stroke sampling to be done before a dab is first performed and as soon
as the stroke begins
Tehnyt: Miika HämäläinenViimeksi päivitetty: 07.11.2014 14:18MiikaH:n Sivut a.k.a. MiikaHweb | 2003-2021