calls: bisect, duplicate, scale, flip, weld.
resolves report [#36475] Symmetrise does not keep uv/weight
also fixes issues with faces that cross the axis more then once.
- plane_point_side_v3(), a bit like line_point_side_v2()
- isect_point_planes_v3(), moved from paint_hide.c
functions to convert between point/normal pairs.
- plane_from_point_normal_v3()
- plane_to_point_normal_v3()
That was not really a bug (code working as expected), but the way tex context was handled was a bit raw, now it is much smarter:
* Default fallback context (when current one is no more valid) will now choose "most specific" ones first (i.e. material/lamp/particules before world and "others").
* When using that default fallback context, previous one is stored and we try to revive it later, if possible. Thus e.g. object[mat tex ctxt] -> empty[default world ctxt] -> object[mat tex ctxt] is now working as expected.
* However, when user explicitely or implicitely (through e.g. going to Material context...) sets a tex context, previous one is not stored, so that only default fallback context switch may later automatically revive a previous (presumably user-set) context.
Topic says it all :)
Jut implemented operator to duplicate mask points
and segments between them (exactly the same behavior
as Curve object duplication in edit mode).
Does not copy animation, but that's tricky and likely
not needed anyway.
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.
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.
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.
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.
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
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
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
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
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
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
New features:
* Bump mapping now works with SSS
* Texture Blur factor for SSS, see the documentation for details:
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/Shaders#Subsurface_Scattering
Work in progress for feedback:
Initial implementation of the "BSSRDF Importance Sampling" paper, which uses
a different importance sampling method. It gives better quality results in
many ways, with the availability of both Cubic and Gaussian falloff functions,
but also tends to be more noisy when using the progressive integrator and does
not give great results with some geometry. It works quite well for the
non-progressive integrator and is often less noisy there.
This code may still change a lot, so unless you're testing it may be best to
stick to the Compatible falloff function.
Skin test render and file that takes advantage of the gaussian falloff:
http://www.pasteall.org/pic/show.php?id=57661http://www.pasteall.org/pic/show.php?id=57662http://www.pasteall.org/blend/23501
* Replaced the Preetham model with the newer Hosek / Wilkie model:
"An Analytic Model for Full Spectral Sky-Dome Radiance" http://cgg.mff.cuni.cz/projects/SkylightModelling/
* We use the sample code data, which comes with the paper, but removed some unnecessary parts, we only need the xyz version.
* New "Albedo" UI paraemeter, to control the ground albedo (between 0 and 1).
* Works with SVM only atm (CPU and CUDA).
Example render:
http://www.pasteall.org/pic/show.php?id=57635
ToDo / Open Questions:
* OSL still uses the old model, will be done later. In the meantime it's useful to compare the two models this way.
* The new model needs a much weaker Strength value (0.01), otherwise it's white. Can this be fixed?
* Code cleanup.
This is done by fixing logic for finding the first unused element in treehash.
The blend file from [36486] also exposes a memleak, but it should be addressed separately.
