It was caused by own mistake by not noticing externtex is used not
only by render engine. Now this function uses pool passed as argument
rather than using R.pool.
Previously normalization will happen per image buffer individually, which
was wrong in cases different faces of the sane mesh uses different images.
Also solved possible threading issues when calculating min.max displacement.
This will calculate maximal distance automatically and normalize displacement
to it. Before this change normalization will not happen at all in cases max
distance is not set manually.
This affects on "regular" baker only, there are still some fixes to come for
multiresolution baker, but that could be solved separately.
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.
allow_render_dupli_instance used to pass zero-based index to give_current_material
which is wrong.
Before rev53332 it wasn't so much visible because give_current_material used
to clamp index internally. But that was wrong behavior here anyway, and why
nobody noticed this for so long? :)
There is a new option in the Bake panel to enable baking to vertex colors. Unlike regular baking, this mode does not require a UV map or image to bake to, however the object must have a vertex color layer.
Thanks to:
- AutoCRC for funding
- Brech van Lommel and Dalai Felinto for their initial advice on how to implement it
- Campbell Barton for helping to make this feature work with modifiers and bmesh
This commit implements highlight of tiles which are being currently
rendered for both Blender Internal and Cycles (and should be possible
to use it for other external engines as well).
Couple of implementation details:
- Added one extra boolean flag to render engine which should be set
to truth if render engine wants to highlight tiles. If so, property
use_highlight_tiles should be set to True.
- Render Part's ready boolena was changed by status enum, which could
be NONE, IN_PROGRESS and READY. All render part with IN_PROGRESS
status will be highlighted in image editor.
- For external engines render part's status is filling in automatically.
Initially all render parts has got NONE status, then one external
engine acquire render result, corresponding part will change status
to IN_PROGRESS. As soon as render result is finished, corresponding
render part will change status to FINISHED
This should make it easy to highlight tiles for other engines as well.
This assumptions are now made:
- Internally float buffers are always linear alpha-premul colors
- Readers should worry about delivering float buffers with that
assumptions.
- There's an input image setting to say whether it's stored with
straight/premul alpha on the disk.
- Byte buffers are now assumed have straight alpha, readers should
deliver straight alpha.
Some implementation details:
- Removed scene's color unpremultiply setting, which was very
much confusing and was wrong for default settings.
Now all renderers assumes to deliver premultiplied alpha.
- IMB_buffer_byte_from_float will now linearize alpha when
converting from buffer.
- Sequencer's effects were changed to assume bytes have got
straight alpha. Most of effects will work with bytes still,
however for glow it was more tricky to avoid data loss, so
there's a commented out glow implementation which converts
byte buffer to floats first, operates on floats and returns
bytes back. It's slower and not sure if it should actually
be used -- who're using glow on alpha anyway?
- Sequencer modifiers should also be working nice with straight
bytes now.
- GLSL preview will predivide float textures to make nice shading,
shading with byte textures worked nice (GLSL was assuming straight
alpha).
- Blender Internal will set alpha=1 to the whole sky. The same
happens in Cycles and there's no way to avoid this -- sky is
neither straight nor premul and doesn't fit color pipeline well.
- Straight alpha mode for render result was also eliminated.
- Conversion to correct alpha need to be done before linearizing
float buffer.
- TIFF will now load and save files with proper alpha mode setting
in file meta data header.
- Remove Use Alpha from texture mapping and replaced with image
datablock setting.
Behaves much more predictable and clear from code point of view
and solves possible regressions when non-premultiplied images were
used as textures with ignoring alpha channel.
While trying to render a RenderLayer from a linked scene, I couldnt tell why it wasnt doing anything. It just stopped rendering. Until I look on the console and see the No Camera print.
This commit replaces the simple terminal printf with an actual error report, that shows in both terminal and to the user:
http://pasteall.org/pic/show.php?id=42499
I believe this commit is pretty harmless, and only adds functionality. But feel free to remove it.
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)
Material Texture blend modes Screen, Overlay and Multiply didn't respect
the alpha for textures... an error I could trace back to 2004 even.
Obviously the fix should be done, but it might change the appearance of
renders somewhat. Will keep an eye open if this is worth ugly
version-patching.
Now: image textures with alpha, will only apply the blend modes
respecting the alpha values.
This implements AO baking directly from multi-resolution mesh with much
less memory overhead than regular baker.
Uses rays distribution implementation from Morten Mikkelsen, raycast
is based on RayObject also used by Blender Internal.
Works in single-thread yet, multi-threading would be implemented later.
* Motion blur with shutter time > 1 did result in the correct evaluation
of some modifiers because it set the subframe to values > 1, and some
places assume the current frame to be set to the integer coordinate and
the subframe to be a value between 0 and 1.
* Shape keys did not take subframe time offsets into account.
* Point density texture was using an current frame value that was never set.
Curves heavily scaled down will have render artifacts
Caused by precision issues when computing average normal map
for INDEX3 surface type. Now calculation happens in local object
space instead of world space.
volume wasn't accurate, it still isn't quite but hopefully a bit better by
taking clip start into account.
With clip start it's actually impossible to do a single 'inside' test, since
there will not be a single point where all camera rays start from, though for
small clip start they will be close together.
