Suitable for inclusion in 2.67a.
Logical AND, OR and XOR operations on freestyle.Nature instances gave an error in some cases.
The updated C implementation of these bitwise operations is intended to reproduce the following Python implementation:
class Nature(int):
def __and__(self, other):
return Nature(int(self) & int(other))
def __or__(self, other):
return Nature(int(self) | int(other))
def __xor__(self, other):
return Nature(int(self) ^ int(other))
The problem report was by plasmasolutions on IRC, thanks a lot!
bug reported by Eloy Felix over email
Apparently there are some files that will perform better with "use_occlusion_culling" off.
For now the UI option can return.
Technically this could make into 2.67a, but the string is not localized (it'll be in English).
Not sure what is more important here:
- consistent UI OR to expose in the UI an option some people need
The issue here was that the "active" material node depends on the editor context. Previously (< 2.67) there was only 1 edited node group possible globally throughout Blender, so the active material in the context could be resolved more easily. The solution now involves the active_viewer_key variable (first introduced for compositor viewer nodes in r56271, naming is a bit awkward but hard to change in DNA). This key defines the "last modified" node tree to resolve ambiguity of active context items. For single editors the result is the same as in 2.66, if multiple editors are used with different node groups the last modified tree is used.
SpatialNoiseShader, as well as SmoothingShader were not updating stroke length after
geometry modification, causing an infinite loop in Stroke::Resample(int iNPoints) due to
incorrect length-based resampling of stroke vertices.
* Editing number of segments for particle hair did not update the viewport.
* Hidden particles were confusing, the paths were drawn but without the points.
Now it draws the path faded to indicate that they are hidden/locked.
* Select tips/roots operators now have options to select/deselect/toggle/invert.
take up a lot of memory.
The operator was recording an array with all stroke points. However this was not
particularly useful, only sculpt mode had exec() implemented to redo the stroke,
but it was not registering the operator anyway so there was no way to access the
data after the operator was done. So no one was using this anyway.
I did now implement exec for the paint modes so you can call the operator with
stroke points from a script.
Partial redraw doesn't work so well with these, now I've changed the action
zones to just draw as part of regions instead of as a special overdraw done
at the end, which fits better with partial redraw by avoiding any special
exceptions.
* Particles did not render at viewport resolution like meshes.
* Properties editor preview render of hair was crashing, solution is to have
two separate flags for this preview render and viewport preview render.
Will be reverted as soon as the x64 compiler is fixed.
For now it shouldn't have an impact on tracking performance. My test have shown no significant speed difference to official VC2008 build of 2.67.
After the paint refactoring for 2.67, the OpenGL texture was getting updated for
every stroke point, rather than once for every redraw. With a small brush radius
and low spacing the number of stroke points can be quite large, which might have
a big performance impact depending on the graphics card / drivers.
Also for 2D image paint, avoid redrawing the button panels and properties editor
during painting.
There is another possible cause for slowdowns with 3D texture painting which was
not fixed. Projection painting is creating and destroying threads for every stroke
point. Depending on the CPU/OS there might be a lot of overhead in doing that if
the brush size is small.
down, this time by the operator properties getting converted to a string for
display in the info window.
With 1000+ stroke points this can get slow, and takes up too much space anyway,
so now it's (somewhat arbitrarily) limited to printing only 10 points.
Textured dyntopo draw was leaving 2d textures enabled when it shouldn't.
Root of the issue was figured out by Campbell, actual place where
2D textures left enabled found by self.
Also, simplified fix is suggested by Campbell (mine was 2 lines longer! :)
Switching to tool will cycle via all brushes with given type
only in case current brush tool matches requested one.
This means, when user requests brush with different type,
first brush of that tool will be activated. But further
toggling to the same tool will cycle via all acceptable
brushes.
This functios are declared in BKE_paint.h header and using
SculptSession structure which is also declared there.
Anyway, does not make sense such a splitting of header and
implementation files, better be consistent here.
Made it so dynamic topology will flush changes from
SculptSession->bm to Object->me.
Used the same approach as sculptsession_bm_to_me does,
but instead of using DAG_id_tag_update used in-place
DerivedMesh release. Otherwise this lead to some
update issues resulting in missed object after render.
Also fixed multires modifier not being applied for
render when rendering from dyntopo sculpt mode.
P.S. Apparently sculpsession_bm_to_me was declared
in BKE_paint.h but implemented in object.c.
Rather confusing and better make it so this
functions are declared and implemented in
consistent files. But will solve this in a
separate commit.
* Removing KX_Scene::RemoveAnimatedObject() since KX_Scene::NewRemoveObject() is already handling this.
* Don't create a new BL_ActionManager when replicating an object. Just set m_actionManager to NULL and let KX_GameObject::GetActionManager() allocate a new BL_ActionManager when one is needed.
* Use KX_GameObject::GetScene() instead of KX_GetActiveScene() in KX_GameObject::GetActionManager() to make sure we're using the object's scene instead of one where Python might currently be running from. This could avoid potential issues with playing actions for objects in other scenes.
