Problem was that area calculation of polygons was done relative to the xy plane, and with a very obscure (to me at least) algorithm. That meant that vertical ngons would get 0 area.
Commented initial code in case this is a strange optimization case that someone wants to use and used a cleaner algorithm: first project vertices to the ngon plane, defined by the normal of the ngon and the center (mean) of the ngon vertices. This will only be exact for convex and mostly planar ngons, still it is much better than the previous code.
Also fixed memory leak when stretch display was on.
Not all file formats/calls are supported yet. It will be expended.
Please from now on use BLI_fopen, BLI_* for file manipulations.
For non-windows systems BLI_fopen just calls fopen.
For Windows, the utf-8 string is translated to utf-16 string in order to call UTF version of the function.
- Crash was caused by recursively copying directory into itself, fixed
by switching from opendir() to scandir().
- Also do not try to unpack images which doesn't have name.
which resolves some possible issues with operating files with quotes and backslashes.
Also this might resolve (or at least help) resolving compilation error on GNU Hurd platform
which will help a lot maintaining Blender for Debian.
Vector.angle_signed(other)
for 2D vectors to get the clockwise angle between them.
in BLI math its called - angle_signed_v2v2()
shorthand for...
atan2f((v1[1] * v2[0]) - (v1[0] * v2[1]), dot_v2v2(v1, v2))
also corrects compile error in last commit.
the problem was numeric precision when in ortho mode the start/end points for the view vector would be 2000 apart which caused trouble for the intersection test.
No functional changes, this is just a bit easier to read I think (and
nicer if we add more PBVH types in the future, e.g. for dynamic
topology sculpting.)
problem was bow-tie quads would add opposite normals together and result in zero vector which was used for projection.
Now is_quad_convex_v3() checks if quad contains 2 faces which point away from eachother when split by either direction.
Theres another fix for this bug which can be done since creating the face can use existing edges in the example given so it wont have to guess which order of verts to use.
- edgebisect bmesh operator used uninialized beauty field.
- BLI_join_dirfile could read from before the string bounds when passed an empty dir string.
- pransform could use an uninitialized projected coordinate (unlikely but possible)
- RNA_property_path_from_ID_check would compare against an uninitialized pointer when the path wasn't found.
also have bmesh walker use BM_edge_other_vert() utility function.
Issue was caused by precision errors with floats.
Made internal grid drawing stuff using doubles and also added some
functions to multiply double vector by float matrix which also makes
all intermediate calculation in doubles.
Previously, the shading and material was set once per PBVHNode when
drawing. This is still the case, but PBVHNodes are now built to
contain only one material and shading mode.
This is done with an extra partitioning step; once the number of
primitives in the node falls below the PBVH leaf limit, it's
primitives are checked for matching materials. If more than one
material or shading mode is present in the node, it is split and
partitioned (partitioned by material rather than 3D location.)
Given a sufficiently 'annoying' input, like a dense mesh with
thousands of materials randomly scattered across it, this could
greatly increase PBVH build time (since nodes might end up containing
a single primitive), but in general this shouldn't come up.
In order to support materials for grids, the CCGDM is building another
grid array (of DMFaceMat structs). This could be used to replace
CCGDM.faceFlag for some small memory savings (TODO).
