It's quite tricky to see if the driver actually depends on time or not,
so currently used approach when we'll be doing some extra updates.
This seems to correspond to how old depsgraph was dealing with this.
This is essential for video projection, and the alternative until now was to manually change the projection matrix via Python.
( http://www.blender.org/manual/game_engine/camera/introduction.html#camera-lens-shift
- this page will be removed as soon as I commit this)
Also this is working for perspective and orto cameras BUT if the sensor is not AUTO it will only look correct in blenderplayer (this is an unrelated bug, but just in case someone runs into it while testing this, now you know why you got the issue).
Kudos for the BlenderVR project for supporting this feature development.
Differential Revision: https://developer.blender.org/D1379
Parallel rendering was not working.
The idea of having parallel convergence mode to render as parallel but
visualize as off-axis was good, but it was leading to some complications
in the code.
I think it's more clear to the user if parallel looks and render as
parallel, and if she wants to pre-visualize the converged planes, simply
temporarily set the camera to off-axis.
'ar->winy' may not be initialized, making regions zoom in (past limits)
and attempt to draw very large text (~10x10k size characters), often crashing.
Fix isn't complete since it only corrects factory startup.
Angular velocity clamping was missing from the BGE. It is implemented
similarly to the linear velocity clamping. It is needed to be able to
drive physical simulations of systems that have a limited rotational
speed.
Reviewed by: campbellbarton, panzergame, ton
Differential Revision: https://developer.blender.org/D1365
Simply backport small part of work from asset-experiments here (using double and
adding tera-bytes unit), looks like off_t is not always 64bits even on a 64bit OS...
With multiview/multilayer OpenEXR file, `load_image_single()` will return NULL ibuf,
since it has already populated ima (with `image_create_multiview()` or
`image_create_multilayer()` calls).
Also, added some more checks before doing `IMB_ImBufFromStereo3d()`, to be sure
we do have enough slots in ibuf_arr, and we do not overwrite second ibuf either.
Issue is data race between preview job and GPU nodetree evaluation when
localizing the nodetree. Data race happens due to localizations doing
overrides on original nodes' new_node variable.
Solution here could probably be to use a hash for mapping of old to new
nodes but will prefer simple brute force lock for now.
This reverts commit 0e02ad8b64.
Initial commit was done so visual result fits with animation cursor
in timeline but this makes it so it looks like one extra frame is
rendered. Other idea would be to render one less frame for sequencer
but this is not so nice either. Generally here's no way to be
fully consistent here, but at least let's be workflow-consistent
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.
Now we use color converted (if we do a color management) by the setter for background color in VideoTexture (ImageRender & ImageMirror).
Reviewers:panzergame
