Internally vector and waveform opacities are stored as float in 0..1 range
and the same range is exposed to the UI.
From file compatibility POV decided to change prop's type from percentage
to factor so it'll be nice slider with 0..1 range without confusing percentage
symbols (which should be quite easy to follow) and both forward and backwards
compatibilities are here.
The DMSetDrawOptions[Tex] callbacks return 0 (skip), 1 (draw), or 2
(either stipple or skip mcols.) In the CDDM, EDDM, and CCGDM draw
functions, as well as the callbacks in drawmesh/drawobject, replace
these numbers with values from an enum, DMDrawOptions.
- access to a meshs editmesh before the pointer was checked to be a mesh.
- uninitialized memory use in transform (not a problem practically but nice to quiet the error in valgrind).
add the function to create new UV layers, this only works when there are no polygon layers already created (to prevent confusion since scripts with polygon layers should be adding MTexPoly and MLoopUV layers)
Issue was caused by missing fdata for meshes which doesn't have tessellated
faces yet. Real fix would be to use loop's MLOOPUV layer, but currently interface
is using mtex layer names for UV lists so use poly's mtex layer to check if
layer name is indeed correct.
Should work fine until we'll separate setting textures and UV coordinates.
(sphinx_doc_gen.py)
- file reorganization to use more functions (easier to read)
- adapting to work after a recent commit that made some of the members of bpy.app.*
output bytes instead of strings (see [#30154])
- a couple of new command line optionsto avoid editing the script:
-T: let you choose the sphinx theme: the theme dir get copied in the destination dir
-b: choose if we want the bpy module page or not
Current command line arguments optional arguments:
-h, --help show this help message and exit
-o OUTPUT_DIR, --output OUTPUT_DIR
Path of the API docs (default=<script dir>)
-T SPHINX_THEME, --sphinxtheme SPHINX_THEME
Sphinx theme (default='default')
-f, --fullrebuild Rewrite all rst files in sphinx-in/ (default=False)
-t, --testdump Dumps a small part of the API (default=False)
-b, --bpy Write the rst file of the bpy module (default=False)
(rst/info_best_practice.rst)
- fixed a typo
from Dan Eicher (dna)
--- from the tracker
Setting Screen.scene only uses the active screen through a call to CTX_wm_screen(C) instead of the actual referenced scene.
The attached py-op demonstrates this behavior, assuming at least two separate scenes in the VSE.
Knifetool accumulates a bunch of proposed cuts and when the user
confirms, it makes them all. The old code did this by using scanfill
to triangulate the cutting edges in their faces, and then merging
triangles where possible. This sometimes ended up with strange
lost faces, and also made it so that when holes were cut, the
surrounding face ended up totally triangulated. But 29908 was
an example of a lost face.
This new code directly finds chains of cutting edges that go from
one side of a face to the other and using BM_edge_split_n to make
the cuts. Holes are handled by finding two good places where
the hole can be connected to the containing face (using two
because I think some other code in bmesh assumes that there are
no edges that appear twice in a face).
The old code is still there with #if SCANFILL_CUTS, so can easily revert
if this proves to be a bad idea.
Also, a small fix to previously added BM_split_n (forgot to
copy face attributes to new face).
now theres always a single step before skipping delimiters, this means the skipping actions always advance by more then 1 char (which matches the text editor).
This function pointer's 'setDrawOptions' parameter took a slightly
different type than the other drawing callbacks. In particular, it
could set a 'drawSmooth' value to indicate that smoothing should
always be enabled, overriding the face flag. However, all callbacks
either did not set this value, or set it unconditionally to
1. Replaced this by adding a new 'flag' parameter to drawFacesMapped,
which can be set to DM_DRAW_ALWAYS_SMOOTH where appropriate.
Also removed the 'useColors' parameter and replaced it with another
flag value, DM_DRAW_USE_COLORS.
Removed the 'wpaint__setSolidDrawOptions' callback, was only being
used to set the shading to smooth.
Node updates should generally be local by design, i.e. changes should not depend on any of the other nodes in the same tree. The original purpose of the dependency sort was to allow some experimental nodes to update their socket types based on upstream connected nodes, but these have been removed long ago. If such features need to be implemented they should instead use the tree-wide update callback, which is called after all the local node updates are done.
Removing the extra allocation and recursive function calls from most updates will ensure this function stays as fast as possible and can be called during node space context updates (snode_set_context), which are done very frequently (redraw).
and 5 float image textures. For CPU render this limit will be lifted later
on with image cache support. Patch by Mike Farnsworth.
Also changed color space option in image/environment texture node, to show
options Color and Non-Color Data, instead of sRGB and Linear, this is more
descriptive, and it was not really correct to equate Non-Color Data with
Linear.
"This patch adds "Not Equal To" to the list of options for selecting faces based on the number of vertices. While the equivalent can indeed be achieved by using "Equal To" and invert selection, having this option allows for a smoother work-flow when adjusting the number of vertices to be compared."
turns out old code also had the same bug (just coincidance it was noticed after my change)
now boundry verts are tagged so edges connected to them are not seen is missing a tagged, adjacent edge.
this fixes [#30471]
when the source and destination vectors were the same pointer, the X value would get overwritten.
now the rip tool uses the best side to grab as in trunk.
It's currently not respecting the material color, probably since the
BMesh merge. There are a couple problems, both involving "dummy"
variables taking the place of actual MTFace/MCol data.
Code review: http://codereview.appspot.com/5753050/
