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.
Changed curve active point from pointer to index. Allows curve active point to be saved to file and retained between modes for free. Also some small optimisations by removing pointer look up code.
- Made active point access functions into BKE API calls.
- Fixes operators where curve de-selection resulted in unsel-active point.
- Split curve delete into 2 functions
There were several issues with how bounding box and texture space
are calculated:
- This was done at the same time as applying modifiers, meaning if
several objects are sharing the same curve datablock, bounding
box and texture space will be calculated multiple times.
Further, allocating bounding box wasn't safe for threading.
- Bounding box and texture space were evaluated after pre-tessellation
modifiers are applied. This means Curve-level data is actually
depends on object data, and it's really bad because different
objects could have different modifiers and this leads to
conflicts (curve's data depends on object evaluation order)
and doesn't behave in a predictable way.
This commit moves bounding box and texture space evaluation from
modifier stack to own utility functions, just like it's was done
for meshes.
This makes curve objects update thread-safe, but gives some
limitations as well. Namely, with such approach it's not so
clear how to preserve the same behavior of texture space:
before this change texture space and bounding box would match
beveled curve as accurate as possible.
Old behavior was nice for quick texturing -- in most cases you
didn't need to modify texture space at all. But texture space
was depending on render/preview settings which could easily lead
to situations, when final result would be far different from
preview one.
Now we're using CV points coordinates and their radius to approximate
the bounding box. This doesn't give the same exact texture space,
but it helps a lot keeping texture space in a nice predictable way.
We could make approximation smarter in the future, but fir now
added operator to match texture space to fully tessellated curve
called "Match Texture Space".
Review link:
https://codereview.appspot.com/15410043/
Brief description:
http://wiki.blender.org/index.php/User:Nazg-gul/GSoC-2013/Results#Curve_Texture_Space
Added surface support to recent curve split operator, completing quick hack todo
Updated nurbs separate operator to make use of new split logic, completing tools todo
Added 'Delete segment' option to surfaces and improved surface duplication, used for split/separate
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.
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
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
- add support for using the active point's orientation.
- add support for creating new custom orientations from curves.
- fix error where only the last selected curve handle was taken into account for manipulator orientations.
modifiers with text/curve/surface objects.
This is because the code here did not yet support the distinction between
generating the tesselated mesh at viewport/render resolution and generating a
separate displist/derivedmesh for render that is not stored in the object but
created and freed on the fly.
Without this, bezier curves at 12 resolution are very high detail for many tasks when converted from freehand strokes.
so add the option to convert 1:1 grease pencil points to curve polygons.
also add use_handles option to curve conversion which is used when converting beziers to poly lines.
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!
- Make sure functions are named in way BKE_<object>_<action> (same way as RNA callbacks)
- Make functions which are used by mball.c only static and remove their prototypes
from public header file.
Further cleanup is coming.
This commit updates curve datablock to respect curve dimension flag
when setting datablock for curve.
Not ideal but this makes behavior quite expected, avoids big changes in
curves core stuff which depends on object type and prevents restrictions
on changing data datablock which works in general cases.
- The object ID was being passed to the data_delete_material_index_id() from object_remove_material_slot(), rather then the object data. (so the material slot fix wouldnt run in that case).
- add support for fixing text object materials too.
