Color management of byte buffers is currently disabled, to enable
it COLORMANAGE_BYTE_BUFFER from colormanagement.c should be defined.
Currently color management supposes that byte buffer is originally
in sRGB space. Ideally it'll be using the same input color space
setting as float buffer which is still in a TODO list.
It could be nice artistic option to play with. Also in theory it's
possible that byte images would store data in non-sRGB space.
There's still kind of issue with byte buffers which results in
showing linear image when view transform is set to RAW. It'll be
resolved as soon as real input color space is added. Other view
transformations should work fine.
Refactored code a bit to make naming a bit more clear and added a
function to create mesh from given display list rather than from
object's displist.
Tested using plain curves (which doesn't imply using derived meshes)
and curves with constructive modifiers (which are using derived meshed).
notes:
- uncomment #define USE_RASKTER in BKE_mask.h to use the previous mask rasterizer.
- slightly slower for regular masks but significantly faster for feather.
- main benefit is that it threads well so works nice for tile compositor.
- feather is lower quality, can use some improvements here.
- feather can also use some interpolation enhancements, will do later.
This commit adds "shift" and numtype to both Bevel and Inset mesh operators.
It also gets rid of the magicnumber used in NumInput to str operation (currently, 20 chars per element, now defined as NUM_STR_REP_LEN in ED_numinput.h).
Problems were in the old multires loading system.
Actually, the sigsev itself was the easy part of the job (simply had to convert from tesselated data to polys/loops), but after that I was getting a horrible bunch of wild stray faces...
It finally turned out it was a mismatch in two different subsurf structs used while computing a mdisps layer from the multires DM, leading to getting complete random normals (null ones, NAN ones...), leading to complete dummy tangent space matrix, leading to absurds mdisps values...
Note: I also moved the copy of first layer's vertex and face data from old me->mr to mesh's v/fdata earlier in multire_load_old(), to be able to use general face_to_poly conversion function (later on we would have to do it by hand, the general function would erase our newly computed mdisps layer...).
Took me the whole week (something like 20h) to track this down: multires + subsurf = C nightmare!
Issue was caused by threading conflict between compositor output node which
is freeing buffers used by render result image and image draw code which
could use buffers at the same time as compositor frees this buffers.
Solved by adding adding lock around viewer image invalidation and image
drawing.
Use renamed LOCK_PREVIEW mutex for this, which si not called LOCK_DRAW_IMAGE.
With new compositor locking for preview is not needed so it could be removed.
Added the same lock around viewer operation which also frees buffers used
by viewer image. It's actually quite difficult to check whether this is
indeed needed. This code seems to be using acquire/release technique, but
somehow acquiring ImBuf before invalidating it in compositor operation
doesn't resolve the issue, so probably it's not actually locking acquire
and things should be checked deeper.
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/
Issue was caused by performing conversion from FTFaces to materials from
the end of lib_link_mesh, where tesselated faces were cleared already.
This conversion can't be switched to BMesh structures because in future
MTexPolys could be changed in a way, that versioning stuff wouldn't work
any more. Another issue is that making such a conversion per-mesh would
lead to quite a code spagetti, which is difficult to follow.
Solved by splitting per-mesh cycle in lib_link_mesh, so now it consists
of three steps:
- Do linking stuff such as custom data layers, materials. Perform a
Conversion stuff like tessface -> polys.
- Convert all MTFaces to materials. This conversion handles all meshes
and creates needed materials.
- Free tessfaces, mark mesh as linked.
Such a separation shouldn't noticeably affect on speed of linking.
Issue was caused by the code which checked whether snapping should be enabled
on transform init taking into account keymap and special keys state. It was
used for Ctrl-Click on manipulator only.
Check for Ctrl state gave wring result with skin modifier. It was solved
by additional check for which mode transformation is initializing for --
currently manipulator is available for translation/roation/resize only
which doesn't give any keymap issues.
