Issue was caused by merging triangles into quads policy which used to think
triangulation of non-planar/non-concave quads happens by 1-3 diagonal which
isn't actually correct in some OpenGL implementations.
Added check for non-concave faces when merging triangles. It will work fine if
original faces are flat. In case if original faces aren't flat this check might
fail and triangulate face when it's not actually needed or merge triangles in
a way which leads to OpenGL artifacts.
* Exploded faces that were meant to be hidden were still created with invalid vertices (0,0,0,0).
* In normal cases this went unnoticed, but for example edge split modifier crashed when it encountered these faces.
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.
Issues was caused by operator props "presets" which was reusing name of property
on every run of OBJECT_OT_game_property_new. This run into conflict with how text
property is determining -- it's stupid name comparsion which worked unexpectable
after adding and removing text property.
Solved by using empty (default) name for game_property_new when crating game property.
* Hair particle rotations weren't calculated properly for particle locations along a path and the "particle on path" calculations were not correct in many other ways too.
* Now the particle's location along a path is interpolated directly from the cached paths if it exist. These paths are always correctly calculated.
* Paths are now cached if a particle instance modifier using the particle system with the path option exists.
Problem was in how file selector is called by the effect_strip_add operator invoke. WM_operator_filesel() is not suited, as it directly calls exec if filepath is already set, and sequencer_generic_invoke_xy__internal() will set that path unless otherwise told. So using rather the same way to do as the one used by the other "strip_add" operators...
for after 2.62 I would like to try if using doubles would help to increase the precision here.
Also now that the mipmap patch is reverted we may want to look at this problem from a different perspective.
RES could be calculated taking the object size in relation to the camera (i.e. size and distance, ignoring rotation).
That may solve both problems of wrong resolution and lack of smoothness.
For the time being users still need to use object.resolution to fine tune the rendered text.
of python bundling on systems where python is installed to /usr/lib64
Now ABI flags are automatically detecting (by checking all available flags
and checking if there's include directory exists for flag).
Also, automatically set PYTHON_LIBPATH to /usr/lib64 if python
scripts are stored in this folder.
Bundling python on *nix platforms is now checks if python is installed
to lib64 directory and if it is, python will be bundled to lib64
folder instead of lib.
This will make building on openSUSE a bit less annoying
very well for colors that can be outside of the 0.0..1.0 range, giving +/- infinity
results.
Now we just use a simple linear contrast factor as proposed by Paolo Sourvinos, and
clamp values to be >= 0, and also make the parameters work more in the 0..1 range
instead of the 0..100 range, to be more consistent with other nodes.
Issue was caused by not enough threshold limit used for removing doubles.
Switched to adoptive threshold value calculation based on smallest length
of segments in meridians and parallels.
Select Linked operator was setting Limit by Seams property automatically
depending on current selection mode. But this property only used to be
set to truth if selection mode is set to Face, in other cases this property
is being reused from previous operator run. This leads to incorrect
behavior of selecting linked in vertex mode after this operator was
used in face selection mode.
