Mainly behaves in the same way as legacy color transformation, but it'll
give different result on over and under exposured areas.
Not sure if it's indeed issue -- seems this behaves crappy in both of
current stable release and OCIO branch.
This gives some percentage of speedup, which compensates slowdown
caused by converting image buffer into display space.
Used OpenMP for this. Still feel skeptic about this, discussed with
Brecht and we decided this approach actually could be used since
seems all the platforms has got OpenMP issues solved.
Waveform and vector scopes are still single-threaded since they're
a bit tricker to be done multi-threaded and probably not so commonly
used.
This avoids calculation of scopes on every redraw, so such tools as panning
and zoom wouldn't imply re-calculating scopes.
Implemented as a structure inside of SpaceSeq, juts like it's done for clip
and image spaces.
Also fixed zebra display to work in display space.
Added utility function to apply display transformation on image buffer's
float array which is currently only used by sequencer's scopes.
This function is multithreaded, but scopes should be improved further
since currently they're being recalculated from scratch on every draw.
- when renderlayers could not be found in save_render_result_tile() blender would crash.
- RE_engine_end_result() / rna end_result() didn't set result argument as required.
... also some style cleanup.
This means that modifier would operate on buffer which was passed to it,
without creating copy of image buffer and operating on it.
All current modifiers fit into this model and if it would need to have
original buffer on modifier calculation, that particular modifier can
create copy.
Gives some percentage of boost.
Initial idea of this input was re-designed in a bit more flexible
way using modifiers.
Also since Color Balance (which was the only thing using effect
mask input) was moved to the modifiers, this input field became
rudiment.
It's pretty tricky to write versioning code to prevent possible
data in cases this field was used, but hope it wouldn't be difficult
to switch to modifiers masks.
Having two ways to control color balance now seems a bit overkill
and not clear.
Removed old Color Balance settings from the interface and logic,
added versioning code to convert this settings to modifier.
Unfortunately, since color balance was a pointer, it's not actually
possible to preserve compatibility of old files saved in new
blender and opened back in old blender.
Hopefully there's no regressions :)
Regular rendering now works tiled, and supports save buffers to save memory
during render and cache render results.
Brick texture node by Thomas.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Textures#Brick_Texture
Image texture Blended Box Mapping.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Textures#Image_Texturehttp://mango.blender.org/production/blended_box/
Various bug fixes by Sergey and Campbell.
* Fix for reading freed memory in some node setups.
* Fix incorrect memory read when synchronizing mesh motion.
* Fix crash appearing when direct light usage is different on different layers.
* Fix for vector pass gives wrong result in some circumstances.
* Fix for wrong resolution used for rendering Render Layer node.
* Option to cancel rendering when doing initial synchronization.
* No more texture limit when using CPU render.
* Many fixes for new tiled rendering.
- Color managed RGB values wouldn't be displayed anymore for
byte images (which are currently unsupported to be managed).
- Color rectangle would now be color managed
- Sequencer was passing non-linear float to information line,
now it'll pass linear float.
This tonemap was added as a temporary option only and if it'll be
needed again, it'll be better to implement is as either a spline
in OCIO or as a film response curve (as some of such curves were
added as a presets for RGB curves in Mango production SVN).
Also revert changes made to IMB_buffer_byte_from_float since it's
not actually needed anymore and makes it's clearer changes against
trunk.
during a WM_draw. tiny is max 8* size of pointer and it is maintained at
that size. So no worries there.
* cleanup some code to be certain that deinitialization happens
correctly.
Two bugs: first, the point-in-face function had a bug that made it fail for the xz or yz planes.
Second, in ortho mode, simultaneous linehits need careful sorting.
Also, in orth mode it is somewhat random whether the edges exactly behind the front ones are reported 'hit' by bvh tree, so put in code to prevent cuts along the parallel-to-view faces when not in cut-through mode.
Issue was caused by getting image from compositor node conversion code,
now it'll check whether rendering happens and if so, frame wouldn't be
stored in the cache.
This possible fixes#32465: Memory leak when rendering
Checked by Brecht when were in Blender Institute.
Discovered when was looking into #32296: Node Texture - Node Material - GLSL Viewport rendering issue
