The documentation for the -b/--background option incorrectly states that it
takes a <file>, however it can run also without a file with e.g. a script.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D250
Summary:
Made objects update happening from multiple threads. It is a task-based
scheduling system which uses current dependency graph for spawning new
tasks. This means threading happens on object level, but the system is
flexible enough for higher granularity.
Technical details:
- Uses task scheduler which was recently committed to trunk
(that one which Brecht ported from Cycles).
- Added two utility functions to dependency graph:
* DAG_threaded_update_begin, which is called to initialize threaded
objects update. It will also schedule root DAG node to the queue,
hence starting evaluation process.
Initialization will calculate how much parents are to be evaluation
before current DAG node can be scheduled. This value is used by task
threads for faster detecting which nodes might be scheduled.
* DAG_threaded_update_handle_node_updated which is called from task
thread function when node was fully handled.
This function decreases num_pending_parents of node children and
schedules children with zero valency.
As it might have become clear, task thread receives DAG nodes and
decides which callback to call for it.
Currently only BKE_object_handle_update is called for object nodes.
In the future it'll call node->callback() from Ali's new DAG.
- This required adding some workarounds to the render pipeline.
Mainly to stop using get_object_dm() from modifiers' apply callback.
Such a call was only a workaround for dependency graph glitch when
rendering scene with, say, boolean modifiers before displaying
this scene.
Such change moves workaround from one place to another, so overall
hackentropy remains the same.
- Added paradigm of EvaluaitonContext. Currently it's more like just a
more reliable replacement for G.is_rendering which fails in some
circumstances.
Future idea of this context is to also store all the local data needed
for objects evaluation such as local time, Copy-on-Write data and so.
There're two types of EvaluationContext:
* Context used for viewport updated and owned by Main. In the future
this context might be easily moved to Window or Screen to allo
per-window/per-screen local time.
* Context used by render engines to evaluate objects for render purposes.
Render engine is an owner of this context.
This context is passed to all object update routines.
Reviewers: brecht, campbellbarton
Reviewed By: brecht
CC: lukastoenne
Differential Revision: https://developer.blender.org/D94
The problem is that the animation curves are first before object updates,
where BKE_pose_rebuild and proxy synchronize will undo the animation when the
proxy is evaluted for the first time after loading.
This is somewhat of a workaround but it's also useful to have the scene updated
once when opening in background mode, and it makes rendering from the UI and
background more similar and so more predictable to give the same result.
Summary:
Old idea with changes since previous release tag
didn't work good enough. In most of the cases tag
was done in a branch hence not actually reachable
from the master branch.
Now change since release is gone, and date of
the latest commit is used instead.
The date is displayed in format YYYY-MM-DD HH:mm
in the splash.
New bpy.app fields:
- build_commit_timestamp is an unix timestamp of
the commit blender was build from.
- build_commit_date is a date of that commit.
- build_commit_time is a time of that commit.
Reviewers: campbellbarton
Differential Revision: http://developer.blender.org/D5
- Use commit number since last annotated tag as a
revision number replacement. It'll eb followed
by 'M' symbol if there're local modification in
the source tree.
- Commit short SHA1 is included. Helps getting
information about commit used to build blender
with much faster.
- If build is not done from master branch, this also
will be noticed in the splash screen.
This commit also replaces revision stored in the
files with git-specific fields (change and hash).
This is kind of breaks compatibility, meaning
files which were saved before this change wouldn't
display any information about which revision they
were saved with. When we'll finally switch to git,
we'll see proper hash and change number since
previous release in the files, for until then
svn version will be used as a change number and
hash will be empty.
Not a huge deal, since this field was only used
by developers to help torubleshooting things and
isn't needed for blender itself.
Some additional tweaks are probably needed :)
Release builds will now use lock-free allocator by
default without any internal locks happening.
MemHead is also reduces to as minimum as it's possible.
It still need to be size_t stored in a MemHead in order
to make us keep track on memory we're requesting from
the system, not memory which system is allocating. This
is probably also faster than using a malloc's usable
size function.
Lock-free guarded allocator will say you whether all
the blocks were freed, but wouldn't give you a list
of unfreed blocks list. To have such a list use a
--debug or --debug-memory command line arguments.
Debug builds does have the same behavior as release
builds. This is so tools like valgrind are not
screwed up by guarded allocator as they're currently
are.
--
svn merge -r59941:59942 -r60072:60073 -r60093:60094 \
-r60095:60096 ^/branches/soc-2013-depsgraph_mt
Move static variables to context filling in by this fcuntion
and owned by a callee function. This ensures no conflicts
between threads happens because of static variables used in
this function.
Also moved modifier types and virtual modifiers data to a
function called from creator. This is needed to be sure all
the information is properly initialied to the time when
threads starts to use this data.
--
svn merge -r57899:57900 ^/branches/soc-2013-depsgraph_mt
with other applications launching SDL applications from Blender.
At the time this was added the game engine joystick code was unnecessarily
initializing the SDL video subsystem, and looking at the SDL source code that's
the only place this environment variable is read. That doesn't happen anymore,
though we do have WITH_GHOST_SDL now. But the environment variable is set after
GHOST has been initialized, otherwise this code would have actually broken that.
- script execution is off by default
- if a blend file attempts to execute a script
this shows a message in the header with the action
that was suppressed (script/driver/game-autostart) and 2 buttons to either reload the file trusted, or to ignore the message.
- the file selector will always default to use the trust setting in the user preferences,
but reloading an open file will keep using the current setting (whatever was set before or set on the command-line).
- added SCons setting WITH_BF_PYTHON_SECURITY, this sets the default state for the user prefereces not to trust blend files on load.
... this option was in CMake before, but always off, now its enabled by default for SCons and CMake, and forced on in CMake for now.
Need to initialize FFmpeg for animation player.
This is a bit confusing, but the only way to do this
properly and clear is to call IMB_ffmpeg_init from
playback_mode command line callback.
This is because this callback is blocking and
"usual" FFmpeg initializetion (which happens after
command line parsing) was never called.
Could be switched to separate FFmpeg initializtion
and debug level set but let's keep simple for now.
The feature "Keep Session" was also loading that session when you double-click
on a .blend to open it, or when a .blend file was on commandline.
Moved this feature to the main() in creator.c, so it can check on it properly, skipping the
kept session when a file was loaded.
Conflicts resolved:
source/blenderplayer/bad_level_call_stubs/SConscript
Partly reverted changes to intern/cycles/blender/addon/ui.py in revision 52899
to make it easier to merge trunk changes.
Issue is sharing using global random generator which is shared with
particle system which resets the seed due to some scene/option
combination. Since it may be desirable to get predictable results with
particles, made sure brushes allocate their own random number generator
on startup and use that for jittering.
- update man page for new additions since last release.
- note that --start-console argument is windows only.
- correct own assertion in own recent commit.
