| Age | Commit message (Collapse) | Author |
|---|
|
Made it so viewport will disable color management if display device set to None.
This solves couple of regressions, mainly related on old BGE files and made
None display behave exactly as old color management disabled.
|
|
|
|
source/blender/blenkernel/intern/property.c would get mixed up with an X11 function of the same name. it crashed blender loading on my system.
Give functions in property.c more unique names.
|
|
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!
|
|
of the vars were in fact NULL)
|
|
C with gcc.
helps for finding unused functions and making functions static, also did some minor code cleanup.
|
|
situations.
|
|
|
|
color managed.
|
|
from Fredrik Hansson (fredrikh)
|
|
Issue was caused by VBOs using CD_TEXTURE_MCOL for faces colors. This
layer was creating on mesh display (from draw_tface_mapped__set_draw)
in cases there's no such a layer.
If material settings are changing, this layer wasn't updated and old
colors were used.
Fixed by performing an update of this layer in cases it's already
exists. This would give some % of slowdown, but don't think it'll
be dramatically bad.
Would be nice to find a nice way to update such a layer in cases
material is actually changes only, or get completely rid of it/
|
|
|
|
|
|
instanced in a dupli
|
|
replace do prefix with do_ for bool vars.
|
|
wire paint drawing into draw_mesh_paint().
|
|
|
|
also stop numpy from being found in /usr/include with cmake.
|
|
There is an FAQ that mentions a mythical GL_LIGHT_POSITION, and lots of programmers speak of it, but this mythical creature does not exist!
The correct symbol is GL_POSITION
|
|
also quiet unused var warnings
|
|
mask drawing.
Now refactored the code a bit so that in no longer calls textured mesh drawing
for the face mask drawing, just handle it as part of regular paint color drawing.
Should also make the blender internal behavior more logical where it would start
showing textures in solid mode when enabling face masking.
|
|
allows vertex paint to be unlit (which is quite handy, previously you had to hide lamps).
|
|
missed call to glColorMaterial made glEnable(GL_COLOR_MATERIAL) behavior
undefined.
|
|
UV/Image Editor)
Another regression since bmesh merge which was caused getting CD_MTFACE from
polys datablock instead of face datablock.
|
|
It was a regression since 2.62 caused by how texface is passing to drawParamsMapped
Previously it was used from CD layer but now it's getting copied from MexPoly
into a variable allocated in stack for function void emDM_drawFacesTex_common.
To set texture needed to draw particular face function set_draw_settings_cached
is used, which tries to not to copy texture into GPU when it's not needed (for
example, when drawing bunch of faces with the same texture) and one of condition
if texture should be updated in GPU was comparing address of texface passed to
this function and cached texface. But this address are exactly the sane and
points to a memory inside stack of emDM_drawFacesTex_common.
Fixed by cacheing texface content, not it's address.
|
|
error with recent refactoring.
|
|
|
|
match BM_ function naming conventions
|
|
|
|
|
|
else if's
|
|
this layer is now also used for various preview tasks in Object mode.
“Cleanup” commit, no functional changes.
|
|
old mesh MCol 'r' was blue, 'b' was red, but theres no reason to keep this for bmesh with MLoopCol.
Loading old files works, saving legacy format works too.
What wont work is loading a file after this revision and loading it in an older revision since the bmesh merge.
(it wont crash but the blue and red will be swapped on vertex color layers).
|
|
|
|
also remove large, duplicate comments from sunsky.h
|
|
The DMSetDrawOptions[Tex] callbacks return 0 (skip), 1 (draw), or 2
(either stipple or skip mcols.) In the CDDM, EDDM, and CCGDM draw
functions, as well as the callbacks in drawmesh/drawobject, replace
these numbers with values from an enum, DMDrawOptions.
|
|
This function pointer's 'setDrawOptions' parameter took a slightly
different type than the other drawing callbacks. In particular, it
could set a 'drawSmooth' value to indicate that smoothing should
always be enabled, overriding the face flag. However, all callbacks
either did not set this value, or set it unconditionally to
1. Replaced this by adding a new 'flag' parameter to drawFacesMapped,
which can be set to DM_DRAW_ALWAYS_SMOOTH where appropriate.
Also removed the 'useColors' parameter and replaced it with another
flag value, DM_DRAW_USE_COLORS.
Removed the 'wpaint__setSolidDrawOptions' callback, was only being
used to set the shading to smooth.
|
|
It's currently not respecting the material color, probably since the
BMesh merge. There are a couple problems, both involving "dummy"
variables taking the place of actual MTFace/MCol data.
Code review: http://codereview.appspot.com/5753050/
|
|
already used a lot and part of proposed style guide).
|
|
|
|
|
|
- copy & rename EditMesh stricts for use with scanfill (remove unused members)
|
|
These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete.
This uses similar convention to RNA.
* use face/loop/edge/vert as a prefix for functions.
* use 'elem' as a prefix too for functions that can take any type with a BMHeader.
* changed from camel case to underscore separated (like RNA).
|
|
these flags apply to bmesh elements.
|
|
drawing game engine bitmap font text.
minor edits to draw_tface_mapped__set_draw() to make it more efficient.
|
|
macro for copying polygon settings
|
|
since removing tesselation faces we can no longer rely on me->totface & me->mface being set. now use polygons instead.
|
|
Noted preview code for DynamicPaint is currently disabled, will see if I can re-enable it…
|
|
of how modifiers can generate preview.
User side:
* Preview for DynamicPaint should keep the same behavior (for now). Weight preview should be somawhat quicker, though.
* Preview for WeightVG modifiers is only active in WeightPaint mode, and if the affected vgroup is the active one.
* Last active preview modifier in stack wins!
Note: that modifier preview topic is yet to be further refined, quite raw/incomplete for now.
Dev side:
* In draw code, renamed DRAW_DYNAMIC_PAINT_PREVIEW flag to DRAW_MODIFIERS_PREVIEW
* Removed use of MOD_DPAINT_PREVIEW_READY in DynamicPaint code (seems unecessary, and if it was, should be of more general scope).
* Added eModifierTypeFlag_UsesPreview to ModifierTypeFlag, for modifiers that can generate some preview data.
* Added three new modifier funcs, to handle preview modifiers in draw code / mod stack.
* For weights preview: added the generic DM_update_weight_mcol func, which can update WEIGHT_MCOL layer with either a given array of weights (currently used by DynamicPaint only), or from current active vgroup(s).
So now, draw code is fully generic (i.e. no more modifier-type checking in it). Mod stack code is generic to some extent, but will need more work.
|
|
|
