Age | Commit message (Collapse) | Author |
|
|
|
T37799 Patch from Simon Repp
with added option to recalculate handle lengths.
|
|
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
|
|
selected but not the mid-point.
only one of the handles would be changed to the HD_FREE.
effected curves and fcurves.
|
|
|
|
by Kevin Mackay (yakca)
The operator follows roughly the same behaviour as the split operator for a mesh (Ykey).
|
|
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
|
|
|
|
calculations for curve handles,
- 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.
|
|
material texture
|
|
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!
|
|
|
|
wasn't needed for lattice and curves, and in some cases meshes.
do dirrect array lookups instead where possible.
|
|
|
|
|
|
- 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.
|
|
|
|
without the underscores these clogged up the namespace for autocompleation which was annoying.
|
|
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.
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
the include path from CMake & SCons.
* ED_curve_editnurbs --> curve_editnurbs
* ED_sculpt_modifiers_changed --> object_sculpt_modifiers_changed
|
|
- 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.
|
|
doubles, adjust to use floats.
|
|
|
|
flagged as PROP_THICK_WRAP.
Also use const char in many other parts of blenders code.
Currently this gives warnings for setting operator id, label and description since these are an exception and allocated beforehand.
|
|
NURBS surfaces always used resol{u,v} from spline and never used curve's render resolutions.
Now, if curve's render resolution is non-zero then it'll override resolution for all
splines when rendering (in needed direction only, ofcource).
|
|
|
|
more of a request then a bug but shows up a strange limitation with curve deform modifier,
The mesh bounding box would set the deform axis start/end to map the deformation of the curve to. This means it ignored offset in the object location and object data location (you could use a dummy vertex to trick it).
Old files wont change, added an option (next to stretch), called 'Bounds Clamp', old files have this behavior but newly made curves have it disabled.
Double checked this gives useful results with stretch on/off and negative axis.
|
|
using the dupli's offset value.
|
|
[#23108] bpy.ops.object.origin_set(type='GEOMETRY_ORIGIN') dosen't work in console
[#23115] Crash when moving armature origin
- setting the armature in editmode would leave editdata in some cases.
- transforming selected linked objects to account for the movement of the obdata was only done for meshes, now do for curves and text3d.
- added utility functions for getting curve & mesh bounds.
- text3d moving center wasn't working at all.
- changed drawobject.c to use BLI_math funcs in more places.
- remove some unused code from operator object.origin_set.
|
|
Fix #21498: Edit curve Shape key /252_r 27318
Added full support of shape keys for curves and nurbs surfaces including
topology changing in edit mode, undo stuff, updating relative keys when
working under basis and so on.
|
|
|
|
enabled only for realtime display or only for rendering
|
|
27562, 27570, 27571, 27574, 27576, 27577, 27579, 27590, 27591, 27594, 27595, 27596, 27599, 27605, 27611, 27612, 27613, 27614, 27623
|
|
|
|
Internal change to not apply the shape keys to the Mesh vertex coordinates,
but rather use it as part of the derivedmesh/displist evaluation. This only
has one practical advantage right now, which is that you can now make a
linked duplicate and pin it's shape key to a different shape than the first
object.
Further, this makes shape keys correctly fit into the modifier stack design,
which will help implement some other features later. Also it means the mesh
vertex coordinates are now really the orco's.
|
|
|
|
Renamed BevPoint's members
* x,y,z -> vec[3]; compatible with other functions.
* f1 -> split_tag; used by displist to set the splitting flag.
* f2 -> dupe_tag; used in curve.c to remove duplicates.
BevList
* flag -> dupe_nr; was being used as a counter for duplicate points.
* use arithb.c functions where possible.
* arrays for coords, tilt and radius were being allocated, then copied into the BevPoint's, now write directly into the values without allocing/freeing arrays.
|
|
moved CU_2D to Nurb->flag in do_versions
This made simple type checks confusing to read.
many... if( (nu->type & 7)==CU_BEZIER)
replaced with ... if(nu->type == CU_BEZIER)
made setting rna curve_2d clamp the Z values. still more RNA/UI changes to do.
|
|
-r19323:HEAD
Notes:
* blenderbuttons and ICON_SNAP_PEEL_OBJECT were not merged.
|
|
Another bug in the 'radius per vertex' feature in curves.
If you set front/back face off for curves, and make it bevel or give
depth, the curves should draw as tubes. This feature didn't work in 2.48
either...
Still unsure about this implementation, campbell can check!
|