Conflicts resolved:
source/blenderplayer/bad_level_call_stubs/SConscript
Partly reverted changes to intern/cycles/blender/addon/ui.py in revision 52899
to make it easier to merge trunk changes.
note: that this intentionally removes check to exit vpaint mode when a vertex color layer is removed,
since being in vertex-paint mode without a vertex color layer is supported.
also minor change to drawing camera limits while picking from previous commit.
Resolved conflicts:
release/datafiles/startup.blend
source/blender/editors/space_nla/nla_buttons.c
Also updated source/blender/blenkernel/intern/linestyle.c as a follow-up of
recent changes for the use of bool.
Zooming in on images in Image window now shows pixels again (was filtered).
Now the glaDrawPixelsTex() and glaDrawPixelsAuto() have an argument to
define if images should zoom in with linear filter, or draw pixels.
brushes, due to issues with color coded drawing or slow/buggy reading from such
a buffer on some systems.
In case multisample is enabled now, it uses an offscreen buffer for such drawing,
which is not multisampled and so should not cause issues. This does mean there is
some extra GPU memory usage when multisample is enabled, and we could optimize
triple buffer to work together here somehow to share buffers, but it's better than
having selection not working.
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.
Also now display nice "area" units (maybe using "length" units was a perf matter, but anyway, you can't have more than a few tens of values displayed at a time, after that they become unreadable). Easy to undo anyway if we really want to keep ugly "10m" as area display!
Full log is here:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.66/Usability#Matcap_in_3D_viewport
Implementation notes:
- Matcaps are an extension of Solid draw mode, and don't show in other drawmodes.
(It's mostly intended to aid modeling/sculpt)
- By design, Matcaps are a UI feature, and only stored locally for the UI itself, and
won't affect rendering or materials.
- Currently a set of 16 (GPL licensed) Matcaps have been compiled into Blender.
It doesn't take memory or cpu time, until you use it.
- Brush Icons and Matcaps use same code now, and only get generated/allocated on
actually using it (instead of on startup).
- The current set might get new or different images still, based on user feedback.
- Matcap images are 512x512 pixels, so each image takes 1 Mb memory. Unused matcaps get
freed immediately. The Matcap icon previews (128x128 pixels) stay in memory.
- Loading own matcap image files will be added later. That needs design and code work
to get it stable and memory-friendly.
- The GLSL code uses the ID PreviewImage for matcaps. I tested it using the existing
Material previews, which has its limits... especially for textured previews the
normal-mapped matcap won't look good.
Old fixes, since 2009 and before! Related to Curve object editmode:
- normals are not being drawn for hidden curves anymore
- even worse: Blender also didn't hide the extrusions or bevels for hidden curves
- outside edit mode, it shows all (as for all other modes)
- (de)select-all now works when 1st (or any) handle was hidden.
Edge length display in standard files (1 blender unit == 1) only gave two
numbers precision for lengths > 1. Three is much nicer at least.
The guess-work here in the code remains a bit dubious :)
Simply added a dashed line materializing the center/direction of the spot, and ending at Distance from it (exactly as for the Area lamp). We already had something similar for buffered shadow spots (to materialize start/end clipping), and imho it's also quite useful to see *where* points a spot, when using wide spots!
Very easy to revert anyway.
caused by not projecting points behind the perspective view,
even though this worked in 2.64 the values were flipped (rotating direction was reversed and the center point was flipped).
added V3D_PROJ_TEST_CLIP_NEAR, when omitted ED_view3d_project_*** will project points from behind a perspective view plane.
this may introduce bugs which I didn't catch, but they are very easy to identify in a debug build which has asserts to ensure the arrays are valid before use.
in my own test drawing ~98,304 quads - this gave an overall ~16% drawing speedup.
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 :)
Conflicts resolved:
source/blender/blenloader/intern/readfile.c
source/blender/bmesh/operators/bmo_utils.c
This commit also includes a fix of a bug identified during the merge and committed in revision 51853.
Thanks Thomas (dingto) for the timely fix!
