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!
reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer
for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces.
(CD_POLYINDEX and CD_ORIGINDEX).
as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on
the same derived mesh, and polygons only store the original index values.
Documentation & Test blend files:
------------------
http://wiki.blender.org/index.php/User:MiikaH/GSoC-2012-Smoke-Simulator-Improvements
Credits:
------------------
Miika Hamalainen (MiikaH): Student / Main programmer
Daniel Genrich (Genscher): Mentor / Programmer of merged patches from Smoke2 branch
Google: For Google Summer of Code 2012
