So now, their generation is controlled by a flag, else previous "simple values" group ids are generated (one per poly region, no need here to reduce the number of used IDs!).
Will update obj exporter too.
In fact, smooth groups are supposed to be bitflags, not simply integer values (would be far too much simple!). This adds quite a bit of work, as with only 32 values, we can't just assign one to each group. Somewhat related to the "Four colors theorem"! ;)
Here we simply use the first available bit for current smooth group (i.e. first bit not used by any of the already defined contiguous groups).
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
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
Also construct orco uv layer when converting curve to a mesh.
This makes it possible to preserve automatically generated coordinates
("use uv for mapping" option) when using constructive modifiers or
converting curve to the mesh.
With cycles nothing special is needed to preserve texture mapping
after such operations, in blender internal you'll need to change
texture mapping from Generated to UV.
This feature is useful on it's own and also would help in potential
switch 3d viewport to always use DM to draw objects, which would
help making drawing more thread-safe.
add arguments to calculate normals when converting to bmesh:
BM_mesh_bm_from_me, DM_to_bmesh
This gives some speedup to undo (which didnt need to re-calculate vertex normals), and array modifier which doesnt need to calculate face normals at all
Now add asserts to make sure this layer is only added once the modifier stack has been calculated.
this saves normal layer being calculated whenver vertex normals need updating.
This means main database is no longer pollutes with
temporary scene and objects needed for freestyle
render.
Actually, there're few of separated temporary mains
now. Ideally it's better to use single one, but it's
not so much trivial to pass it to all classes. Not
so big deal actually.
Required some changes to blender kernel, to make it
possible to add object to a given main, also to
check on mesh materials for objects in given main.
This is all straightforward changes.
As an additional, solved issue with main database
being infinitely polluted with text blocks created
by create_lineset_handler function.
This fixes:
- #35003: Freestyle crashes if user expands objects in FRS1_Scene
- #35012: ctrl+f12 rendering crashes when using Freestyle
