| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
|
Move static variables to context filling in by this fcuntion
and owned by a callee function. This ensures no conflicts
between threads happens because of static variables used in
this function.
Also moved modifier types and virtual modifiers data to a
function called from creator. This is needed to be sure all
the information is properly initialied to the time when
threads starts to use this data.
--
svn merge -r57899:57900 ^/branches/soc-2013-depsgraph_mt
|
|
|
|
|
|
from an index.
- BKE_lattice_index_from_uvw()
- BKE_lattice_index_to_uvw()
|
|
by Kevin Mackay (yakca)
Was one of our TODO's from the wiki.
|
|
- mult_m4_m4m4 -> mul_m4_m4m4
- mult_m3_m3m4 -> mul_m3_m3m4
these temporary names were used to avoid problems when argument order was switched.
|
|
|
|
Fixes small precision problems.
|
|
Issue was caused by couple of circumstances:
- Normal Map node requires tesselated faces to compute tangent space
- All temporary meshes needed for Cycles export were adding to G.main
- Undo pushes would temporary set meshes tessfaces to NULL
- Moving node will cause undo push and tree re-evaluate fr preview
All this leads to threading conflict between preview render and undo
system.
Solved it in way that all temporary meshes are adding to that exact
Main which was passed to Cycles via BlendData. This required couple
of mechanic changes like adding extra parameter to *_add() functions
and adding some *_ex() functions to make it possible RNA adds objects
to Main passed to new() RNA function.
This was tricky to pass Main to RNA function and IMO that's not so
nice to pass main to function, so ended up with such decision:
- Object.to_mesh() will add temp mesh to G.main
- Added Main.meshes.new_from_object() which does the same as to_mesh,
but adds temporary mesh to specified Main.
So now all temporary meshes needed for preview render would be added
to preview_main which does not conflict with undo pushes.
Viewport render shall not be an issue because object sync happens from
main thread in this case.
It could be some issues with final render, but that's not so much
likely to happen, so shall be fine.
Thanks to Brecht for review!
|
|
|
|
- free_dverts -> BKE_defvert_array_free
- copy_dverts -> BKE_defvert_array_copy
also move the functions from BKE_mesh into BKE_deform
|
|
now blenlib/BLI doesn't depend on any blenkern/BKE functions,
there are still some bad level includes but these are only to access G.background and the blender version define.
|
|
|
|
|
|
checking >= 0.
also remove unused bmesh decimator code.
|
|
|
|
|
|
have been removed by accident as code has been updated.
|
|
|
|
also fix for building ghost test and fix double free in one of the tests
|
|
|
|
|
|
replace do prefix with do_ for bool vars.
|
|
vector function edits.
|
|
to pass options, instead of having one parameter per boolean flag (i.e. replaces current useRenderParams and isFinalCalc by a single ModifierApplyFlag flag. ModifierApplyFlag is an enum defined in BKE_modifier.h). This way we won't anymore have to edit all modifier files when e.g. adding a new control flag!
Should have no effect over modifier behavior.
|
|
|
|
|
|
also use ..._find_name(..., name) rather then ..._find_named(..., name) --- both were used.
|
|
|
|
|
|
- replace inline face UV center calc.
- use const float[3] for mesh and uv functions.
- remove unused define
|
|
call it strength too)
|
|
* This patch adds a influence slider for the lattice modifier, which affects the strength of the deformation.
Patch by Patrick Boelens (senshi), thanks a lot!
|
|
else if's
|
|
|
|
|
|
|
|
use 0-5. (confusion here casued an error in the code).
make calc_curve_deform use 0-5 too, only minor changes needed.
|
|
|
|
cases?
the curve modifier was applying the offet between the mesh and the curve object twice.
for positive axis it was (offset+offser), for neg axis (offset-offset) --- giving no offset,
in both cases not very useful.
|
|
groups were used.
|
|
comments is silly, may as well have in declaration)
|
|
inconsistent with similar functions & math notation:
mul_m4_m4m4(R, B, A) => mult_m4_m4m4(R, A, B)
mul_m3_m3m4(R, B, A) => mult_m3_m3m4(R, A, B)
For branch maintainers, it should be relatively simple to fix things manually,
it's also possible run this script after merging to do automatic replacement:
http://www.pasteall.org/27459/python
|
|
broke forward compatibility. now the new values are copied into 'dscale' and existing ones remain.
this is annoying since now we have dsize and dscale, will look into a way to deprecate struct members next.
|
|
was an error with make-local refactor & path updating.
|
|
- remove unneeded type check from convert grease pencil operator.
- correct some error prints & use __func__.
- make copy_libblock take an ID* argument rather than void*.
|
|
also removed some unused function definitons.
|
|
so path manipulation functions dont run multiple times on the same path in the case of sequence strips where the one directory is used as the base for many images.
|
