| Age | Commit message (Collapse) | Author |
|---|
|
This modules does not depend on any blender-specific data
structures or algorithms and due to our policy better be
placed to intern/
Shall be no functional changes, tested CMake and SCons on
Linux, hopefully other platforms will work as well.
P.S. SVN history shall be preserved for the files.
|
|
|
|
this patch enables the translate node to wrap around the image borders. This is especially needed if the translate node is not used to position elements on a layer but when it is used instead for seamless backgrounds like mountains or clouds that should be repeated over time (by animating the x/y values).
No trunk without docs! So here is my documentation: http://wiki.blender.org/index.php/User:Plasmasolutions/TranslateNodeExtension
The code is properly documented and should be easy to read and understand. When there are any problems or issues, please comment, I'll tackle them right away!
Greetings, Thomas Beck
* optimized determination dependant areas
* fixed some issues with scale node
There are still some issues when scaling very small values (x=0.0001)
- At Mind -
|
|
|
|
another patch for the dilate/erode step method, still without any functional changes.
This time it keeps the general algorithm but uses the tile system to make it
multithreaded. I could not measure a speedup on my 2-core laptop, but hope that
it will be faster for more cores. The immediate speedup that is very visible though is
that tiles come in as soon as they are calculated and a dilate/erode node does not
block the whole image to be calculated.
till then, David.
|
|
|
|
this patch optimizes the dilate/erode step method (hopefully without any functional change),
making its speed not depend on the distance anymore.
Couldn't detect funtional changes so committing. Haven't tested for speed gain.
* credits to erwin94 David M
|
|
It was caused by image threading safe commit and it was noticeable
only on really multi-core CPU (like dual-socket Xeon stations), was
not visible on core i7 machine.
The reason of slowdown was spinlock around image buffer referencing,
which lead to lots of cores waiting for single core and using image
buffer after it was referenced was not so much longer than doing
reference itself.
The most clear solution here seemed to be introducing Image Pool
which will contain list of loaded and referenced image buffers, so
all threads could skip lock if the pool is used for reading only.
Lock only needed in cases when buffer for requested image user is
missing in the pool. This lock will happen only once per image so
overall amount of locks is much less that it was before.
To operate with pool:
- BKE_image_pool_new() creates new pool
- BKE_image_pool_free() destroys pool and dereferences all image
buffers which were loaded to it
- BKE_image_pool_acquire_ibuf() returns image buffer for given
image and user. Pool could be NULL and in this case fallback to
BKE_image_acquire_ibuf will happen.
This helps to avoid lots to if(poll) checks in image sampling
code.
- BKE_image_pool_release_ibuf releases image buffer. In fact, it
will only do something if pool is NULL, in all other case it'll
equal to DoNothing operation.
|
|
|
|
- Drawing masks in image editor requires LOCK_DRAW_IMAGE around
ED_space_image_get* functions since they'll acquire image buffer.
Lock is needed because viewers will be modified directly in
compositor (see commend in draw_image_main)
- Seems that was wrong order of invalidating render result and
viewer image invalidation happened in Composite node, which
could easily lead to thread lock.
|
|
|
|
|
|
|
|
Issue was caused by resolution detecting which assumed zero resolution is
undefined one and should be re-evaluated. It doesn't work in cases when
there's a missing input, causing lots of unneeded resolution re-calculation.
It wasn't so much issue in average sized node trees, but it was a real
problem in generated tree from the report.
Currently used pretty simple solution which added a boolean flag to the
node operation which signal whether resolution was ever set or not.
There're probably smarter solutions here but can not think about them.
|
|
This codec is absolutely needed to generate DCP using OpenDCP,
before that external application to convert JP2 to J2K was used
which slowed down export a lot.
New codec is exposed to image format settings panel and called
Codec. Default one is JP2 which creates files with .jp2 extension,
new one is called J2K which creates with .j2c extension.
Other changes:
- Fixed avi jpeg warning which was treating as error here.
- Made it so extension is detecting from ImageFormatData instead
of image file type, which makes it possible to have different
extension for the same file type depending on it's settings.
IRIS format should still be changed (depending on number of
channels it'll be .bw, .rgb or .rgba extension)
- Default image format settings would be set from image buffer
when re-saving it. Makes it possible to easily open .j2c file
and save it using J2K codec (without this change it'll save as
.jp2 using JP2 codec)
|
|
|
|
by mistake.
removed RNAMeta mixin class since you cant register subclasses.
also some minor code cleanup
|
|
|
|
|
|
Also changed shebang to '#!/usr/bin/env python', this is more portable across unixes...
|
|
|
|
resolution is zero.
|
|
There was a missing image reload signal in node creation by drag-dropping,
which lead to incorrectly set image type.
Also fixed misusage of IMB_freeImBuf used to release buffer acquired by
BKE_image_acquire_ibuf.
|
|
|
|
|
|
Think should be pretty much harmless since if this node was used for buffers
with infinities it already showed artifacts. Now it should be more useful for
mapping Z buffers.
|
|
The same behavior was in old compositor system and it makes more sense
when you're normalizing Z buffer.
|
|
Seems no extra notifiers should be added here.
|
|
from main thread using job update callback.
Added new execution-time callback to bNodeTree which marks job to be updated.
The code here could be a bit not so obvious because in some cases job update
callback need to merge local tree, but it's only needed for old compositor
system which is gonna to be removed soon, so decided not to bother with
cleanup now. Removing old compositor system will also allow to drop stats_draw
callback from bNodeTree.
This should fix following bugs:
|
|
BLI_sprintfN when invalid args are given.
|
|
docs.
|
|
|
|
- FastGaussianBlurValueOperation is a value operation, so use only first vector
component in initializeTileData.
- Gamma correct/uncorrect operations didn't set alpha for output which lead to
usage of uninitialzied memory further in nodes graph.
|
|
convertToOperations. This breaks quite a lot and is not really necessary, since connected Node inputs are ignored later on. Connected outputs however are still forbidden, this indicates a real bug.
|
|
rendering), it should still unlink all inputs to avoid debug assert failure that checks for remaining Node connections (debug_check_node_connections).
|
|
redirecting links from the reroute output the input must be completely unlinked, otherwise the debug_check_node_connections will complain (this is a sanity check that ensures all the original Nodes have been fully reconnected to Operations).
|
|
socket menu, and make the normal animatable.
|
|
Own mistake in image threading commit.
|
|
Gamma correction option was ignored by new compositor system.
Also new compositor was doing alpha premul in a wrong way. In fact,
not sure if it should do premul -- old compositor didn't do that..
|
|
also add UNPACK macros's. handy for printing vectors for eg.
|
|
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 :)
|
|
presence of markers still hangs.
also compiler warnings and some style edits.
|
|
(useful for flipping the values inside the node)
|
|
this node allows for more control for normalization of the mapped input range.
Made during BlenderPRO 2012 - Brasilia, Brazil :)
Idea and testing: Daniel Salazar
Implementation: yours truly
Reviewed by Lukas Toenne and Sergey Sharybin
|
|
also initialize bmesh-bevel settings struct to zero to avoid possible uninitialized memory later.
|
|
from blenlib
|
|
It wasn't used and it was incorrect anyway (distortion could be more than 100px).
|
|
Originally issue was discovered when using stabilization and movie distortion
nodes, but in fact issue was caused by render layer node always doing nearest
interpolation. Now made it so this node will respect sampler passed to it's
executePixel function and do an interpolation.
Added two new functions to do bilinear/bicubic interpolation in float buffer
with variable number of components per element, so it could interpolate 1, 3
and 4 component vectors. This functions currently mostly duplicates the same
functions from imageprocess.c and it should actually be de-duplicated. Think
it's ok to leave a bit of time with such duplication, since functions should
be generalized one more time to support byte buffers, which could backfire on
readability.
Also removed mark as complex from stabilization node, which isn't needed sine
int fact this node is not complex.
|
|
- Somehow this node was using nearest interpolation which seems have been
passed from compositor node. It was using b-spline interpolation with
old compositor implementation. Now forced this node to use bilinear
interpolation, which should be close enough.
- Operation should be marked as complex it seems, otherwise area of
interest wouldn't make any affect on it's behavior.
|
|
|
