Object update used to free object-data level bounding box to trigger
it's re-calculation in the future. Such a freeing performed from
object update isn't thread-safe because mesh could be shared between
multiple objects.
Rather than freeing bounding box, tag it's as invalid, this is safe
from threading point of view and also prevents unnecessary memory
re-allocation.
Object-level bounding box is still reallocating, but think we could
change this easily in the future as well.
the way Curve.len is used at the moment is really stupid, calculate string size on save for now, but should really store the length in bytes and total number of characters.
I know this is not so much nice to have this guys hanging
around in a general Object datablock and ideally they better
be wrapped around into a structure like DerivedMesh or
something like this. But this is pure runtime only stuff and
we could re-wrap them around later.
Main purpose of this is making curves more thread safe,
so no separate threads will ever start freeing the same path
or the same bevel list.
It also makes sense because path and bevel shall include
deformation coming from modifiers which are applying on
pre-tesselation point and different objects could have
different set of modifiers. This used to be really confusing
in the past and now dtaa which depends on object is stored
in an object, making things clear for understanding even.
This doesn't make curve code fully thread-safe due to
pre-tesselation modifiers still modifies actual nurbs and
lock is still needed in makeDispListsCurveTypes, but this
change makes usage of paths safe for threading.
Once modifiers will stop modifying actual nurbs, curves
will be fully safe for threading.
This display list was only used for texture space calculation,
and even there this display list was only used for bounding
box calulation.
Since we alreayd do have boundgind box in a curve datablock
there's no reason to duplicate non-modified display list
just to calculate bounding box later, let's just calculate
boundding box at the first point.
This makes code a little be more thread-safe but curves are
still not safe for threads at all because of bevel list and
path. That would be solved later.
Added function called WM_set_locked_interface which does
two things:
- Prevents event queue from being handled, so no operators
or values are even possible to run or change. This prevents
any kind of "destructive" action performed from user while
rendering.
- Locks interface refresh for regions which does have lock
set to truth in their template. Currently it's just a 3D
viewport, but in the future more regions could be considered
unsafe, or we could want to lock different parts of
interface when doing different jobs.
This is needed because 3D viewport could be using or changing
the same data as renderer currently uses, leading to threading
conflict.
Notifiers are still allowed to handle, so render progress is
seen on the screen, but would need to doublecheck on this, in
terms some notifiers could be changing the data.
For now interface locking happens for render job only in case
"Lock Interface" checkbox is enabled.
Currently this option would only make rendering thread-safe, but
in the future more benefits are possible to gain from it. Namely,
if we'll make renderer using it's own graph, this option would
allow to free memory used by 3D viewport graph, which would help
keeping memory usage low (or even would allow renderer not to
copy anything in this case).
Initially thought this change will also allow to free DMs used
by viewport, but we couldn't actually do this. This is because
of modifiers which uses other objects (like boolean), They're
in fact using viewport DM. This is bad because of few reasons.
We currently need to have viewport DM when rendering.
And for sure even in background render viewport DMs are being
calculated. This sounds like 2x computing is needed: one is for
viewport DM and one is for RenderDM.
If we'll have local graphs, we'll be able to compute RenderDMs
only and store them in graph. This would require a bit more of
the memory, but would solve current issues with viewport DM
used for modifiers operands while rendering and it should give
quite noticeable speedup.
Other tools like backing would also benefit of this option,
but rather get approval of current way of locking first.
linked via material
Textures linked to modifiers are now shown in the AnimEditor channel hierarchy
under object level now (i.e. on same level as ob-data, shapekeys, and object's
action). This makes it possible to edit such animation data without having to
ensure that these textures are also linked to the object's material so that they
will appear.
As a side-effect of how this is implemented, if playback is slower on scenes
following this commit, disable the "modifier" filter under the filtering
settings in the relevant animation editor header. In particular, it may be
beneficial to disable this when you've got scenes with meshes that have many
modifiers (but none of these have any linked data with settings which can be
animated), as Blender will still try to go through all those modifiers checking
for anything to show.
Implements an automatic keyframe selection algorithm which uses
couple of approaches to find out best keyframes candidates:
- First, slightly modifier Pollefeys's criteria is used, which
limits correspondence ration from 80% to 100%. This allows to
reject keyframe candidate early without doing heavy math in
cases there're not much common features with first keyframe.
- Second step is based on Geometric Robust Information Criteria
(aka GRIC), which checks whether features motion between
candidate keyframes is better defined by homography or
fundamental matrices.
To be a good keyframe candidate, fundamental matrix need to
define motion better than homography (in this case F-GRIC will
be smaller than H-GRIC).
This two criteria are well described in this paper:
http://www.cs.ait.ac.th/~mdailey/papers/Tahir-KeyFrame.pdf
- Final step is based on estimating reconstruction error of
a full-scene solution using candidate keyframes. This part
is based on the following paper:
ftp://ftp.tnt.uni-hannover.de/pub/papers/2004/ECCV2004-TTHBAW.pdf
This step requires reconstruction using candidate keyframes
and obtaining covariance matrix of 3D points positions.
Reconstruction was done pretty much straightforward using
other simple pipeline routines, and for covariance estimation
pseudo-inverse of Hessian is used, which is in this case
(J^T * J)+, where + denotes pseudo-inverse.
Jacobian matrix is estimating using Ceres evaluate API.
This is also crucial to get rid of possible gauge ambiguity,
which is in our case made by zero-ing 7 (by gauge freedoms
number) eigen values in pseudo-inverse.
There're still room for improving and optimizing the code,
but we need some point to start with anyway :)
Thanks to Keir Mierle and Sameer Agarwal who assisted a lot
to make this feature working.
The Emission panel now has a Use Modifier Stack option to emit particles from
the mesh with modifiers applied. Previously particles would only be emitted from
faces that exist in the original mesh. There are some caveats however:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.68/Tools#Particles
Previously it was nearly impossible to have fast moving objects emitting smoke or they would just leave behind a row of smoke poofs instead of continious stream of smoke. Now it's possible to set number of subframes for each smoke flow.
Another new thing is ability to set size of smoke flow particles instead of using closest smoke cell. This also works with my earlier "full sample" commit, so no more blocky particles either. :)
For more info check my blog post: http://www.miikahweb.com/en/blog/2013/05/17/blender-smoke-subframes
This commit also includes couple of fixes I spotted while testing:
* Fix: dissolve was applied at different time for low res and high res simulations.
* Fix: full sample setting didn't get copied with domain.
So now, in the new "other" tex context, you can (depending on active data) have direct access to modifiers', force's or brushes' textures...
I also refactored a bit how texture contexts are handled (once again, we had some quite similar code in both space_buttons and RNA sources). This should also solve some harmless glitches like "no texture context selected in UI" sometimes when you remove data related to current texture (see e.g. after removing the material from default cube, in startup scene).
This usage of two different systems for textures, and the handling of switches between them, has been a bit tricky to get working right, but it is OK now I think. I also had to add a bool flag to buttons space, SB_TEX_USER_LIMITED (use_limited_texture_context in RNA), which indicates "new shading" texture code whether it has to ignore materials, lamps etc. (BI) or not (Cycles).
Btw, pinned textures from modifiers/force/etc. were also broken (showing nothing), now it should work too.
Thanks to Brecht for reviewing.
The issue here was that the "active" material node depends on the editor context. Previously (< 2.67) there was only 1 edited node group possible globally throughout Blender, so the active material in the context could be resolved more easily. The solution now involves the active_viewer_key variable (first introduced for compositor viewer nodes in r56271, naming is a bit awkward but hard to change in DNA). This key defines the "last modified" node tree to resolve ambiguity of active context items. For single editors the result is the same as in 2.66, if multiple editors are used with different node groups the last modified tree is used.
* Particles did not render at viewport resolution like meshes.
* Properties editor preview render of hair was crashing, solution is to have
two separate flags for this preview render and viewport preview render.
This is hopefully the ultimate solution against smoke blockiness near emitter.
Previously high resolution flow/emitter voxels were generated based on the low resolution ones. So if you had 32 resolution and 4 division high resolution, it still used smoke flow generated from those 32 resolution voxels. Now I introduced a new sampling method called "Full Sample" that generates full resolution flow for for high resolution domain as well.
Read more about it in my blog post: https://www.miikahweb.com/en/blog/2013/05/10/getting-rid-of-smoke-blockiness
Also changed "quick smoke" operator default voxel data interpolation mode to "Cubic B-Spline" to smoothen out it even more.
This modifier uses a mask set in the modifier settings
and multiplies strip by it. Alpha channel will also be
multiplied by mask, which makes it easy to mask some
objects on footage and alpha-over them in sequencer.
Actually, this modifier sets alpha for byte strips
directly (since byte is always straight alpha) and
multiplies float buffer by mask (flaots are premulled)
so in both cases masked strip could be easy alpha-overed
without any artifacts.
It uses own structure with only SequenceModifierData
property in to preserve both forward and backwards
compatibilities (using new structure ensures modifier
will be ignored on load in older blenders, the same
happens for mesh modifiers actually).
Request from Pablo Vazquez.
Also removed unneeded image buffer scaling, it was only needed
for "early output" if there was no rotation. That is no longer
supported since it used to pixelate result a lot and interpolation
is always used now.
Saves quite a few of memory and CPU cycles.
It's now default to 2D textures, and no AUTO mode at this
moment, since detecting which method is the best not so
simple.
Image drawing could manually be switched to GLSL for tests
and feedback, but for default GLSL is not so much great.
Reason of this is huge images, where operations like panning
becomes dead slow comparing GLSL vs. 2D texture.
Added a mutex lock for smoke data access. The render was already working with a
copy of the volume data, so it's just a short lock to copy things and should not
block the UI much.
The design changes coming with pynodes for the node editor allow editing multiple node groups or pinning. This is great for working on different node groups without switching between them all the time, but it causes a problem for viewer nodes: these nodes all write to the same Image data by design, causing access conflicts and in some cases memory corruption. This was not a problem before pynodes because the editor would only allow 1 edited node group at any time. With the new flexibility of node editors this restriction is gone.
In order to avoid concurrent write access to the viewer image buffer and resolve the ambiguity this patch adds an "active viewer key" to the scene->nodetree (added in bNodeTree instead of Scene due to otherwise circular DNA includes). This key identifies a specific node tree/group instance, which enables the compositor to selectively enable only 1 viewer node.
The active viewer key is switched when opening/closing node groups (push/pop on the snode->treepath stack) or when selecting a viewer node. This way only the "last edited" viewer will be active.
Eventually it would be nicer if each viewer had its own buffer per node space so one could actually compare viewers without switching. But that is a major redesign of viewer nodes and images, not a quick fix for bcon4 ...
properties were continuously redrawing, which slowed down everything else.
The problem was integer overflow, with a short only capable of storing values
up to 32767. Note that sockets are collapsed by default since the previous
release, and that's it's not very useful to edit such complex node setups in
the properties editor, it's mainly meant for simple setups or group nodes to
present just a few sockets.
