The issue was caused by memory optimization marking particle system to recalc,
and because of the way how particle flags works it was possible that it'll
cause particle's re-distribution. Now this memory optimization will act the
same as loading the file.
This commit appears to be safe according to our render farm and is safe to
be included into final release.
It was possible race condition on empty curves -- it's possible that curve
object is fully updated and path is null in that cases, Proper way to deal
with this is to check curve_cache for non-NULL.
It was possible that two threads will start calculating proxy group's inverted
matrix and store it in the object itself. This isn't good idea because it means
some threads might be using partially written matrix.
Currently it is just moving existing functions into a new file,
but in the future those new files will be grown much more due
to upcoming more granular scene updates.
Should be no functional changes.
Since it was not ensuring dest has valid mdisp data matching new multires modifier subdiv level...
Also, fixed a bug in `multires_subdivide()`, which would crash when trying to
increase from level 0 (aka no subdiv) to > 1 (wrong check, trying to interpolate
when it should not). And added a few sanity checks.
A Python API for the collision group / mask has been added:
```
KX_GameObject.collisionGroup
KX_GameObject.collisionMask
```
The maximum number of collision groups and masked has been increased from eight to sixteen.
This means that the max value of collisionGroup/Mask is (2 ** 16) - 1
EndObject will now activate objects that were sleeping and colliding with the removed object.
This means that, unlike now, if a rigid body starts sleeping on top of another object, when the latter is removed the rigid body will activate and fall, rather than float midair as before.
Collision groups that do not intersect used to collide on the first frame. Now this has been fixed so that they collide appropriately.
Thanks to agoose77 for his help.
Reviewers: scorpion81, hg1, agoose77, sergof
Reviewed By: agoose77, sergof
Subscribers: sergof, moguri
Projects: #game_physics, #game_engine
Differential Revision: https://developer.blender.org/D1243
This change introduces a new hysteresis parameter that it will be added
or subtracted to/from the LOD distance to avoid popping when a LOD
object moves close to the LOD transition continuously.
Then, we have the following:
- a new LOD Hysteresis setting per scene (default 10%) which is located
in Scene context --> Level of Detail panel. This scene parameter also
will active/deactive the scene hysteresis.
- and a new LOD Hysteresis setting per object (default 10%) which is
located in Object context --> Levels of Detail panel. The LOD hysteresis
setting per object (if active) will overwrite the hysteresis setting per
scene value.
For the new blends: the hysteresis setting per scene would be active by
default and the per object would be inactive by default.
For the old blends: both hysteresis settings (per scene and per object)
would be inactive by default. A quick way to take advantage of this
feature for old blends would be to activate the hysteresis parameter in
the scene context -> Level of Detail panel
Reviewers: campbellbarton, kupoman, moguri
Reviewed By: kupoman, moguri
Subscribers: nonamejuju, lordodin
Differential Revision: https://developer.blender.org/D957
General idea is to avoid actual calculation from property update()
callback and tag things for update later instead.
That said, pose constraint flags are now tagged for update and
handled as a part of object update. In the new depsgraph it'll
be a nice dedicated operation node.
Also avoid updating disabled flags for all the modifiers. This
part of the path is not totally optimal since it'll still need
to iterate over bones in order to get pchan, but to optimize it
further would be nice to find a way to avoid pchan requirement
all together.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1191
Issue this commit is addressed to is that particle system and particle modifier
will contain caches once derived mesh was requested and this cached data will
never be freed.
This could easily lead to unwanted memory peaks during synchronization stage
of rendering.
The idea is to have RNA function in object which would free caches which can't
be freed otherwise. This function is not intended to deal with derived final
since it might be used by other objects (for example by object with boolean
modifier).
This cache freeing is only happening in the background rendering and locked
interface rendering.
From quick tests with victor file this change reduces peak memory usage by
command line rendering by around 6% (1780MB vs. 1883MB). For rendering from
the interface it's about 12% (1763MB vs. 1998MB).
Reviewers: campbellbarton, lukastoenne
Differential Revision: https://developer.blender.org/D1121
shape instead of a brush tool.
The brush cutting tool for hair, while useful, is not very accurate and
often requires rotating the model constantly to get the right trimming
on every side. This makes adjustments to a hair shape a very tedious
process.
On the other hand, making proxy meshes for hair shapes is a common
workflow. The new operator allows using such rough meshes as boundaries
for hair. All hairs that are outside the shape mesh are removed, while
those cutting it at some length are shortened accordingly.
The operator can be accessed in the particle edit mode toolbar via the
"Shape Cut" button. The "Shape Object" must be set first and stays
selected as a tool setting for repeatedly applying the shape.
Added extra checks for constructive modifiers which might in theory cause deformation
motion blur. it's still not totally perfect but we're getting really close to what we
can do in the best case scenario.
This commit might cause some extra time being spent on scene synchronization because
there might be now some false-positive results, but render time should stay quite the
same as before (apart from cases when there is deformation happening which was not
detected before).
Propper fix reverting most of rB60e70c0c6014e5, which was only partial specific fix.
This code uses generic `BKE_id_lib_local_paths()` func to handle all possible paths.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D977
The getter of this matrix (actually, `BKE_object_matrix_local_get()`) was only correct
in case of pure-object parenting, bone parenting and such did not gave valid results.
Also cleaned up a bit setter code, was using as temp storage ob->obmat itself,
which is supposed to be a world matrix!
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D958
Only fixes the crash actually, real issue is, vparent does not handle deletion of vertices
at all currently... We'd need either some kind of static uuid for vertices, or some
mapping helpers used each time we remove or reorder verts... ugh.
Org patch by Severin (Julian Eisel).
Looks like material node trees are stored directly in the material. The
reason I thought this was fixed was because my test file didn't connect
the lamp data node in the rest of the tree.
Thanks to Campbell for catching this :)
In cases when the subsurf modifier is the last in the stack and there
are only deformation modifiers before it we can skip doing full orig
vertex lookup.
This is rather common situation here in animatic.
Vertex parent was using original non-modified nurbs list, simply because
it didn't have something else to operate with.
Now we've got deformed by pre-tessellation modifiers nurbs in the curve
cache which might be used y the vertex parent.
Root of the issue goes to the fact that bevel list calculation might drop some points
if they're at the same position. This made spline length calculation goes wrong.
Now the length of the bevel segments is stored in the bevel list, so values are
always reliable.
Initial patch by Lukas Treyer with some tweaks from me.
