There was strange context changes in the Add menu... Now everything uses the EXEC_REGION_WIN one (no need to invoke here, and metaballs have a strange specific invoke func...). This fixes the problem when using Add menu from a 3D view. Obviously, it still doesn't work when used from Info window's header, but that can't be helped for now (and never worked for any kind of object).
Anyway, imho all this "add object" code could use some review/cleanup, both on py menu and C ops side, but this is obviously postponed to after 2.64!
from special NDOF menu, added them in user preferences as well now. Also made it do
proper version patch for conversion from old user preferences, and changed turntable
choice from a boolean to enum for consistency.
have no effect on the end result, because it is only an intermediate space and
scene_linear was already set to Linear. It does avoid some unnecessary matrix
transforms which should be a bit faster, and it makes it more clear what's
happening.
(there were several differences on color theme stored in startup.blend
and colors after restoring them by Reset to Default Theme button).
Should be no other changes.
Main problem was in py UI code (has to set the context to INVOKE_REGION_PREVIEW for the shortcut lookup to succeed).
Also moved the N properties item into SequencerCommon keymap, and removed the View Selected menu entry from preview-only mode View menu (thx to Ejner Fergo for pointing this out).
updating data was only being done on the active object but sticly was being calculated for the selection.
split this into 2 operators, one that works on the selection and another that operates on the active object - so we can have a button in the mesh panels that calculates sticky.
also note that there was no way to calculate sticky from the UI - perhaps this feature should die a quiet death?
anyway - it works better then it used to for now.
currently can remove sticky/mask/skin vertex layers.
regarding the skin layer - while adding and removing the modifier normally works fine, its not 100% reliable since the mesh may be linked into another scene, or be a linked duplicate and the object with the modifier deleted.
Replace old color pipeline which was supporting linear/sRGB color spaces
only with OpenColorIO-based pipeline.
This introduces two configurable color spaces:
- Input color space for images and movie clips. This space is used to convert
images/movies from color space in which file is saved to Blender's linear
space (for float images, byte images are not internally converted, only input
space is stored for such images and used later).
This setting could be found in image/clip data block settings.
- Display color space which defines space in which particular display is working.
This settings could be found in scene's Color Management panel.
When render result is being displayed on the screen, apart from converting image
to display space, some additional conversions could happen.
This conversions are:
- View, which defines tone curve applying before display transformation.
These are different ways to view the image on the same display device.
For example it could be used to emulate film view on sRGB display.
- Exposure affects on image exposure before tone map is applied.
- Gamma is post-display gamma correction, could be used to match particular
display gamma.
- RGB curves are user-defined curves which are applying before display
transformation, could be used for different purposes.
All this settings by default are only applying on render result and does not
affect on other images. If some particular image needs to be affected by this
transformation, "View as Render" setting of image data block should be set to
truth. Movie clips are always affected by all display transformations.
This commit also introduces configurable color space in which sequencer is
working. This setting could be found in scene's Color Management panel and
it should be used if such stuff as grading needs to be done in color space
different from sRGB (i.e. when Film view on sRGB display is use, using VD16
space as sequencer's internal space would make grading working in space
which is close to the space using for display).
Some technical notes:
- Image buffer's float buffer is now always in linear space, even if it was
created from 16bit byte images.
- Space of byte buffer is stored in image buffer's rect_colorspace property.
- Profile of image buffer was removed since it's not longer meaningful.
- OpenGL and GLSL is supposed to always work in sRGB space. It is possible
to support other spaces, but it's quite large project which isn't so
much important.
- Legacy Color Management option disabled is emulated by using None display.
It could have some regressions, but there's no clear way to avoid them.
- If OpenColorIO is disabled on build time, it should make blender behaving
in the same way as previous release with color management enabled.
More details could be found at this page (more details would be added soon):
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management
--
Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO
integration and to Brecht van Lommel for some further development and code/
usecase review!
This commit integrates support of OpenColorIO library into build systems.
It also contains C-API for OpenColorIO library which could be used by Blender.
CMake has got find rules familiar to OpenImageIO's one which makes it easier
for build system to find needed libraries and includes. Scons only could use
explicitly defined paths to libraries and includes.
C-API would be compiled and Blender would be linked against C-API and OpenColorIO
but it wouldn't affect on Blender behavior at all.
OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and
setting WITH_BF_OCIO in Scons.
- sample weight didnt work when the object was transformed.
- sample weight didnt work when vertex selection was enabled.
- 'All faces' option is used by weight paint mode, but there was no UI access.
add ED_mesh_pick_face_vert(). which uses the face selection buffer but returns the closest vertex.
Initial idea of this input was re-designed in a bit more flexible
way using modifiers.
Also since Color Balance (which was the only thing using effect
mask input) was moved to the modifiers, this input field became
rudiment.
It's pretty tricky to write versioning code to prevent possible
data in cases this field was used, but hope it wouldn't be difficult
to switch to modifiers masks.
Having two ways to control color balance now seems a bit overkill
and not clear.
Removed old Color Balance settings from the interface and logic,
added versioning code to convert this settings to modifier.
Unfortunately, since color balance was a pointer, it's not actually
possible to preserve compatibility of old files saved in new
blender and opened back in old blender.
Hopefully there's no regressions :)
- Even preserves thickness but can give unsightly loops
- Smooth gives nicer shape but can give unsightly feather/spline mismatch for 'S' shapes created by beziers.
This is an example where smooth works much nicer.
http://www.graphicall.org/ftp/ideasman42/mask_compare.png
