Transparent rendering can't be implemented in way it gives accurate shading in
3d viewport. It's acceptable for object mode, but when you're in edit mode
it gives more problems than benefits of seeing transparent faces.
This is possible fix for for weird polygons in [#29255] Object invisible and weird polygons appearance
"Just a simple check for non power of two support (GLEW_ARB_texture_non_power_of_two), to avoid what seems to be a very slow, and very unnecessary gluScaleImage call."
This is the only part of the VideoTexture that does the POT calculation, so the check seems good.
It would be interesting if some opengl guru would like to benchmark the use of this in other areas of Blender (e.g. 2D Filters, and all GLSL materials).
Note that mipmap should also be supported automatically by this extension, so it's not something to worry about.
I've written a convenient function that returns the sibling of a node in the
red-black tree implementation originally implemented by Joshua Leung.
I want to use this get_sibling() function in the future to implement the missing
removal function of the red-black tree implementation.
For now the get_sibling() function just simplifies the get_uncle() function.
Just like the rest of the red-black tree implementation this diff is based on
Wikipedia: http://en.wikipedia.org/wiki/Red%E2%80%93black_tree#Removal
This issue it totally related on issue with changing object datablock.
For curves it used to guess object type from curve datablock based on
count of control points in V direction.
This quess fails in case when SurfCircle datablock is trying to be reused
by another surface object or as another sample empty surface databouck used
to be treated as curve.
Store type in Curve when creating new Curve datablock which is used in
this object type quessing function.
Note: Previously saved files wouldn't change behavior at all.
If enter is pressed outside of any button in menu, generate two menu return values:
- UI_RETURN_CANCEL so button wouldn't be executed
- UI_RETURN_POPUP_OK so callback associated with popup block would be executed
There were some issues with PBVH which prevented working it for meshes without faces.
Discussed with Brecht, for benefits of dynamic-topology-sculpting and so better to
make PBVH survive such things.
Added some extra NULL-pointer checks for this.
- setting the color channels on save as would ignore the channel - BW/RGB/RGBA setting.
now its used when available but still need to hide BW for formats blender can only write as color.
move these checks from creator into BKE's image.c, this way we dont need the defines for creator, scons was missing DDS, HDR & Cineon for example and nobody noticed.
from Andrew Hale (trumanblending), with some edits to use these in mathutils.Vector added.
Added Functions:
- dot_vn_vn - Dot product of two arrays
- normalize_vn_vn - Normalize an array and store the result in a second array
- normalize_vn - Normalize an array inplace
Renamed Functions:
Some functions have been renamed to make them consistent with the naming conventions used by fixed length array functions.
- fill_vni to fill_vn_i
- fill_vn to fill_vn_fl
* Get rid of subrow/subcol variable names in the C UI code as well, use sub instead. This is shorter and sufficient.
* Minor layout alignment fixes.
* Greying out in NLA editor was doing nothing for "strip_time" property.
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.
Regression was introduced in svn rev40343. It was caused by re-creating
EditMesh structure which was needed to solve issues with parenting to
vertices after topology changes. This would also erase derivedMesh.
Problem reported now is caused by missing derivedMesh which is used
to solve parenting and apply inverted matrix on ob->parentin, so
parented object used to stay at exactly the same position it used to
stay before parenting.
Not very nice solving of this issue: re-create derivedMesh after
re-creating EditMesh when parenting. Nicer solution would require
bigger changes and probably ful lrefactor of this tools.
* Added some RNA tooltips, now that they are supported by dropdown lists.
* Fixed some RNA num properties UI steps.
* Fixed a memory leak in Proximity modifier (when dm of "target" object had to be created, it wasn’t freed...).
- UV's were not being calculated if there were too many VColor layers.
- precalc (omd->size * omd->spatial_size) was being called in a loop.
- use vector functions to avoid pointer indrections on each access which the compiler wont optimize - eg: och->ibufs_disp[f]->rect_float[4*(res_x*j + i) + 1]
- dont call abs() on ints (converts to double and back to int in this case).
also unrelated render buttons change. move saving options directly under the file path since these were easy to confuse with image format options like zbuf, ycc, preview.. etc.
This patch adds a new CLIP_EVENTS flag for uiBlock, which will prevent the ui_but_find_mouse_over search function from looking into "lower" uiBlocks (i.e. those further back in the list). The order of block creation for nodes has also been updated to use the z-ordering (just the nodetree->nodes list).
In order for this to work, the bounding box values of the uiBlocks have to be set explicitely to fit the node size, those are usually either zero or calculated from the internal buttons.
Constraint (bones case only for now). See [#29100] for some problematic test
cases
* It is no longer necessary to have to press "Clear Inverse" before doing "Set
Inverse" to get a reliable result. The calculation now calculates the pose with
the inverse cleared as it's "baseline" first now, which has the same result as
clearing the inverse manually first.
* Also, this commit trials a new method for computing inverses when there is
more than one constraint on the bone. Previously it just temporarily muted the
offending constraint, but kept all following constraints active, thus
potentially including their results in the inverse calculation. However, since
the inverse should only really care about what the stack looked like up to and
including when the constraint is applied, all constraints starting from this one
onwards are now disabled when calculating the inverse. PLEASE TEST!!! In the
few tests I've done, the effects appear minimal, but this may be quite an issue
in the wild
