| Age | Commit message (Collapse) | Author |
|---|
|
Issue is rather well explained in T45471: our current customdata writing code easily generates several different blocks in blend file with same 'old' address. This is bad, because those addresses are used as 'uid' during reading process (it kind of work in Blender's own reading process, by mere luck mostly, but breaks the file specs).
Solution (suggested by Campbell, thanks) implemented by this patch is to avoid duplicating everything, and instead just overwrite what we needs to skip some cdlayers on write:
* the CustomData's `totlayer` number;
* the CustomData's `layers` array of CustomDataLayer (keeping its original address using the `writestruct_at_address` helper).
New design allows us to get completely rid of the no_free flag stuff in `write_customdata()`.
Note that this implies written data is **not** directly valid from Blend PoV, since its written typemap does not match written layers (this is not an issue because typemap is rebuilt on read anyway - and it's easy to fix this if really needed).
Also, the backward compatibility saving of mface data remains an issue here, see comment in code.
Reviewers: sergey, campbellbarton
Projects: #bf_blender
Maniphest Tasks: T45471
Differential Revision: https://developer.blender.org/D1425
|
|
This stores loop indices into the loop array giving easier acess
to data such as vertex-colors and UV's,
removing the need to store an MFace duplicate of custom-data.
This doesn't yet move all internal code from MFace to LoopTri just yet.
Only applies to:
- opengl drawing
- sculpting (pbvh)
- vertex/weight paint
Thanks to @psy-fi for review, fixes and improvements to drawing!
|
|
|
|
This is the core code for it, tools (datatransfer and modifier) will come in next commits).
RNA api is already there, though.
See the code for details, but basically, we define, for each 'smooth fan'
(which is a set of adjacent loops around a same vertex that are smooth, i.e. have a single same normal),
a 'loop normal space' (or lnor space), using auto-computed normal and relevant edges, and store
custom normal as two angular factors inside that space. This allows to have custom normals
'following' deformations of the geometry, and to only save two shorts per loop in new clnor CDLayer.
Normal manipulation (editing, mixing, interpolating, etc.) shall always happen with plain 3D vectors normals,
and be converted back into storage format at the end.
Clnor computation has also been threaded (at least for Mesh case, not for BMesh), since the process can
be rather heavy with high poly meshes.
Also, bumping subversion, and fix mess in 2.70 versioning code.
|
|
Used this in GPU module to clarify what some "ints" really are.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1026
|
|
Don't use a dedicated node layer but use temporary int layer instead.
Works like a charm as long as we are careful resetting the layer when
needed (after pbvh clearing and always after bmesh has been filled in
undo)
Tip by Campbell, thanks!
|
|
Store PBVH node ID in CustomData. This avoids a number of hash deletions
and checks/insertions on big hashes.
|
|
here):
* Add a new calcLoopNormals function to DerivedMesh struct, and implement it for CDDM and CCGDM (subsurf).
EditDerivedBMesh (edit mode DM) only gets a dummy one in this commit.
* Add a tessellated version of CD_LOOPNORMAL layer (CD_TESSLOOPNORMAL), with relevant code to handle it
(tessellation, rna access, etc.).
* Change auto_smooth options of Mesh (angle now in radian internaly, and toggle is now used to enable/disable
split normals in DM creation process). Note BI render code is not touched here, hence its behavior regarding
this option is now incoherent, will be addressed in a separate commit.
Reviewers: campbellbarton
CC: brecht
Differential Revision: https://developer.blender.org/D365
|
|
|
|
This simply mimics code used for loopnormals, to enable py scripts to generate and access (temporary)
a tangent 3D vector and bitangent sign for each loop. Together with the split normals, this allow
to recreate a complete tangent space for normal mapping (bitangent = bitangent_sign * cross(normal, tangent)).
Expects all faces to be tri or quads.
Reviewed By: Brecht, campbellbarton
Differential Revision: https://developer.blender.org/D185
|
|
enum is an int, and values from CD_PREVIEW_MLOOPCOL (32) onwards
will not give what apparently was expected.
Found with help from Oscurart in #blendercoders while trying to figure
out compile error with CMake/msvc9. Occasionally it is good to heed
the warnings given by compilers!
|
|
|
|
circumstances.
Problem was actually integer overflow in the requested data layers (1 << 31) does
not fit in an integer, it only goes up to (1 << 31) - 1.
|
|
The previous implementation of Freestyle edge/face marks was refactored
based on suggestions from the latest code review by Campbell. The new
implementation relies on mesh CustomData to store edge/face marks, instead
of introducing extra flags in the core Mesh and BMesh data structures.
The CustomData-based implementation will allow further additions of new
edge/face attributes because of the independence from Mesh/BMesh.
This revision is work in progress, mainly intended to address the review
comments and ask for further code review in view of the trunk merger in
the upcoming 2.67 release.
|
|
DNA headers when its not so obvious what their purpose is.
|
|
|
|
reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer
for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces.
(CD_POLYINDEX and CD_ORIGINDEX).
as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on
the same derived mesh, and polygons only store the original index values.
|
|
in pre-bmesh blender version, remove MODSTACK_DEBUG, was never used.
|
|
|
|
The MVertSkin currently just stores local skin radii and skin
flags (MVertSkinFlag).
Skin modifier documentation:
http://wiki.blender.org/index.php/User:Nicholasbishop/SkinModifier
Reviewed by Campbell Barton.
|
|
CD_PAINT_MASK is a layer of per-vertex floats for non-multires
meshes. Multires meshes use CD_GRID_PAINT_MASK, which is a layer of
per-loop GridPaintMask structures. GridPaintMask is similar to MDisp,
but contains an array of scalar floats.
Note: the GridPaintMask could be folded into MDisp, but this way
should be easier to add mask layers in the future (if we do fold
GridPaintMask into MDisp, the mask array should probably be an array
of arrays with a 'totmask' field so that mask layers can be easily
supported.)
Includes blenload read/write support for CD_PAINT_MASK and
CD_GRID_PAINT_MASK.
|
|
this layer is now also used for various preview tasks in Object mode.
“Cleanup” commit, no functional changes.
|
|
|
|
* Only have 1 python object per bmesh, vertex, edge, loop, face.
* Store pointers back to the python data in a custom data layer so as not to use more memory for normal editing operations (when pythons not running).
* Currently this data is created and freed along with the BMesh PyObject.
* Incidentally - this fixes comparisons for bmesh elements which wasnt working before.
|
|
|
|
without the underscores these clogged up the namespace for autocompleation which was annoying.
|
|
Next, uv sculpting will be ported.
Also fixed "initializer element is not computable at load time" compile error caused due to bit-shifting a constant past its precision length (1L should be 1LL for 32 positions left shift).
|
|
currently only works for 3/4 sided faces.
|
|
|
|
|
|
|
|
This commit extends limit of ID and objects to 64 (it means 63 meaning
characters and 1 for zero-terminator). CustomData layers names are also
extended.
Changed DNA structures and all places where length constants were hardcoded.
All names which are "generating" from ID block should be limited by MAX_ID_NAME-2,
all non-id names now has got own define called MAX_NAME which should be used all
over for non-id names to make further name migration stuff easier.
All name fields in DNA now have comment with constant which corresponds to
hardcoded numeric value which should make it easier to further update this
limits or even switch to non-hardcoded values in DNA.
Special thanks to Campbell who helped figuring out some issues and helped a lot
in finding all cases where hardcoded valued were still used in code.
Both of forwards and backwards compatibility is stored with blender versions newer
than January 5, 2011. Older versions had issue with placing null-terminator to
DNA strings on file load which will lead to some unpredictable behavior or even
crashes.
|
|
|
|
|
|
with USE_BMESH_FORWARD_COMPAT.
|
|
load but this is unavoidable.
|
|
index values in a typemap.
|
|
|
|
|
|
|
|
|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
|
|
|
|
|
|
|
|
documentation done.
|
|
|
|
|
|
own files.
No functional changes.
Where necessary extern "C" {} blocks have been added.
|
