In previous optimization in outliner I assumed that order in treehash was not important.
But testing outliner in datablocks mode revealed a problem: when user expands multiple recursive levels and then closes any element, it always closed the top level of recursion.
Now it should work fine with recursive trees.
Now treehash contains groups of elements indexed by (id,nr,type). Adding an element with the same (id,nr,type) results in appending it to existing group. No duplicates are possible in treehash.
This commit should also make lookups a little bit faster, because searching in small arrays by "used" is faster than searching in hashtable with duplicates by "id,nr,type,used".
That ended up in tricky code trying to mimic depsgraph
branch behavior API-wise preserving texspace and bound
box calculation compatible with previous releases.
So for now bring cu->disp back to the trunk but keep
texpsace and boundbox APIs the same as in the branch.
This keeps texpsapce and boundbox behavior fully compatible
with previous releases and still makes API the same as
for meshes.
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 data 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.
Actually, this commit also contains wrapping runtime curve
members into own structure
This allows easier assignment on file loading, keeps curve-
specific runtime data grouped and saves couple of bytes in
Object for non-curve types.
--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
svn merge -r57957:57958^/branches/soc-2013-depsgraph_mt
This display list was only used for texture space calculation,
and even there this display list was only used for bounding
box calculation.
Since we already do have bounding 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
bounding 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.
--
svn merge -r57939:57940 ^/branches/soc-2013-depsgraph_mt
This commit includes all the changes made for plane tracker
in tomato branch.
Movie clip editor changes:
- Artist might create a plane track out of multiple point
tracks which belongs to the same track (minimum amount of
point tracks is 4, maximum is not actually limited).
When new plane track is added, it's getting "tracked"
across all point tracks, which makes it stick to the same
plane point tracks belong to.
- After plane track was added, it need to be manually adjusted
in a way it covers feature one might to mask/replace.
General transform tools (G, R, S) or sliding corners with
a mouse could be sued for this. Plane corner which
corresponds to left bottom image corner has got X/Y axis
on it (red is for X axis, green for Y).
- Re-adjusting plane corners makes plane to be "re-tracked"
for the frames sequence between current frame and next
and previous keyframes.
- Kayframes might be removed from the plane, using Shit-X
(Marker Delete) operator. However, currently manual
re-adjustment or "re-track" trigger is needed.
Compositor changes:
- Added new node called Plane Track Deform.
- User selects which plane track to use (for this he need
to select movie clip datablock, object and track names).
- Node gets an image input, which need to be warped into
the plane.
- Node outputs:
* Input image warped into the plane.
* Plane, rasterized to a mask.
Masking changes:
- Mask points might be parented to a plane track, which
makes this point deforming in a way as if it belongs
to the tracked plane.
Some video tutorials are available:
- Coder video: http://www.youtube.com/watch?v=vISEwqNHqe4
- Artist video: https://vimeo.com/71727578
This is mine and Keir's holiday code project :)
They were caused by not having a free_windowmanager_cb set and by not having registered SpaceTypes, which meant data allocated for thosse SpaceTypes could not be freed. These were solved by defining a free_windowmanager_cb for the player that just frees wmWindows, and by making sure we only allocate memory for registered SpaceTypes.
with recent outliner optimizations (revision 58855, 3 days ago), in any Blender
version before this commit. On current Blender it would give a double free
warning in the console.
The problem is that it creates a temporary TreeStore on file save. However if you
have multiple outliners this memory block would always be at the same memory
address making it no longer unique. That then meant old memory address lookups on
file read were failing. Solution now is to postpone freeing these temporary memory
blocks until the end so that they are at unique addresses.
- performance of outliner was low because of unoptimal data structures.
- now it uses BLI_mempool instead of custom mempool and GHash to make searches for duplicates faster.
- also fix undesired behaviour of BLI_mempool_as_arrayN
thanks to Campbell Barton and Lukas Tönne for helping me get a better fix put together.
* Change overlay alphas to 33 if not initialized. This should have been
done for 2.67 but better do it now to avoid frustration with overly
transparent overlays. For users that have set this low manually this
will reset the setting to 33 but I think it's less irritating than users
who unwillingly had the setting to 1 and saw nothing when activating the
overlay.
* Allow overlay alpha to be zero as well
* Reset old, now obsolete BRUSH_FIXED flag for brushes that still use
this. I am doing this here to avoid patching hell when the paint brush
is merged, since it's not possible to know the merged version
beforehand, and this flag will be used.
existing code was very stupid.
- all ID pointers for clipboard strips are handled uniformly.
- clipboard stores a duplicate ID pointer which are restored on paste.
- restoring pointers...
-- use ID's that are still in the database (copy&paste within the same file).
-- fallback to name lookup.
-- fallback to loading them from the original filepath (movie-clip and sound only).
also fix bug pasting where initialing the sound wasn't done if there was no frame-offset.
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.
custom pynodes tree edited directly as library data would get a 0 user count on reload and subsequently not be saved. Now the node space follows the same pattern as the image space: the node tree(s) user
count gets incremented on file load and opening in the editor ensures a real user. This leads to 1 "unreal" user for the editor (dropped on reload), but seems to be the only viable solution atm.
* [#35724] Backdrop zoom can be set to a very small value, making the backdrop disapear.
There were checks in the drawnode that needed to be placed in the readfile.
The checks checked if the zoomlevel was 0.0, then it was defaulted to 1.0, but the zoomvalue had a minimum limit of 0.01, hence it did not work.
Moved the check to the readfile and checked for all values smaller then 0.02. These values are then reset to 1.0
Jeroen & Monique
- At Mind -
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.
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.
Issue was caused by ntreeUpdateTree calling for a ntree
which is not in G.main.
This lead to issues in ntreeVerifyNodes (which is called
from ntreeUpdateTree).
Made is so ntreeUpdateTree now accepts main as an argument.
Will work for the release, later we could either solve the
TODO mentioned in ntreeUpdateTree which will eliminate need
in main there or make it so context's main is used from all
over where ntreeUpdateTree is called (currently there're
still some usages of G.main).
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.
Initial fix was not fully working, because faulty
edge shared the same address as screen area. This
lead to screen freeing issues -- double free (which
was supressed by guarded allocation actually) but
also freed memory access when iterating via edges
to free them.
Solved by a small hack which removes edges with bad
vertices from edges list. This prevents double-free
and freed memory access cased by corrupted files we're
currently fixing. In other cases this tweak is likely
be harmless -- in worst case scenario it'll lead to
small memory leak, which is not as much lethal as
freed memory access.
