| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This mimics the behaviour we have in the Clip Editor.
I personally would prefer if we had no border once in fullscreen
(current border is 5 pixels).
I will consult Sergey Sharybin first to see if we can change that in the clip editor as well (though there I
believe the border is useful - the bottom of the editor is used to indicate 'tracked' frames.
|
|
before that if you pressed 'F', fit_view would be True every time (e.g.,
even if you pressed 'HOME' which is supposed to call the operator
without the fit_view).
I'm not sure why we need a fullscreen without 'fit_view' but anyways,
that's a different issue.
|
|
Simply recalc sequence len for audio (and meta!) strips when modifying fps value. Note start, startofs and endofs are also updated, to try to keep final pos and length as consistent as possible.
|
|
|
|
inset individual.
|
|
rewrite individual inset not to remove and re-create faces, makes re-selection simpler.
|
|
allocated block for more efficient reuse.
|
|
of materials when meshes are loading,
also, its possible to have values outside this range by removing materials (though not from the UI)
|
|
area of zero
|
|
|
|
|
|
The reason of this is because PATH_MAX is not guaranteed
to be defined on all platforms and Hurd doesn't define it.
So either we need to support arbitrary long file path or
we need to define own maximum path length.
The rule here would be:
- If it's not big trouble to support arbitrary long paths
(i.e. in ghost by using std::string instead of char*)
then arbitrary long path shall be implemented.
- For other cases to use PATH_MAX please include BLI_fileops.h
which takes care of making sure PATH_MAX is defined.
Additional change: get rid of own changes made yesterday
which were supposed to make storage.c work fine in cases
PATH_MAX is not define, but on the second though it lead
to unneeded complication of the code.
Thanks Campbell for review!
|
|
also enable other errors to show up which were previously commented.
|
|
gpencil_data_get_active and gpencil_data_get_active_v3d did not have consistent behavior when we had an active object, but not on any visible layer (the first would return the default scene gpd in this case, while the first was still returning active object's one). Now they both return scene's one.
|
|
initialization. In sculpt mode, when using shift-click to switch to the
smooth brush it was possible to ommit initialization of curvemapping for
that brush.
|
|
the stroke and skip checking for initialization each time we request the
curve value.
|
|
|
|
hangs Blender
Wiresize and rendersize were not handled regarding scene scale, leading to insane precision when working in cm or less...
|
|
* Actually check if normal recalculation flags exists and set it when
splitting nodes in dyntopo. Right now, nodes that need GPU buffer update
will always get in the list to get their normals generated, but to avoid
a possible future breakage better do it right now.
* Avoid keeping deleted/removed vertices in vertex-to-node and unique
vertex hashes, since some checks rely on those and may go awry if these
still exist. Also they pollute the hashes, and may hurt performance
somewhat.
|
|
|
|
It's a bit dumb to store render-time bevel list in
object's curve_cache, but that's how blender already
used to work for ages.
Proper fix is suspended for tomorrow :)
|
|
Turn off pbvh normal update flag after recalculation, saves
recalculating normals every frame when not stroking the mesh.
For this to work reliably with undo we need to support original normals
in the bm_log (was marked as a TODO already in the code), so that
undoing avoids having invalid normals in the mesh (since we don't update
every frame anymore). This was added in this commit as well.
Also added some (disabled) quite paranoid checks in the bmesh valication
code for dyntopo hoping to catch the real normal update issue. No luck
there yet.
|
|
keyframes
These are not animatable! Note this is the case of most (all?) render settings, maybe we should go over both Cycles and internal ones, there are still quite a bunch of them that are marked as animatable... :/
|
|
|
|
|
|
|
|
|
|
Was introduced by plane track merge.
|
|
G.is_rendering
|
|
No need in special hacks for this now :)
|
|
--
svn merge -r59259:59260 ^/branches/soc-2013-depsgraph_mt
|
|
- Re-arrange locks, so no actual memory allocation
(which is relatively slow) happens from inside
the lock. operation system will take care of locks
which might be needed there on it's own.
- Use spin lock instead of mutex, since it's just
list operations happens from inside lock, no need
in mutex here.
- Use atomic operations for memory in use and total
used blocks counters.
This makes guarded allocator almost the same speed
as non-guarded one in files from Tube project.
There're still MemHead/MemTail overhead which might
be bad for CPU cache utilization
|
|
Not currently used, but needed for some further changes
|
|
Particle system code used global variable to sort hair by orig index,
which is not safe for threading at all.
Replaced this with usage of reentrant version of qsort, which is
now implemented in BLI. It was moved from recast navigation code
to BLI, so more areas could use it (if needed).
--
svn merge -r59086:59087 ^/branches/soc-2013-depsgraph_mt
|
|
This commit fixes two different issues, which were caused by
how weights are being calculated for relative shapekeys.
Weights for key block used to saved in KeyBlock DNA structure,
which lead to situations when different objects could start
writing to the same weights array if they're sharing the same
key datablock.
Solved this in a way so weights are never stored in KeyBlock
and being passed to shapekeys routines as an array of pointers.
This way weights are still computed run-time (meaning they're
calculated before shapekey evaluation and freed afterwards).
This required some changes to GameEngine as well, to make it
never cache weights in the key blocks.
Another aspect of this commit makes it so weight for a given
vertex group is only computed once. So if multiple key blocks
are using the same influence vertex group, they'll share the
same exact weights array. This gave around 1.7x speedup in
test chinchilla file which is close enough to if we've been
caching weights permanently in DNA (test machine is dual-code
4 threads laptop, speedup measured in depsgraph_mt branch,
trunk might be not so much high speedup).
Some further speed is optimization possible, but it could be
done later as well.
Thanks Brecht for idea of how the things might be solved in
really clear way.
--
svn merge -r58786:58787 ^/branches/soc-2013-depsgraph_mt
|
|
When blender is built in debug mode, BLI_mempool_free will
ensure address passed to the function actually belongs to
this pool.
--
svn merge -r58710:58711 ^/branches/soc-2013-depsgraph_mt
|
|
This new macros could be used to benchmark overall
execution time of some chunk of code, running in cycle.
The usage is:
void foo(void) {
TIMEIT_BLOCK_INIT(overall_bar);
for (...) {
...
TIMEIT_BLOCK_BEGIN(over_bar);
bar();
TIMEIT_BLOCK_END(oberall_bar);
...
}
TIMEIT_BLOCK_STATS(overall_bar)
}
This would print total time which was spent on
running function bar().
--
svn merge -r58281:58283 ^/branches/soc-2013-depsgraph_mt
|
|
Apparently, some routines in armature deformation code
were using static arrays. This is probably just an
optimization thing, but it's very bad for threading.
Now made it so bbone matrices array is allocating in
callee function stack. This required exposing
MAX_BBONE_SUBDIV to an external API, This is not so
much crappy from code side, and it shall be the same
fast as before.
--
svn merge -r58278:58279 ^/branches/soc-2013-depsgraph_mt
|
|
Lattice deformation used to store some runtime data
inside of lattice datablock itself. It's something
which is REALLY bad. Ideally DNA shouldn't contain
and runtime data.
For now solved it in a way that initialization of
lattice deform will create a structure which contains
lattice object for which deformation is calculating
and that runtime data which used to be stored in
lattice datablock itself.
It works really fine for mesh deform modifier, but
there's still runtime data stored in particle system
DNA, It didn't look something easy to be solved, so
leaving this as-is for now.
--
svn merge -r58277:58278 -r58795:58796 ^/branches/soc-2013-depsgraph_mt
|
|
Code in GPU_buffers_free was already trying to be safe
for threading, by skipping OGL calls there, but in fact
it was still buggy.
Namely, freeing was doing buffers shift in a cycle, and
if two threads will call this function shifting will go
crazy.
Now made it so GPU_buffers_alloc and GPU_buffers_free
are using mutex lock, so they're completely safe for
threading. Same goes to gpu_buffer_setup function.
It required minor functions reshuffle, so there're no
locks happening from locked thread, but it's all very
straightforward change
--
svn merge -r58276:58277 ^/branches/soc-2013-depsgraph_mt
|
|
Getting vfont data wasn't safe for threading, because it
was modifying font data which is in bmain and could be
shared by multiple objects.
For now made it so getting vfont uses critical section,
meaning vfont->data is initializing from inside a locked
mutex.
--
svn merge -r58168:58169 ^/branches/soc-2013-depsgraph_mt
|
|
|
|
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.
--
svn merge -r58154:58156 -r59258:59259 ^/branches/soc-2013-depsgraph_mt
|
|
--
svn merge -r58150:58151 ^/branches/soc-2013-depsgraph_mt
|
|
Now modifier stack wouldn't modify original curve's nurbs
and will operate on a copy of nurbs.
This makes it possible to process curve object update with
shared curve datablocks from multiple threads. There's no
big overhead for creating a copy of nurbs comparing to old
behavior which was allocating original vertex array and
apply coordinates on curve after all modifier are applied.
The only remained issue with curves is curve's bounding box
and texture space. It's not thread-safe, but it wouldn't
lead to crashes -- it just could lead to either memory
leak or wrong texture coordinates due to difference in
modifiers stacks of objects which shares the same curve.
--
svn merge -r57959:57961 ^/branches/soc-2013-depsgraph_mt
|
|
So far it was harmless, but with upcoming changes having this
argument could be confusing from logic point of view
--
svn merge -r57958:57959 ^/branches/soc-2013-depsgraph_mt
|
|
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
|
|
It used to be a check for ob->bb ? ob->bb : cu->bb but
in fact it doesn't make sense and only makes code more
crappy.
Making displist for mballs and curves/surfaces/fonts
already ensures object has walid bounding box.
--
svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt
|
