Reading rest of the code, it's obvious we want to start à YOFF lines
from start of rect2i, so we have to also multiply by number of
components.
Also did some minor cleanup.
Code was not accounting for possibilities that width or height of given
buffers may be smaller than XOFF/YOFF...
Note that I seriously doubt that drop code actually works (as in, gives
expected results) when applied to tiles like it seems to be done
currently, but this is much more complex (and involved) topic.
Many checks for out->rect_float being [non-]NULL are done back-to-back.
Combining them into a single check for slightly more efficient code and
less code clutter for easier readability/understanding.
Differential Revision: https://developer.blender.org/D2097
This way it's possible to have some color-correction modifications on
top of the render result and yet still have proper metadata stored.
Usecase: Access per-frame render-time of the movie frames from the
final export.
Apply X and Y blur as separate step, this reduces number of accumulations
required and makes effect more realtime.
Another quick thing for the Nieve project.
- Adds support for word wrapping to Blender's BLF font library.
- Splits lines when width limit is reached or on explicit \n newlines.
Details:
- Word wrapping is used when `BLF_WORD_WRAP` flag is enabled.
- There is a single loop to handle line wrapping,
this runs callback, passing in a substring,
this way we can avoid code-duplication for all word-wrapped
versions of functions... OR... avoid having to add support
for word-wrapping directly into each function.
- The `ResultBLF` struct was added to be able to get the number
of wrapped lines, when calling otherwise unrelated functions
such as `BLF_draw/BLF_width/BLF_boundbox`,
which can be passed as the last argument to `BLF_*_ex()` functions.
- The `ResultBLF` struct is used to store the result of drawing
(currently only the number of lines wrapped, and the width).
Deviding two ints together never yields a float... Also, logic of various proxies size corrections was quite broken.
Now we should always get the same (relative) size of text whatever proxy setting/render scale is chosen.
- default alignment to lower center.
- placement is now relative,
so changing output size keeps correct placement.
- instead of center override, add align option (left/right/center).
Also don't use pixel-size for setting the font size, on new strips.
Better not have UI prefs impact low level API's.
Is pretty much what it says :)
Easy subtitles for everyone!
Supports size, positioning,
a cheap shadow effect (probably will need more work),
and autocentering on x axis.
Now you can go wild with long spanish names
in your soap opera videos.
Will probably be refined as days go by,
but at least it's now ready for testing.
Code here calculated speed based on underlying strip start position,
which was not really visible, making prediction of the result really
difficult. Things here are simple: As long as the strip exists,
manipulate the current frame by the provided factor.
Fix alpha under equation according to porter-duff and user docs that
state that effect should invert he order of channels and reduce to alpha
over when factor is 1.0.
BTW, we don't really expose any factor here...lost feature from 2.49?
Currently this gaussian blur implementation accumulates values in the
square kernel rather that doing X direction and then Y direction because
of the lack of using multiple-staged filters.
Once we can we'll implement a way to apply filter as multiple stages we
can optimize hell of a lot in here.
Another thing we can do is to use SSE2 instructions here.
This patch changes most of the reamining degrees usage in internal code into radians.
I let a few which I know off asside, for reasons explained below - and I'm not sure to have found out all of them.
WARNING: this introduces forward incompatibility, which means files saved from this version won't open 100% correctly
in previous versions (a few angle properties would use radians values as degrees...).
Details:
- Data:
-- Lamp.spotsize: Game engine exposed this setting in degrees, to not break the API here I kept it as such
(using getter/setter functions), still using radians internally.
-- Mesh.smoothresh: Didn't touch to this one, as we will hopefully replace it completely by loop normals currently in dev.
- Modifiers:
-- EdgeSplitModifierData.split_angle, BevelModifierData.bevel_angle: Done.
- Postprocessing:
-- WipeVars.angle (sequencer's effect), NodeBokehImage.angle, NodeBoxMask.rotation, NodeEllipseMask.rotation: Done.
- BGE:
-- bConstraintActuator: Orientation type done (the minloc[0] & maxloc[0] cases). Did not touch to 'limit location' type,
it can also limit rotation, but it exposes through RNA the same limit_min/limit_max, which hence
can be either distance or angle values, depending on the mode. Will leave this to BGE team.
-- bSoundActuator.cone_outer_angle_3d, bSoundActuator.cone_inner_angle_3d: Done (note I kept degrees in BGE itself,
as it seems this is the expected value here...).
-- bRadarSensor.angle: Done.
Reviewers: brecht, campbellbarton, sergey, gaiaclary, dfelinto, moguri, jbakker, lukastoenne, howardt
Reviewed By: brecht, campbellbarton, sergey, gaiaclary, moguri, jbakker, lukastoenne, howardt
Thanks to all!
Differential Revision: http://developer.blender.org/D59
- Add and subtract effects will now affect on only RGB channels,
and alpha of first input is used as an alpha for the result.
Also solved creepyness with straight->premul->straight conversion
in byte versions of add/subtract.
- Solved issue with multiply modifier, which lead to white*white
not being white (was off by 1.0/255) due to wrong optimization
of division by 255 with shr by 8.
According to Ton this issue goes back to 2000!
This fixes#34811: Wrong result of add/subtract effects
Couple of precision issues here:
- Interpolation was rounding trunkcating colors, and because
of some precision issues value 254.999 became 254 leading
to troubles later.
Now color interpolaiton will do rounding to nearest int.
- Subtract was setting channels to something negative which
confused color management (especially negative alpha),
Now subtract effect will clamp channels to 0 from bottom
and also do some tricks to prevent small alpha which
could also confuse color management.
Made small tweaks which now limits blur width in a way it can not
be wider than distance between frame boundary and wipe effect center.
It eliminates weirdeness of how blur appears/disappears in cases
effect fac is close to 0/1.
Could be tweaked further but will require effect rewrite it seems.
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.
