- tessface vertex color had the wrong sized array passing to rna_iterator_array_begin
- re-calculating tessface's would clear them if they were already created (own mistake)
- ED_mesh_color_add initialized tessface vertex colors from the loop color array
also made rna's mesh.tessface_vertex_colors.new() work like tessface_uv_textures.new()
where layers can be added as long as polygons are not present.
mesh.calc_normals() wasnt calculating vertex normals (only face normals),
now only calculate vertex normals.
added a define incase we want to have poly normals back again.
* calculate vertex normals (previously was calculating face normals only)
* clear tessfaces unless theres an argument to build them. since no tessfaces is the default state right now.
* if convert_mfaces_to_mpolys() runs, dont calculate edges, since it already does that.
Issue was caused by making and loading editMesh in drop_named_image_invoke,
which lead to freeing/changing pointers used by CustomData layers. Some of
this pointers might be used by DerivedMesh, so we need to update DerivedMesh
after loading EditMesh.
These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete.
This uses similar convention to RNA.
* use face/loop/edge/vert as a prefix for functions.
* use 'elem' as a prefix too for functions that can take any type with a BMHeader.
* changed from camel case to underscore separated (like RNA).
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.
comparing bmesh to trunk, mesh_calc_normals() in bmesh is a much more comprehensive function, calculating mpoly,mface normals, where trunk only calculated vertex normals.
renamed:
* mesh_calc_normals() --> mesh_calc_normals_mapping_ex
* mesh_calc_tessface_normals --> mesh_calc_normals_tessface() - only calculates normals from tessface
* added mesh_calc_normals() - only calculates normals from poltys
this way we can have mesh_calc_normals() remain fast for parts of the code which only need vertex normals to be updated.
only refactor, no func changes- didnt replace mesh_calc_normals_mapping_ex() with mesh_calc_normals() anywhere yet.
CTX_data_pointer_get_type(C, "object", &RNA_Object).data
with api call:
ED_object_context(C)
... since getting the context object is such a common operation.
Warning! Tesselation uvs or vcol data got out of sync, "had to reset!
This would happen on every editmode edit with UV's and wasn't too reassuring that blender was handling uvs/vcols correctly.
From looking into the problem I found that creating the undo mesh would act as if it was tessellating the existing mesh each time and complain that the data was out of sync, when infact the mesh was just created and being filled in.
Also, allocating uv and vcol customdata arrats for tessfaces isn't needed for undo mesh, so save some memory and dont allocate these in the first place.
- some merges added lines in multiple times
- removed some NULL checks that were only in bmesh
- enable cycles by default (was disabled because it used not to work)
- make formatting match
by Gaia Clary.
Rationale: the name was confusing and not always used consistently, and this
map itself is not something that can be layered, rather the map can be used
as texture coordinates in some layered setup.
The original intent was to indicate this contained more than just UV's, but
the game engine settings have already been moved out, and apparently users
didn't really get this from the name anyway.
