| Age | Commit message (Collapse) | Author |
|---|
|
concurrency.
Note: this commit seems to work as expected (also with transform
snapping etc.). However, it is rather unsafe - not enough for 2.79 at
least, unless we get much more testing on it. It also depends on three
previous ones.
Note that using a global lock here is far from ideal, we should rather
have a lock per DM, but that will do for now, whole DM thing is doomed
to oblivion anyway in 2.8.
Also, we may need a `DM_DIRTY_LOOPTRIS` dirty flag at some point. Looks
like we can survive without it for now though... Probably because cached
looptris are never copied accross DM's?
|
|
That one was doing exactly same thing as `dm->getLoopTriArray()`, no
point in having twice the same code here...
|
|
arrays again from DM.
This was... horribly wrong, CDDM will often *not* need to allocate
anything to return arrays of mesh items! Just check whether array
pointer is NULL.
Also, remove `DM_get_looptri_array`, that one is useless currently,
`dm->getLoopTriArray` will always return cached array (computing it if
needed).
|
|
All three functions were doing exactly the same thing, simpler to only
have one in that case!
|
|
Need some extra checks and should be probably end up in 2.79 since that's a regression.
|
|
Baking rigid body cache was broken if some cached frames already
existed.
This is just a band aid for release, the logic need to be looked into
further.
|
|
break the simulation
Revert 9cd6b03, 3edc8c1, b87d10d and do a better fix for T50230.
|
|
Shrinkwrap must check it does have valid target data.
Safe for 2.79 release.
|
|
after file save and reload.
Issue was nasty hidden one, the dual status (mix of local and linked)
of proxies striking again.
Here, remapping process was considering obdata pointer of proxies as
indirect usage, hence clearing the 'LIB_TAG_EXTERN' of obdata pointer.
That would make savetoblend code not store any 'lib placeholder' for
obdata data-block, which was hence lost on next file read.
Another (probably better) solution here would be to actually consider
obdata of proxies are fully indirect usage, and simply reassign proxies
from their linked object's obdata on file read...
However, that change shall be safer for now, probably good for 2.79 too.
|
|
It is possible to have same image used multiple times at different frames,
which means we can not free it's buffers without any guard. From quick tests
this seems to be doing what it is supposed to.
Need more testing and port this to 2.79.
|
|
Regression from rBfed853ea78221, calling this inside thread worker was
not really good idea anyway, and we already have all the code we need in
pre-threading init function, was just disabled for vertex particles
before.
To be backported to 2.79.
|
|
The new method while improved for solid objects
doesn't work for non-manifold meshes, keep both.
|
|
The '..' in the path caused simple comparisons to fail.
D2780 by @akitula
|
|
Rendered settings.
'OpenGL Preview' checkbox was redundant now, just use seq_prev_type
value only.
Might be OK for 2.79, but should be double-checked first...
|
|
Lost specific MBall 'need update' case here in last year's refactor.
While technically not a regression, nice to have in 2.79.
|
|
Not a regression, but safe enough to be included in 2.79.
|
|
This is still far from prefect, but yet much better than what we had so
far (more consistent with inheritent precision available in floats).
Note that this fixes some (currently commented out) units unittests, and
requires adjusting some others, will be done in next commit.
|
|
|
|
* Numbers with units (especially, angles) where not handled correctly
regarding number of significant digits (spotted by @brecht in T52222
comment, thanks).
* Zero value has no valid log, need to take that into account!
|
|
Even strands that were excluded by the density texture were being added
to the DM passed to cloth, but these ended up having some invalid data,
because they were not fully constructed.
This simply excludes `UNEXISTED` particles from the DM generation, as
would be expected.
|
|
`defvert_array_find_weight_safe()` was confusing 'invalid vgroup' and
'valid but totally empty vgroup' cases.
Note that this also affected at least ShrinkWrap and SimpleDeform
modifiers.
|
|
|
|
GCC seems to detect uninitialized into function calls now, but then isn't
always smart enough to see that it is actually initialized. Disabling this
warning entirely seems a bit too much, so initialize a bit more now.
|
|
This makes sense when we want to avoid float precision error
for near co-linear edges. OTOH, this is an arbitrary decision,
so keep functions separate.
|
|
The issue was caused by combination of following factors:
- Clipboard cleanup function will pass node tree as NULL to node free
function.
This is fine on it's own, we don't have tree in clipboard.
- Node free function will call node storage cleanup only when there is
a non-NULL node tree.
This is somewhat weird, because storage cleanup does not take node
tree as argument.
So the solution here: move node storage cleanup outside of check that
node tree is not NULL.
|
|
This was serious bug actually, probably a crasher in case you free
original or copy after duplication...
|
|
particles' scene and object pointers.
imapaint's clone and canvas are refcounting Image usages.
And particle's editsettings' object and scene seem to be pure runtime
data (they are reset to NULL in readcode), so resetting them to NULL
here as well.
|
|
|
|
LineStyle usercounts.
Really, really, really need to get rid of this usercount handling
everywhere, hopefully incomming ID copying rewrite will help sanitize
that mess. But fix was needed for 2.79 release!
|
|
|
|
|
|
Fix some cases that still assumed there to be a global DPI, instead of a per
window DPI that needs to be set before reading U.dpi.
|
|
The issue was caused by combination of following factors:
- Blender Internal viewport render can not distinguish between which parts of
main database changed, so it does full database re-sync when anything is
tagged for an update.
This way, if any NodeTree (including compositor) is changed, Blender Internal
viewport is tagged for full render database update.
- With old dependency graph, scene-level drivers are evaluated on every
iteration of scene_update_tagged, even if nothing is tagged for an update.
This causes compositor drivers be evaluated quite often.
- Driver evaluation checks whether value was changed, and if so it tags
corresponding ID type as updated (this is what was telling viewport to do
render database update).
This check was quite stupid: current property value was checked against the
one coming from driver expression. This means, if driver value is outside
of the hard limit range of the property, the property will always be
considered updated.
The fix is to compare current property value against clamped value from the
driver.
|
|
Using an arbitrary face as the source of the UV data is mostly fine, as
vertices on seams will generally map to different parts of the texture
that have the same color.
This is regarding fed853ea782211298c902759ec8cd8e455d8b41d
|
|
|
|
When doing any transformation on a rigid body object that has delta
transforms, the object would be offset by the amount of the delta
transform.
|
|
Last fix only accounted for direct changes to the RB settings, but
failed for, say, object transformations. This fix accounts for any
change that might invalidate the RB cache.
|
|
Fix 9cd6b03187b91bb2c267a45eac3cee7738e0e220 introduced a bug that
prevented simulation after a cache invalidation (for instance when
changing a setting after simulating). This fixes that.
|
|
Particles were ignoring the lattice modifier visibility, and
"influence" property.
|
|
|
|
Patch by Alexander, with some refactoring by Brecht.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2709
|
|
|
|
This makes the last time (`ltime`) stored in the rigid body world (`rbw`)
only be updated once a simulation step actually occurs, this prevents
another simulation step from being solved unless the current time is
exactly one frame after the last cached frame. Thus this prevents the
formation of gaps in the cache, such as seen in T50230.
Reviewers: mont29, sergey, angavrilov
Tags: #physics
Maniphest Tasks: T50230
Differential Revision: https://developer.blender.org/D2458
|
|
dupliface in final render
DupliVert/Face were not using render DM at render time.
|
|
Now that some node types may have custom context, we need to handle that
in the (convoluted :| ) UI code of nodes as well.
Reported in T43295 by Gabriel Gazzán (@gab3d), thanks.
|
|
Fix is a bit ugly, but cannot think of another solution for now, at
least this **should** not break anything else.
And now I go find myself a very remote, high and lonely mountain, climb
to its top, roar "I hate proxies!" a few times, and relax hearing the echos...
|
|
|
|
named datablock.
This is annoying especially for exporters who do use mesh name, since it
broke any relation with actual Mesh naming in original Blend file.
Unfortunately, we cannot avoid the extra .xxx digits. ;)
|
|
Also remove duplicate & mismatching comments from grease-pencil header.
Keep comments close to implementation to avoid getting out of sync.
|
|
or dp.
Children where always getting at least one segment of fixed length...
Now fully hidden ones (zero length) get no segment at all.
Note that even very short ones keep getting one 'unit' length segment - would
rather avoid changing that at this point, given how complex children
particles 'length' can get with all kind of modifiers... Think we can
live with that for now anyway.
|
