Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
since enough bmesh operations can also take advantage of direct index lookups on verts/edges/faces.
developers note:
- EDBM_index_arrays_init/ensure/free -> BM_mesh_elem_table_ensure/init/free
- EDBM_vert/edge/face_at_index -> BM_vert/edge/face_at_index
- EDBM_uv_element_map_create/free -> BM_uv_element_map_create/free
- ED_uv_element_get -> BM_uv_element_get
|
|
My previous fix for uninitialized texture coordinates was not working well,
and in fact there was a bigger issue with GLSL drawing and missing attributes
with immediate draw mode. Now it will explicitly pass zero rather than having
it use whatever value was set last.
|
|
|
|
to draw textures without shading. For Cycles this was not possible yet, and
for Blender Internal you had to move away all lights which was also not ideal.
(Caminandes feature request)
|
|
but not UV coordinates, it would show a different color with the object selected
and deselected.
|
|
hides that an arg passed is really an array which may be modified by other functions.
|
|
|
|
|
|
|
|
|
|
texture if more than 1 texture is used
The problem here is that no flushing is done when the texface image
changes between rendered triangles. Added a compare function and
slightly modified the draw_tface_mapped__set_draw callback to compliant
with the new user data.
|
|
|
|
|
|
reported by Leon Cheung.
Adding an extra NULL check to draw_mesh_text() to avoid accessing a NULL material array.
|
|
with bmesh theres no need for edge-hash lookups, replace EdgeHash with BLI_bitmap.
|
|
Added face selection code to GLSL draw. We do this for Cycles
already, shall behave expected now.
Checked by Ton, thanks!
|
|
EditDerivedBMesh.tc -> em. ('tc' is odd name which isn't used elsewhere).
|
|
functions.
|
|
|
|
option in the material in texture draw mode, now it always overrides the material.
|
|
paint).
|
|
Setting Cycles as render engine skipped matcap drawing.
Logic for checking drawing types needed a shuffle.
|
|
bugfix.
|
|
changed
In fact surfaces should be displaying the same way in textures and solid shading,
but they used to change a way they're displaying by draw_textured_end not resetting
light model properly, leaving two-sided shading for all further objects draw.
|
|
`through` the mesh.
also made the wire draw without depth masking when the depth check is off, similar to mesh editmode drawing, nice hint about whats going on.
|
|
with the backbuffer (depth selection).
|
|
filepath
was changed to an invalid one. Also fixed Object Color not being displayed correctly
with VBO's.
The way it has to clear the VBO buffers here is quite poor though and slow, we
really need textures and materials in the depsgraph to do this quicker.
|
|
skip glsl for picking as was already done for other GLSL drawing.
|
|
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 :)
|
|
|
|
|
|
|
|
|
|
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/
|
|
|
|
|