Previously it would save packed file(s),
which would ignore the image.filepath,
making it impossible to set the destination.
Add image.packed_files[...].save() so you can save packed files if its needed.
Idea is, instead of ignoring completely missing linked datablocks, to
create void placeholders for them.
That way, you can work on your file, save it, and find again your missing data once
lib becomes available again. Or you can edit missing lib's path (in Outliner),
save and reload the file, and you are done.
Also, Outliner now shows broken libraries (and placeholders) with a 'broken lib' icon.
Future plans are also to be able to relocate missing libs and reload them at runtime.
Code notes:
- Placeholder ID is just a regular datablock of same type as expected linked one,
with 'default' data, and a LIB_MISSING bitflag set.
- To allow creation of such datablocks, creation of datablocks in BKE was split in two step:
+ Allocation of memory itself.
+ Setting of all internal data to default values.
See also the design task (T43351).
Reviewed by @campbellbarton, thanks a bunch!
Differential Revision: https://developer.blender.org/D1394
This expose the capability of handling offscreen drawing. The initial
support lays the barebones for addons to work with framebuffer objects
and implement 3d viewport offscreen drawing. This can be used by script
writers to make fisheye lens preview, head mounted display support, ...
The complete documentation is here: http://www.blender.org/api/blender_python_api_2_76_1/gpu.offscreen.html
Review and many changes by Campbell Barton (thank you :)
https://developer.blender.org/D1533
It fix T46381. Normally BL_Action::Update (manage action time, end, loop…) should be called the same number of times as BL_Action::UpdateIPO (update action position, scale ect… in the game object).
But the bug report shows that UpdateIPO is called one less time than Update. To fix it i revert the commit 362b25b382 and implement a mutex in BL_Action::Update.
Example file : {F245823}
Reviewers: lordloki, kupoman, campbellbarton, youle, moguri, sybren
Reviewed By: youle, moguri, sybren
Maniphest Tasks: T39928, T46381
Differential Revision: https://developer.blender.org/D1562
Same case as with space char really, one should not use those special chars in
filenames, but they are globally supported by all current FS/OS, so no real reason
to enforce that behvior on users here.
To be backported to 'a' release.
All optional image format are not #define'd in submodules like DDS read/write code.
This means values of `eImbTypes` would not always be the same in all contexts, yuck!
This is a regression and should be backported to 'a' release.
Even if the weights are normalized, the weighted sum of normalized vectors
usually does **not** give a normalized vector (unless all source vectors
are aligned).
This probably was not a big issue in most cases, since we usually interpolate
similar vectors here - but still!
The final stage of the process (copying/interpolating new dst cddata from src cddata)
was simply broken in normal case, where we need to convert from source to destination
object space.
This patch is a bit verbose, but I cannot see how to avoid it really.
To think this code is in master since over 6 months and it only gets reported now... :/
'thumbnail_size' is now used in all cases, it controlls column width in other viewmodes
of filebrowser. We cannot (easily) rename that DNA member, but I also renamed RNA
property, and fixed its tooltip...
As with cdderivedmesh, performance here is still CPU-limited if material
needs tangents/UVs/vcolors. Draw calls have much less overhead though.
Also, as with derivedmesh, kept an exception for old drawing for NVIDIA
+OSX+VBO off or setDrawOptions callback not being NULL.
setDrawOptions should be ommitable and fully VBOfialbe (?) in the
future, usually those just check for hidden flag of poly or similar.
Filenames over 128 chars would crash.
Move BLI_newname into file_ops,
this was only used in one place and isn't all that re-usable.
Also remove special behavior for 4 digits.
linking API funcs would use 'name, idcode', when all other code here uses
(more sensible) 'idcode, name'.
Also, use 'name' arg name when we expect a bare name, without the prepended ID code, and
'idname' arg name when we expect a complete ID name.
And here too, idcode shall be short, not int!
Used old (2.49 era) filled style for drawing here, with white color and
alpha blending.
Also changed drawing to do linear interpolation between samples instead
of ugly square wave in high zoom.
This could be improved upon, with real waveform drawing in higher zoom
levels, but I'll leave this for later since it may need some hacking on
audaspace level.
This adds an option to control at what time relative to the current frame
the shutter is fully opened. Supported options are:
- Shutter is starting to open at the current frame
- Shutter is fully opened at the current frame
- Shutter is fully closed at the current frame
Custom shutter time offset is possible, same as custom curve for shutter
openness but those are considered nice things to have rather than something
crucial.
Reviewers: juicyfruit, dingto
Subscribers: venomgfx, hjalti
Differential Revision: https://developer.blender.org/D1380
Title says pretty much everything, we now have BKE and RNA funcs to get vertex, poly and
loop normals of a given shapekey.
This will be used e.g. in FBX exporter (shapekeys need normal data too).
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1510
New code loops much less, does re-open & close .blend files for each data type,
and is much much more flexible - it is also ready for id-remap & co work being done in branches.
Main idea is to store libraries & datablocks to link in a dedicated struct, in a way
that avoids too much looping, and also allows to search for a single datablock in several libraries.
Here again, no change is expected in current behavior of link/append tool, please report
if anything goes different!
This commits does mostly two things:
* Get rid of bContext parameter: I can see no real good reason to pass such a high-level data
to such low-level code... It also makes it more difficult to call when you do not have
a context available.
* Cleanup the instantiating part.
Last point is the most risky - previous code was sometimes quite confusing and hard to follow,
from tests nothing behaves differently in new code, but some hidden corner case may show up.
Anyway, no change in behavior is expected from this commit, if it happens please file a bugreport!
It turns out libGL from Intel crashes when calling glxewInit (where mesa, nvidia work fine),
unfortunately the only option without making larger changes to glew,
is to inline the parts of glew we're using - before the glx context is created.
Root of the issue is that we do not re-read lib data blocks and ID placholders (ID_ID bheads)
in undo context (in `blo_read_file_internal`), because `BLO_read_from_memfile` copies
lib datablocks and Main data directly from oldmain.
The idea being, linked data do not change from undo/redo.
This is valid as long as linked data was not changed by the undo step - but if some
was deleted or localized, it will be missing from oldmain, leading to data loss
(note that does not only concern objects, all linkable data types can be affected,
at least in theory).
This commit addresses that issue by carefully mixing reuse of needed data from oldmain,
and "normal" re-reading of missing one. Makes us swimming in some rather dark waters,
and gives a rather non-easy-to-follow code, but it seems to work quite well,
and only other solution would be to get rid of that optimization
(not re-reading all libs on undo/redo), which is not acceptable.
Also, thanks to @carlosdp for initial investigation of the issue.
Differential Revision: https://developer.blender.org/D1485
Change the mathutils callback from vector to color for mistColor, backgroundColor and ambientColor.
Reviewers: lordloki, campbellbarton, panzergame, moguri, sybren
Reviewed By: panzergame, moguri, sybren
Projects: #game_engine, #game_logic
Differential Revision: https://developer.blender.org/D1432
Actually we only have a Python API that allows to change the max jumps value.
The patch also allows non programmers to change the maximum numbers of jumps.
Reviewers: panzergame, sybren, campbellbarton, lordloki, moguri, agoose77
Reviewed By: lordloki, moguri
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1302
Title says it all, based on feedback of artists from gooseberry team.
This mainly affects cases when going to a local view from layers setup
when some lamps were on invisible layers. Those lights are no longer
becoming visible to the object in local view.
Reviewers: brecht, juicyfruit, dingto
Reviewed By: juicyfruit, dingto
Subscribers: maxon, eyecandy, venomgfx
Differential Revision: https://developer.blender.org/D1326
The issue was caused by non-continuous tangent space calculated for triangles.
This commit adds a Tangent input to Hair BSDF node which can be used to hook up
Tangent calculated form UV as an input to the node in order to make sure the
tangent space is continuous.
Doing this as an input instead of using default tangent layer from UV because of
several reasons:
- This way it's really easy to preserve compatibility with existing setups.
- Default UV map is not necessarily giving continuous space, one might want to
use other tangent space sources or distort the space for some artistic
decision.
Reviewers: juicyfruit, dingto
Reviewed By: dingto
Differential Revision: https://developer.blender.org/D1428
Currently only image loading benefits of this and will give magenta color
when image manager detects it's running out of memory.
This isn't ideal solution and can't handle all cases. For example, OOM
killer might kill process before it realized it run out of memory, but
in other cases this could prevent some crashes.
Reviewers: juicyfruit, dingto
Differential Revision: https://developer.blender.org/D1502
* Change the character jumping variables and methods from int to char.
* Limit the maxJumps integer value from 0 to 255.
* Allow to set the minimum jump amount to 0.
Reviewers: panzergame, lordloki, moguri
Reviewed By: lordloki, moguri
Subscribers: agoose77
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1305
Currently OpenCL devices are packing images into a single texture,
which means technically number of textures is not limited here.
Now OpenCL will use same number of textures as CPU. If we want
to bump number of textures further, this values are to be modified
in sync.
NOTE OpenCL still does not support float textures.
Original patch from a guy called bliblubli in the tracker with
some own modifications.
Reviewers: brecht, dingto, sergey
Differential Revision: https://developer.blender.org/D1530
The icon16 and icon32_mesh_capsule.dat files are committed with 0 Kb, because I used the patch from the differential from the Phabricator which I done with a regular .diff file.
This patch adds icons to the physic collision shapes.
Adding a new capsule shape 'mesh_capsule' icon which represent the shape better then the metaballs icon.
And replace the metaballs icon for the Blender collision shape.
{F206628}
Reviewers: moguri, sybren, agoose77, lordloki, mont29, panzergame, campbellbarton
Reviewed By: lordloki, panzergame, campbellbarton
Projects: #game_engine, #game_ui, #user_interface
Differential Revision: https://developer.blender.org/D1403
This patch will delete all associated objects from a group instance (dupli group) if the are deleted.
Reviewers: brita_, sybren, lordloki, moguri
Reviewed By: lordloki, moguri
Projects: #game_engine
Maniphest Tasks: T36388
Differential Revision: https://developer.blender.org/D1205
Extending the existing game actuator with a screenshot function, to give also non programmers the ability to take screenshots in the BGE.
Reviewers: lordloki, campbellbarton, moguri
Reviewed By: lordloki, moguri
Subscribers: lordloki, Genome36
Projects: #game_engine
Differential Revision: https://developer.blender.org/D651
Use new interp_m4_m4m4 instead of blend_m4_m4m4.
Note that maybe we could replace other usages of blend_m... by interp_m...,
but this should be investigated on a case-by-case basis.
mat3_polar_decompose gives the right polar decomposition of given matrix,
as a pair (U, P) of matrices.
interp_m3_m3m3 uses that polar decomposition to perform a correct matrix interpolation,
even with non-uniformly scaled ones (where blend_m3_m3m3 would fail).
interp_m4_m4m4 just adds translation interpolation to the _m3 variant.
Ray direction is assumed to be normalized in such areas as scaling intersection
distance on instance push/pop when doing ray-scene intersection, but it was
possible that some closures wouldn't give normalized direction which could cause
wrong intersection checks.
Now normalization will happen on surface bounce, which could be a bit of a waste
if closure actually gives normalized direction, but currently only transparent
BSDF seems to give guaranteed normalized direction.
Issue was caused by wrong intersection distance scaling on instance pop,
which could cause intersection distance to become zero, confusing following
intersection checks.
Looks like instancing of smoke sim is not supported at all
(was fake-working in 3DView in 2.74, but not rendered).
But it should not crash - code was adding temp 'fromdupli' base to the delayed
drawing list...
Nice to backport this to 2.76 I think.
This patch makes it possible to zero out angular velocity. tiny angular
velocities may cause instabilities, according to the discussion in T41943,
so they are mapped to (0, 0, 0) instead.
It also applies the same reasoning to the linear velocity, unifying the
different approaches.
Differential revision: D952
This commit exposes the interpolation parameter for environment textures (requested by DolpheenDream on IRC), just as it already is for image textures.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D1544
Transition strips in the NLA should always stick to whatever strips are beside it,
and are allowed to grow/shrink as needed to achieve this. Previously the code here
was only checking if the neighbouring strips started encroaching on the transition,
but not whether the transition needed to grow to fill a gap. It was also just
moving all strips when there was insufficient space, even though that would alter
timing down the track.
Now transition strip resizing works as follows:
* It will grow/shrink as necessary to absorb any changes in the length of its neighbours
instead of shunting everything around to maintain its length
* If the neighbour has been resized by an amount greater than the transition's length,
all the strips will need to be shunted away to make way for the neighbour. In this
case, the transition will shrink down to being 1 frame long to ensure that it is
still visible (so that it can be removed if necessary).
The "tweak user" flag used to flag strips using the same action as the active strip
was not getting set on other strips that live on the same track as the active one.
Strips with this flag set are shown with a red colour to indicate that editing the
action may have the unintended consequence of modifying another strip.
Duplicate wasn't updating links,
so duplicatinvg a objects would still point to the originals for curve-taper, texmesh, drivers.
Use generic id-looper to handle replacing data.
- BLI_current_working_dir's return value must be checked, since it may fail.
- BLI_current_working_dir now behaves like getcwd, where a too-small target will return failure.
- avoid buffer overrun with BLI_path_cwd, by taking a maxlen arg.
I have removed the m_pHitObject, m_xray and m_testPropName and replace them by a temporary struct "RayCastData" which contains these datas and a collision mask. Finally i add a collision mask argument in the python function "rayCast" :
```
rayCast(to, from, dist, prop, face, xray, poly, mask)
```
It can be useful to hit only object which are on the right colision layer. for example if you have hitbox for a charater or vehicle you don't want to hit it with raycast.
test file : {F237337}
left mouse click on two planes and see console messages.
Somewhat more elaborate test file by @sybren: {F237779}
Look around and click on the cubes. One cube lamp responds, the other doesn't, based on their collision groups.
Reviewers: moguri, hg1, agoose77, campbellbarton, sybren
Reviewed By: agoose77, campbellbarton, sybren
Subscribers: campbellbarton, sergey, blueprintrandom, sybren
Projects: #game_engine, #game_physics
Differential Revision: https://developer.blender.org/D1239
This func is long enough, there's no real need to make it even longer with
verbose local varnames and multi-line for loops...
Also, avoid mono-leters names as well for data pointers.
We now keep actions around when they are finished playing so scripts can
still get access to information such as the current frame. Playing a new
action in the same layer still overwrites the previous action as before this
commit. Using an explicit KX_GameObject.stopAction() will free the memory. The
action is also freed when the KX_GameObject is freed as before.
We now have to explicitely enure tesselation of DMs when we need it.
Notes: Maybe we could use looptris here as well?
Not a regression (bug already present in 2.75, but not 2.74), nice to backport to 2.76 nontheless.
Own regression caused by fix for T46067,
edit-mode bvh only contained unselected faces.
This commit adds support for an edit-mode bvh containing all faces.
Depsgraph customdata flag was set on the parent,
then cleared once the parent object was handled.
This is initialized to zero for new nodes, no need to clear.
Expose our `BKE_image_load_exists` feature through an optional parameter to `Image.load()`.
Extend `image_utils.load_image()` with two optional parameters, to return existing image datablock
if possible, and in that case, to force reloading said image.
Needed by incomming 'import images as planes' addon enhancement.
Also, fix own stupidity, no need to define ID callback in case we only have objects,
calling code knows to fallback to `foreachObjectLink()` when `foreachIDLink()` is missing...
Our version of clang fails with latest SDK. It's not really clear if such
change will disable openmp or not (-fopenmp doesn't throw an error, but
it might be a silent fail).
In any case, builds without OpenMP is better than no builds at all.\
- Match layout from stamp buffer (note last so it can wrap)
- Correct vertical spacing (didn't take decender into account)
- Use U.pixelsize when setting font-size.
It would simply remove default units (in most case), cannot see any good reason for such behavior?
Might work in case default unit is the only one present, but breaks consistency (and it may not be
always obvious for user which unit it is). Comes from original patch from five years ago, rB7d8f0fce.
This will break keyboard-setting of values, e.g. '2m 33.4cm' would become '2 33.4cm',
totally useless and invalid entry!
Issue was caused by changed function signature. This is still not really full
support of new OSL API since we don't store anything in the derivatives which
could confuse mipmapping.
Would write 1.04 seconds as `00:00:01,40` instead of `00:00:01,040`...
Anyway, we already have BLI API for timecodes, much better to add
SubRip timecode format there, heavily simplifies code.
To be backported to final 2.76.
Instead of offsetting along normals, smooth positions are now
calculated on a sphere defined by the vertices and their normals.
This removes visible seams along original edges, which were common previously.
E.g. trackball-arrows (R-R) were no more visible.
Caused by wrong cast of an array from int to float, we need an int version of those helpers (`glTranslatenxv`) too.
Broken by font wrap commit rBf2341f829654c4dc97, there was actually two things here:
* Using non-initialized color (which lead to transparent drawing...), we need to use new
`blf_draw_buffer__start/end` helpers here too, made them shared internally.
* Using `draw_str_i18n_nbr` as `draw_str[i]` length, ugh! That's the number of utf8 glyphs of
translated string, not the length of untranslated string!
This fix must be backported to final 2.76.
Cleanup and rework a bit text_cursor_set_to_pos_wrapped(), it did not handle correctly negative y valuesi,
because it was only checking lines starting from first visible one.
Mostly, we now directly get line matching given y position (be it an invisible one) from the helper
(renamed `get_line_pos_wrapped()`), instead of first visible one, which allows us to get rid of
additional complexity of looping over next lines until we find correct one.
This code remains rather complex to follow, added some asserts to ensure everything works as expected,
and tested it rather seriously, but DO NOT backport this to 2.76!
If t->mode remains edge/vert slide, restoreTransObjects() ends up calling
projectVert/EdgeSlideData(), which tries to access invalid customdata...
Not sure why we call again restoreTransObjects() and resetTransRestrictions() here tbh,
but safer not to change that for now.
Should be backported to 2.76 if possible.
More precise description of the issue: Clicking on the right side of a num-slider button with Continuous Grab enabled sometimes caused cursor to jump to the inner value indicator even though text editing was started.
Happened because data->ungrab_mval wasn't reset correctly after dragging.
Windows-only bug, mmap & co are not threadsafe by default on this platform, so we have to add a dedicated
spinlock for them in win32.
Note that we may try to get rid of those mmap later, but not for 2.76!
To be backported to final 2.76...
The issue was introduced by original Cycles point density support commit,
it lead to a constant density of 1 for object verticies point density source.
Mostly added missing :arg: clauses -- these caused the :type:-clauses
that were already in the RST files to be hidden from the output HTML.
I also fixed some argument types from 'list' to 'Vector' where applicable
and corrected some obvious mistakes.
We need custom context here, those are often very short names so context collision is pretty easy.
Also some minor changes (and avoid shadowing varnames)...
This is a mere bandage, that whole area is known broken anyway, but at least it should prevent the crash.
Note that that kind of stuff (the efd->index being a pointer) is really bad practice imho...
Should be backported to final 2.76.
This adds widget-group level, configurable keymaps. This means, for each widget group (e.g. Manipulator Widgets, Camera Widgets, etc), 6 keymap entries are added:
* Widget Activate (action-mouse down)
* Widget Activate (actually deactivate - action-mouse up)
* Widget Tweak (mouse move)
* Widget Tweak Cancel (RMB)
* Widget Tweak Cancel (esc)
* Widget Select (only for selectable widgets - select-mouse)
This might be useful e.g. to set certain widgets to activate on tweak event only to resove conflicts (see manipulator vs. selection with LMB-select conflict), and for things like setting a widget values using shortcuts (not yet possible, but easy to add now).
Further, this greatly improves the IMHO current ugliest part of the widget backend, the event system part/hack :P \o/
One remaining issue is that the keymap items only appear using search, they are not displayed in the keymap editor list by default (didn't investigate yet).
Old functionality was ported over to new system, everything should work fine still.
Notes:
- There is still some bvh cache code, but that is from the engines initial commit, we might clean this up further or keep it.
- Changes in util_cache.h/.c are kept, this might be re-used in the future.
This removes the BVH cache feature from the UI, underlying code will be removed in a separate commit.
The BVH cache was added before we had a multi-threaded BVH build, and a lot of other optimizations were done since then, which makes this not useful anymore.
Fix T46162.
- measure extents from mesh center instead of origin.
- use clamping method, guaranteed not to flip the input vectors direction.
- use cage coords when available (since knife operates on the cage).
So now the following OSL versions are supported (at least for compilation):
- 1.5 with closure alignment patch applied
- 1.6.8 release
- 1.7 development version from latest git
Calling event handling recursively during window live resize is problematic,
the code wasn't designed to do that. Instead postpone event handling until
after live resize.
This means widgets flagged as selectable - like facemap widgets - can be selected using RMB (currently hard-coded). This means they stay visible until they are deselected by pressing RMB again, or by selecting a different facemap.
- Custom scale:
Avoids having multiple custom-shapes at different sizes.
- Option not to use bones length:
So changes in edit-mode don't resize the custom-shape.
This was broken since ages I think, did not really hurt since we usually never use libs' names
to access them. Rather bad behavior however, breaking a ground rule of our ID system!
And no real reason to add new libraries to new (split) Main at all, libraries are
never considered linked datablocks, which means they should always be in 'main' Main->library list.
Not a regression, but should be included in 2.76 imho.
- Removed relation labels, since these mostly just reflect connected nodes, and also appear too far off the edge lines
- Draw cyclic links in dark red
- Slightly thicker edges and larger margins
Compositing might make main thread so busy that animation is considered done due to duration before final position is reached.
Also added check to avoid unnecessary redraws.
A bit stupid that we mix some special stuff for cone (plane in fact) style drawing into regular arrow widget drawing, still would like to use plane widget for this, but first need to pack arrow handling into more generic functions, since arrow & plane widgets would need almost the same handling.
Issue is, when 'Rotate Aroud Selection' is set, in Edit mode we do a fake transform operation
to get center point around which to rotate. For curves, most transform operations involve
a check of handle types. For now, added 'TFM_DUMMY' as an exception here.
Think it would be best to actually undo those changes in case of cancelled operation,
but this is much more involved, while this fix is safe enough to be included in final 2.76.
This wasn't visible with default settings,
but caused problems w/ pie-menu's & manually adjusted theme font-size.
Now only draw from the bound-box top w/ word-wrap enabled.
Adjusts view after mouse/border selection if some selected items are out of view bounds.
To get as much of the selection into view as possible, this adjusts view first for the last, then for the first element in the selection.
Also, if region is pretty small, view adjustment is skipped, as otherwise the view is focused on the first element only, which isn't really useful IMHO.
Maybe not so nice: Since we do two view alignment iterations, UI_view2d_curRect_validate, which is a rather big function *might* be called twice under certain circumstances (border select & total size of selected elements is exceeds view bounds). I think that's totally acceptable though.
Basically, after border selecting, a wrong file was selected by using arrow keys if the screen was scrolled a bit vertically. Reason was that we didn't use correct view space coordinates but region space coordinates for measuring distance from mouse to first/last file in selection after border select.
Added some extra seed to the hash, so it's now less likely to give repetitive
patters at values around zero.
This will change distribution of bricks for existing files. but it's something
inevitable.
- Adds support for word wrapping to Blender's BLF font library.
- Splits lines when width limit is reached or on explicit \n newlines.
Details:
- Word wrapping is used when `BLF_WORD_WRAP` flag is enabled.
- There is a single loop to handle line wrapping,
this runs callback, passing in a substring,
this way we can avoid code-duplication for all word-wrapped
versions of functions... OR... avoid having to add support
for word-wrapping directly into each function.
- The `ResultBLF` struct was added to be able to get the number
of wrapped lines, when calling otherwise unrelated functions
such as `BLF_draw/BLF_width/BLF_boundbox`,
which can be passed as the last argument to `BLF_*_ex()` functions.
- The `ResultBLF` struct is used to store the result of drawing
(currently only the number of lines wrapped, and the width).
Epsilon was quite arbitrary for GPU, replaced with checking for zero-sized faces.
It should solve both original report and the new one. After the release we can check
why GPU doesn't produce accurate math here and go to the root of the issue.
The user interface was ignoring the precision step size for degrees,
making all rotation inputs drag by a 100th of a degree.
Now use a 10th of a degree instead.
SCons didn't pass `-DWITH_AUDASPACE` to the compiler, so it skipped the
instantiation of the "aud" Python module. This caused a crash of the BGE,
which did get the `-DWITH_AUDASPACE` directive, and expected that module
to exist.
Reviewed by: lukastoenne
As of this release we're able to navigate with the keyboard in the filebrowsing area. The button caption is changing to an appropriate string whenever a new entry is selected. In @Severins original code a different method was used to determine if a directory was choosen or not, but this got lost while merging the filebrowser rework.
Thanks to @mont29 for review!
For now simply show warning in the interface and fallback to regular subsurf
code. Supporting OpenSubdiv in edit mode in possible but not high priority
currently.
The issue was caused by some special tricks needed to compile OpenSubdiv shader
which was using stupid check whether geometry shader is used or not.
Now made it more explicit call whether special OpenSubdiv trickery is needed or
not.
Its not ideal solution, but it's not really easy to do a proper solution for
this, because while we can do half of the work with if-defs in the shader code
but we'll still need to somewhat define layout of the input blocks which isn't
really doable with current shader version we're using.
Disable Intel cards for until we'll go to the root of the issue of the crash.
This will take a bit, so being so close to the release we go safe and disable
unstable GPU, so blender at least doesn't crash.
This could be bypassed by setting OPENSUBDIV_ALLOW_INTEL environment variable.
support is missing.
Supporting those (really) old GPUs requires us to make shaders more
expensive by converting between real and scaled coordinates and be wary
of such conversion caveats when handling uv coordinates in shaders. Not
worth the cost for supporting hardware that old.
Also they did not work when using blender -R from
command line in 64-bit systems.
Issue was checking for wrong define which would
cause code to detect if the blender executable
functions under 32 bit emulation.
For 64bit executables this is false, leading
blender to believe we are operating under a 32bit
system, and registration would try to register
the 32bit thumbnailer.
This 32 bit dll is (correctly) missing for local
installs and from the new installer, thus no thumbnails.
Using the global scheduler here is not a really good idea - `filelist_cache_previewf()` is not a short task
that run once, but it's a loop that keeps cheking for work in a TODO queue. This means it won't quickly allow other tasks
to start, so it should not be in the global scheduler.
In fact, asynchronous tasks (that is, tasks that will live for quite a bit of time, and often sleep a lot) should never use
global scheduler, they would steal computing resources from heavy-duty, short-time living ones - and possibly even completely
stall threaded tasks (if all worker threads are executing long-life tasks...).
We could probably even completely bypass the scheduler/task thing here (and directly use threads), but it does not have
that much of an over-head, and still offers easy handling of threading stuff...
Added a helper that ensures a bbox has some non-NULL dimension along all its axes.
Also, fixed some (rather unlikely) NULL dereference cases (though it should not in this context,
`BKE_object_boundbox_get()` can return NULL).
non-power-of-2 texture support. Note that all I did was pass
the correct width/height into glReadPixels; the result may not
be the same as if non2 textures were enabled.
Deviding two ints together never yields a float... Also, logic of various proxies size corrections was quite broken.
Now we should always get the same (relative) size of text whatever proxy setting/render scale is chosen.
from system/user bookmarks' name if possible.
Volume label on Windows was request from T46083, makes Blender more in line
with 'common' filebrowsing on this OS.
And now, we automatically set name of recent entries from the bookmarks, if path
can be found there, more consistent too from user PoV.
Due to how we find kmi to remove and kmi to add when patching final keymap with user defines,
we could actually end up with same kmi for both, see comments in code for details.
Note that it may be a good idea to make user-defined customizations specific to a given base keymap,
instead of applying them blindly?
Since Blender internal strings are UTF8, changed the initialization
of the string to use initWithUTF8String from default encoding.
Fix worked on OSX 10.5.5.
This is called when modifying an RNA property,
however it can be useful to be able to make a properties
update callback run without having to change it.
IMAGE_OT_save_as assumes that active area is an Image Editor and the logic that should return to image editor after saving didn't run after fullscreen was manually exited.
Note that allocating DM arrays from an editmesh is currently not threadsafe,
however even if were resolved, its more efficient to avoid having to do it in the first place.
Previously, the min value of the arrow range was set to be at the origin, but figured out in most cases this is actually not wanted (e.g: force field strength widget min value is -200, meaning at strength=0, the widget would be offset 200 pixels; camera focal length widget min value is 1, meaning widget was constantly offset by -1). Instead, the origin should be where the value of the property is 0.
This might still be wanted for some future cases, so leaving old behavior #ifdef'ed out.
Needs some more work still, especially, it should become a plane widget (currently it's just a new arrow style since it needs almost the same handling as an arrow).
Was requested in IRC, and seemed like a nice project to tackle until we found a way to fix facemap drawing :P
We were still using main borwser's FileDirEntryArr to own memory of entries currently in cache.
That was OK for common caching operation, but if was not released when clearing cache!
Nothing dramatic, since that was cleared too, but less often, so e.g. by changing sorting
options you could pile up more and more no-more-used entries there...
Anyway, there is no reason to do that, much more sound and clean to keep everything
cache-related in dedicated FileDirEntryCache struct.
This means main borwser's FileDirEntryArr is now always expected to not store any actual entry!
Note: this can probably be cleaned up a bit more, but would wait after 2.76 for this!
This was introduced in the fix for T44336 .
The code is now what it should have been in the first place at the time
of multiview commit.
ImageUser->passtype is being removed in favour of bringing
ImageUser->pass back.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D1504
To reproduce the crash:
* Add some shapekeys to default cube.
* Add at least on driver (can be default empty one) to a shapekey value.
* **Make this driver visible in Outliner**.
* Delete all shapekeys.
* Undo.
* Crash.
Root of the issue is outliner reading code in `blo_lib_link_screen_restore()`,
which would try to `restore_pointer_by_name()` for all `TreeStoreElement->id` pointers.
Thing is, those id pointers are not always IDs, they can be animdata, sequence, RNA struct/property...
That's really not so great design, but also has reasons like size of the struct, we have to live with it.
So now:
* TreeStoreElement->type defines are braught back into DNA.
* There we also define a `TSE_IS_REAL_ID` macro to check whether a given TreeStoreElement actually stores an ID pointer or not.
* And in Outliner read code we only try to retore pointers by name for actual ID ones, and set the others to default NULL value.
Also, added clear comment to TSE types that do not store a real ID pointer!
From Gooseberry team request indirect libs were also added at root of 'BlendFile' Outliner view,
but that allowed edition of their path, which is useless...
Found a way to make AVX2 CPUs happy by reshuffling instructions a bit,
so now there's no weird precision errors happening in there.
This solves some render speed regressions on CPU, but unfortunately
this doesn't help for GPU rendering.
This is more an experiment, not guaranteed to work but at the same time
building of kernels seems to work manually in the same chroot. Perhaps
latest changes helped compiler to optimize registers usage.
- add missing uniforms.
- add uniform types.
- link to RNA equivalent.
- remove 'value' from uniforms (they were wrong, better use module members anyway).
- various corrections & edits.
Fixes T45505
As decided in D910, we use a new icon for incremental grid snapping and use its old one for absolute grid snapping.
This also touches the library_data_broken icon .dat files, seems some changes on its .svg entry landed in upstream without updating the other icon files (already noticed this when committing icon for auto-offset, but removed it from commit - leaving it in now to avoid further confusion)
Icon by @plyczkowski (made a tiny edit as it looked a bit blurry in 16x16). Thx!
Now, ctrl+wheel for cycling tabs is passed to hovered button if it supports cycling values (RNA menus, color/row/number/slider buttons, list boxes)
This might feel a bit glitchy if ctrl+wheel is used to cycle tabs and in newly opened tab, a button with cycling support is under the mouse, which will get mouse input from this point on instead of region. Think this is still better than old behavior.
When a modifier was animated by a NLA strip, this animation was not working when using
the old depsgraph. This was because the code which checks if a NLA strip affects any
modifiers was missing - specifically, it was originally left out as it was thought
that it was unlikely that many users would need this, but adding in those checks
would have a (slight) negative effect files where there are heaps of NLA strips
but modifiers animated this way were absent.
The new depsgraph however doesn't suffer from this problem, as these sorts of checks
need ot be built into the graph-building stage for everything to work, so these links
had already been added.
This was simply broken for vertex case (indexing loop normals with vert indices...).
Turns out to be rather verbose to replace on-the-fly zero normals by default ones correctly,
and do not want to make a full copy of the given custom normals array, so now this one is
editied in place (replacing zero vectors by correct default normals). Don't think this
could be a serious issue anyway.
It can't be simply removed in cases when it's connected to input which is
different from Normal. This is because the input wouldn't be connected to
default Normal geometry input, possibly breaking shading setup.
The fix is not really ideal, but should work at least.
This fixes skin having too much glossy reflection in the file from T46013.
Initial idea was to optimize calculation a bit by skipping calculation of actual
triangle edges and use vector from ray origin to triangles. In practice this
optimization didn't quite work in cases when origin point is too close to the
triangle.
Let's do 2.76 with a bit more complicated calculation, still looking into exact
reasons why watertight intersections fails in certain cases, but actual fix might
bit be ready so soon.
This fixes wrong eyes on the lady from T46013.
That one was hairy... To summarize:
* We were setting Bone.head/tail (aka **local** rest location of bone) from EditBone data, using **EditBone's parent computed armature space**.
* We use those local head/tail to define Bone's restpose (in `BKE_armature_where_is_bone()`), using **Bone's parent armature space** (aka parent's arm_mat).
* Because of bone's roll nightmare, the two above parent's matrices will often not be the same.
In an ideal world, this should not affect locations (head/tail), but in real world of float it does - noticeably, in some extreme cases.
So! This commit cleans up things a bit (`fix_bonelist_roll()` was already doing much more than just fixing roll mess, has been renamed
to `armature_finalize_restpose()`), and ensures we do use (final!) parent's arm_mat local space to compute children's local head/tail as well.
This allows us to avoid too much imprecision here.
Checked the patch also with a complete Victor's rig from Gooseberry, seems to have no nasty side effects - fingers crossed!
`fix_bonelist_roll()` is already recursive, and was calling recursive `BKE_armature_where_is_bone()` twice!
Changed `BKE_armature_where_is_bone()` to controll whether we recurse over children or not.
With full Victor's rig, we gain 16% in `ED_armature_from_edit()` (from 31ms to 26ms).
With a dummy test-case 100 bones chain, we gain 80% in `ED_armature_from_edit()` (from 1.25ms to 0.25ms).
Not crucial, but still worth it. ;)
The issue was caused by wrong detection whether number of verticies
changed or not. Basically, it wasn't working correct in cases when
number of verticies is increasing compared to the current frame.
This causes no change in behavior, since code was alreadying doing
a no-op in bmesh_edge_separate if the edge is a boundary.
But it tripped an assert, annoying in debug builds.
We want to leave assert in bmesh_edge_separate in case callers
expect there to be separate loops after this always.
So putting test in caller.
(Same worry about bmesh_urmv_loop? I checked callers and they
appear OK to me - they deal with the no-op return.)
This isn't really complete fix, complete fix would require calculating
derivatives via OIIO API, but supporting this will either end up with
some code duplication or will require some non really safe changes at
this release cycle.
The documentation for bge.render.{setWindowSize,setFullScreen,getFullScreen}
did not mention that those functions are no-ops when using the Blender-
embedded player.
Extensions such as ".tar.gz" are now also supported. Before this patch,
ensure_ext('demo.tar.gz', '.tar.gz') would return 'demo.tar.tar.gz'.
This results in issues with the `ExportHelper` mix-in class; clicking
an existing file in the file dialogue warns about overwriting it
(highlighting the input box in red), but then saves to a different
file.
Also added a unit test for the new behaviour.
Reviewers: mont29, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1498
The detection of needed sharp edges (based on given loop normals) would not fully work
on first run in case we started with a complete smooth cyclic loop fan (edge between
first and last loop of the fan would not get checked).
get_keyframe_extents() would add an extra frame in case of mono-key fcurves in selected set...
Now do the 'not same start/end frames' check later, and also use floor/ceil instead of round
(we want to start at frame 3 if first key is at frame 3.8, reversed-same goes for end frame).
at some point.
Resurrect spell also took care of rewriting function for
the new mpoly GPU scheme.
Subsurf code will also need the same as well.
Note:
Untested code still!
Since data transfer when called from this tool has reversed behavior (it transfers **towards**
active object, as previous tool), we have to also reverse source/destination layers selection options.
Also fix 'reverse' option being saved, otherwise calling regular operator after 'transfer weights'
would stay in reverse mode, ugly!
Root of the issue was, preview generator was filling ID preview with unsigned int,
when RNA only knows of signed integers (and thus generates a python exception
when converting uint outside of int range)...
Using the brand new and much simple float pixels accessor to PreviewImage now.
Why this was working perfectly OK (it seems...) under Linux, and why error (py exception)
was so badly and misleadingly reported on Windows, remains pitch black mystery to me.
Raw int pixels can be nice in some cases (much less memory used), but converting to/from float values
(as e.g. expected by/from Image) is not simple in py, error prone and rather slow.
triangles.
This made the normal-related artifacts of projection painting much more
apparent. Now we do culling based on
whole polygons. Pure backface culling still uses individual
triangles.
painting.
Also system added a brush every time it found no paint brush in the
system which is not what we would want.
Solution:
* Brush panel stays visible always, regardless of whether there is a
brush or not.
* We search for first available brush when we find no brush in paint
struct instead of always generating a new one.
* Generating and searching for a brush take a mode argument now. Needed
some refactoring to users of BKE_paint_init as well.
* Did some style cleanups for paint mode enums.
Patch is big but it's mostly argument refactoring.
Would be much better if we could add a modal handler for widgets, so we don't need to hardcode the keymap, but supporting this isn't easy (I tried it today :/)
Cannot reproduce the issue here on linux, but have the feeling windows builds are much
more easily broken with referencing bad data from bpy. So here guessing direct loop
over bpy.data.xxx when you do add and remove stuff from said xxx inside the loop
is not a good idea - which seems logical in the end. :P
was enabled.
Caused by an -unneeded now- fix for opensubdiv. Code caused the vertex
colors to be uninitialized. Thanks to Sergey for confirming that initial
issue is no longer a problem.
- wasn't checking subframe to see if the scene needed to be re-evaluated.
- unneeded int/float conversion storing original frame.
- moved cleanup block into one place to avoid confusion.
Basically filtering was happening twice, first time by applying weights of EWA
filter itself and then by applying subpixel offset while reading pixel values.
Primary goal of this commit is to fix an annoying issue - when processing and saving .blend
files in background mode you lose their thumbnails, since it can only be generated with
an OpenGL context.
Solution to that is to read .blend thumbnail while reading .blend file (only done in background
mode currently), and store it in Main struct.
Also, this lead to removing .blend file reading code from thumb_blend (no need to have doublons).
We now have a small interface in regular reading code area, which keeps it reasonbaly light
by only reading/parsing header info, and first few BHead blocks.
This makes code reading .blend thumbnail about 3 to 4 times slower than previous highly specialized
one in blend_thumb.c, but overall thumbnail generation of a big .blend files folder only grows
of about 1%, think we can bare with it.
Finally, since thumbnail is now optionally stored in Main struct, it makes it easy to allow user
to define their own custom one (instead of auto-generated one). RNA API for this was not added though,
accessing that kind of .blend meta-data has to be rethought a bit on a bigger level first.
Reviewers: sergey, campbellbarton
Subscribers: Severin, psy-fi
Differential Revision: https://developer.blender.org/D1469
Issue was caused by blender internal accessing data from DNA during rendering.
There's no simple solution to make stuff thread safe, so for now simply restart
rendering on frame update.
The issue was caused by uninitialized ray used for composite and AO evaluation.
Can;t really think of "proper" ray configuration here, it's all a bit arbitrary
but think initializing the ray in a way so we look at the surface in a negative
normal direction is much better alternative to uninitialized ray.
Open for alternative suggestions tho.
This is more like a workaround to prevent obvious cases fail, but in theory
if some other area will start updating object for subframes blender will
crash again.
Perhaps proper way to solve this will be to copy objects for subframe updates.
The issue was in fact caused by both preview and viewport renderers affecting
on the default material, conflicting with each other.
Preview render doesn't really need default material, so we can safely skip it's
initialization in the render pipeline for preview rendering.
Don't force re-distribution of cached particle systems, this doesn't
cause actual evaluation of particles and there was a reason why particles
are baked actually..
This isn't a Blender issue and the same bug happens with official OpenSubdiv
examples. For until it's either worked around from OpenSubdiv side or fixed
in the driver we'll force disable GLSL Compute for AMD hardware.
Uniform block data layout was different on CPU and GPU which caused wrong
data being used from shader.
In theory using layout(std140) is what we need to do, but for some reason
such layout specifier is being ignored. This is probably caused by the way
how we exploit extensions from older version of glsl.
For until we've upgraded our glsl pipeline used different approach which
is basically about removing unused fields form the struct manual in hope
that it'll keep memory layout consistent for both CPU and GPU.
This seems to work so far for both NVidia GTX580 and AMD FirePro W8000
here in the studio.
It was possible to navigate into an unused temp screen
(using Ctrl+Arrow keys), but there was no way to navigate back out.
Now Ctrl+Arrows skips temp screens, and remove the ability to navigate away from a temp screen from RNA.
This reverts commit 1ed1f2f3ab.
Waiting 10 seconds to change view isn't practical.
Further it expose issues where users can attempt to activate tools during view motion,
Some work, others give issues, this just isn't going to be properly supported.
View animation features are fine, but this isn't the purpose of the smooth-view option.
This is a bit tricky one -- ideally viewport should detect whether alpha is used
in the shader tree and if so do separate viewport pass for that objects. But in
practice it's really tricky to detect whether alpha is affected by shader or not
without evaluating the tree for all possible input values. We also can't assume
that alpha might always be affected because it'll slow viewport drawing down.
For until some smart solution is found simply expose alpha blending mode used
by the viewport. It could be found below the Viewport Color settings.
By popular request, restored the ability to shift-click on the X (unlink) button
to unlink the action (from the active action slot), clear the Fake User, and
also remove the NLA-stashed copy (only works for the current object/NLA stack though).
Forgot to increase the size of the string buffer in b88d8916e4
While this wouldn't have caused problems in most cases (since most modifier names
are short), in the rare event that a long modifier name exists, the buffer may have
ended up being truncated prematurely, causing the wrong FCurves to get matched.
It's hopefully no longer needed, at least not needed for as long as
single ptex face corresponds to a single patch which should be always
correct for uniform subdivisions as far as i know.
Implementation is less optimal compared to non-opensubdiv drawing but
it is now as good as we can do it without affecting on how patches are
being created by OpenSubdiv.
By using getAnimRecordFrame(), game developers have access to the frame
number used by the "Record animation" feature. This enables them to
record additional information in Blender's F-Curves and ensuring perfect
synchronization with the information already recorded by Blender.
The setAnimRecordFrame() can be used to change the frame number at which
animations are recorded, for example to introduce delays the recording that
do not require delays in the actual game/simulation run.
The getter/setter functions in KX_KetsjiEngine are not directly named after
property they access (m_currentFrame). I found "current frame" to be too
vague for a public interface, hence chose a more descriptive name.
Reviewers: moguri, hg1, campbellbarton, panzergame, aligorith
Reviewed By: panzergame, aligorith
Differential Revision: https://developer.blender.org/D1449
Use vertex varying data which gives better approximation of normals.
Still not ideal but should be closer for higher poly meshes to correct
normal.
The only way to have proper smooth normals seems to be to implement
patch evaluation in tessellation shader, but that's a bit PITA with
current GLSL usage in our draw code.
* Fix BLI_file_touch, used to add one dummy byte ((unsigned char)EOF) to empty files!
* Get rid of static global temp string in WIN32 area (very bad, and useless!).
* Get rid of paranoid NULL checks in WIN32's BLI_gzopen().
* Add non-relative filename asserts to WIN32 file operations too.
* ifdef-out BLI_move and BLI_create_symlink, unused (and the later is not even implemented for windows).
Partly based on patch and points raised by Jason Wilkins (jwilkins) in T32870, thanks!
The issue was caused by some numeric instability in triangle intersection which
was visible on avx2 CPUs and GPUs (at least sm_20 here) but maybe some others
too.
Committing rather a workaround for now to be safe for the release, still need
some investigation.
From tests with grass field from Gooseberry project didn't see measurable
slowdown.
Instead, we now draw the manipulator with some transparency and without if highlighted. This also helps making the manipulator not so 'in your face'-ish.
Fix T45769: Image Texture Node clipping bug
Simple mistakes in the normalized/pixel-space coordinates handling.
Render tests for this feature are coming.
Avoid memmove() happening on every insert of duplicated node to the references
list. Temporary pre-allocated vector is used for new references which is then
being inserted into actual array in one go later.
Gives around 4x speedup building spatially split BVH for the grass field in the
cassette player shot from Gooseberry.
This commit implements object reference node spatial split making it possible
to use spatial split for top-level BVH.
The code is not in use yet because enabling spatial split on top level BVH is
not coming for free and it needs to be investigated if it's worth in terms of
improved render times.
This way it's easy to add more reference types allowed for splitting to the
BVH reference split function without making this function too much big. This
way it's possible to experiment with such features as splitting object instance
references.
So far should not be any functional changes.
The generic tangent calculation relied on CDDM arrays which aren't available in edit-mode.
Add a tangent calculation callback, which has its own implementation for editmesh data.
Now works as follows with combined manipulator types:
Translate+Rotate: 2-axes widgets hidden
Scale+Rotate: 2-axes widgets hidden
Translate+Scale: Use 2-axes widgets from translate, hide scale ones
Tranlate+Scale+Rotate: 2-axes widgets hidden
We can of course still change behavior later, but would like to get user feedback for this.
It's needed especially for the menu entry "recover auto save" where you'd like to have the files sorted by date most of the time but it could be useful in other places too.
There should be no functional change in other areas, I just added the missing parameter (FILE_SORT_ALPHA).
Was a request from @sebastian_k at #BCon13, so at least one guy needs it ;)
Reviewers: mont29
Reviewed By: mont29
Subscribers: sebastian_k
Differential Revision: https://developer.blender.org/D1476
* Resolved some todo's where FModifier paths were getting identified using the
wrong pattern.
* Added the missing animation -> modifier link. The "hacky" part here is just
to do with how we check if that link is needed; the link though should exist
in the graph.
(hopefully)
Fixes crash when leaving window bounds with cursor.
Seems that new manipulator is now completely working and stable. Next step is to add some new manipulator features :)
Meaning manipulator finally does what it's supposed to do.
There is still a crash when leaving active window while transforming, and drawing of dragged widget is also a bit jiggly, but everything else seems to work :)
This commit makes some tweaks that make it at least possible to use lib-linked
actions as Pose Libraries. Specifically:
* The apply poses button is no longer greyed out
* It is possible to select different poses from the list of poses
* All pose library operators which edit the poses stored in the poselib
now have improved poll callbacks which perform extra checks for lib-linked
actions (which cannot be edited, as all those changes will be lost)
Caveats:
* Due to the way the UI list template works, it doesn't seem to be possible to
make it not grey out the items in the list. (While the double-click to rename
thing shouldn't be allowed, items should at least look like they can be clicked on)
* The difference between clickable vs not-clickable isn't too great, making it hard
to tell that that while the Add/Remove/Sanitise toggles are not usable,
the Apply Poses is actually functional. But, this is a more of a UI-toolbox
level issue
This commit simplifies the logic for finding the control curves for NLA strips,
thus eliminating a whole bunch of weird errors that were happening here. It should
also fix a number of other related issues here.
By default watertight intersections are used,
For callbacks where its not needed,
BLI_bvhtree_ray_cast_ex can be called without the BVH_RAYCAST_WATERTIGHT flag.
Fixes T45286
In fact exit was getting called because we
had an error in shader compilation:
Uniform buffer objects are in fact required.
Since it looks like original intent was to
write the shader against older GLSL version,
I will be adding an extension here instead
of a version.
Thanks to Anshu Arya for letting me borrow his machine through
VPN to do the debugging :)
The callback checks if 2 nodes intersect (not just their AABB).
Advantages:
- theres no need to allocate overlaps which are later ignored.
- expensive intersection tests will run multi-threaded.
Currently only used for Python API.
In the file of the report, stencil and clone indices
have fallen out of synch with the uv/mtexpoly layers.
Looks like the file has a long history, coming from 2.49
even. Unfortunately reporter cannot recall exact steps
to reproduce, so "fix" is to patch mesh.validate to
fix those indices.
Was performing ray-tri intersection checks on all faces.
Note, this isn't using isect_ray_tri_threshold_v3
which was used to prevent ray-casts slipping through between faces.
Instead we'll move to using watertight intersections by default.
An entry could already exist in misc cache, when creating it for block cache, leading to double-creation.
Issue was not that serious (no memleak or so), but nasty still. Thanks to Severin for notifying the assert.
It basically rewrites most of filelist.c, with some more limited changes in other areas of filebrowser.
From user perspective, it:
* Removes some info in 'long' drawing mode (owner, permissions) - OS-specific data that do not really matter in Blender!
* Makes short/long display 'fixed' size (among four choices, like thumbnails mode).
* Allows to list several layers of dirtree at once, in a flat way (inside .blend files and/or real directories).
* Consequently, adds datablocks types filtering.
* Uses way less RAM when listing big directories, especially in thumbnail mode (we are talking of several hundred of MiB spared).
* Generates thumbnails way faster.
From code perspective, it:
* Is ready for asset engine needs (on data structure level in filebrowser's listing).
* Simplifies and makes 'generic' file listing much lighter.
* Separates file listing in three different aspects:
** 'generic' filelisting (in BLI), which becomes a shallow wrapper around stat struct.
** 'filebrowser drawing' filelisting, which only contains current visible subset of the whole list (sliding window), with extra drawing data (strings for size, date/time, preview, etc.).
** 'asset-ready' filelisting, which is used for operations common to 'basic' filehandling and future asset-related one.
* Uses uuid's to handle file selection/state in the browser, instead of using flags in filelisting items.
* Uses much lighter BLI_task handling for previews, instead of heavy 'job' system (using the new 'notifier' timer to handle UI refresh, in similar way to jobs).
* Moves .blend datablocks preview handling to IMB_thumbnail (necessary to avoid storing all datablock previews at once, and gives better consistency and performances too).
Revision: https://developer.blender.org/D1316
Thanks to Campbell & Sergey for the reviews. :)
If we had ambiguity in the SceneRenderView > Suffix matching test, the
first match would be used. And this would happen everytime a
SceneRenderView had an empty camera suffix.
We now take the longest matching suffix instead.
This gives us enough flexibility for some special manipulator drawing with combined axis types (like translate, rotate, scale manipulators enabled all together)
Now we also don't have to use immediate mode drawing.
It might also be interesting to support custom drawing callbacks, but for now this isn't really needed. Let's see!
Based on feedback by @psy-fi
Notes:
* Not yet used, this is the last piece of 'side changes' before the big filebrowser commit.
* We can probably be more effective here (like e.g. reading and storing all previews for a given
group in thumbnails cache at once, instead of re-opening and parsing the whole file each time),
but will do this later.
General idea is that, if several threads are handling thumbnails at the same time,
they can end working on the same file at some point, which will generate conflict.
To avoid this, threads can now lock a given filepath.
Note that locking data is allocated on a ref-count basis, to avoid keeping the GSet
in memory when not needed. Also, we are using global LOCK_IMAGE mutex for now.
Needed for upcomming filebrowser rework.
For popup interactions we need to know if events are in the region or not,
however subtracting the shadow isn't so reliable, since its not always added to all sides of a popup.
Instead, get the winrct value from a popup using the block rect, otherwise the winrct as-is.
Even when lasthit can't be used to find the next address,
use it as a starting point for the full array search.
Gives approx 1/3 less array searching in own tests.
We're now using immediate drawing for arrow widgets instead of using the arrays created using the widget export script.
Although this also includes a thinner arrow generated using the export script, I decided to not use it for now, as the thin lines are drawn a bit ugly. I just #ifdef'ed it out.
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
There is an adjustment pass in bevel that tries to make the bevel
widths at either end of a beveled edge as equal as possible.
When there are hundreds of beveled edges end-to-end, these adjustments
can accumulate out of control and result looks awful.
Yet the adjustment pass is sometimes needed to avoid equally awful
appearances in other cases (see the "Bent test" in the bevel regression
tests).
This change uses the 'Clamp overlap' flag of bevel (on by default in
the modifier, not in the tool) to limit the amount of adjustment to within
10% of the desired width. When the flag is off, there is no limit to the
adjustment.
Issue already existed since rB4ee1de8c3ce6e, used fallback to old manipulator handling since then.
Issue was that we weren't able do identify the highlighted widget after freeing and reinitializing the widget group (as it happens on each redraw). widgets_compare checked the property assigned to the widgets, but since the manipulator widgets trigger operators instead of tweaking a property, it never returned the right result.
Now, instead of comparing widget properties, we use a widget id-name that is unique within it's widget group (see rB3b42468bff06d2).
Hrmpf, and I spent countless hours debugging widget initialization and OGL selection :S
When one edge is beveled at a vertex among more than 1 other unbeveled
edges, the code makes a polygon around the vertex. The position of the
vertices on the non-adjacent-to-beveled-edge edges depended on the
ordering of edges, which leads to inconsistent-looking results in seeming
symmetrical situations. Changed to use the bevel amount as slide
distance, which fixes this.
When using the nmake generator from cmake, numpy fails to extract during build because the working directory doesn't exist yet.
Reviewers: juicyfruit
Differential Revision: https://developer.blender.org/D1466
Fixing crash if the physic type is set sensor or character. Caused by a790e172d0.
Fixing memory leak, if the constraint is deleted with Python API removeConstraint().
Add RemoveConstraint() method to avoid code duplication.
Rename old RemoveConstraint() to RemoveConstraintById() which is more suitable name for this method.
Two problems fixed. One, the comparison of angles to
'almost straight' or 'almost zero' needed a bigger epsilon.
Two, using the corner normal instead of the average face normal
is usually the right thing to do, and what the code was doing,
but in some cases the corner normal could be very wrong.
Steps to reproduce were: startup.blend, move any object, delete active scene (nothing happens), undo (nothing happens), second undo is needed to revert object transformation
* draw lattice boundingboxes in 3dView [if "show_bounds" is used -- an option previously pretty useless for lattices]
* give proper values for lattice objects ".bound_box" in bpy
* give proper values for armature objects ".bound_box" in bpy
* lets users use "Dimensions" [in 3dView Transform panel] on lattices and armatures
* remove redundant calculations in "boundbox_armature()"
Armatures boundingboxes were already drawn in 3dView, if "show_bounds" was used.
Based on report T45735: Lattice's bounding_box doesn't update,
and a comment in code by @campbellbarton ("later we may want to add dimensions for lattice, armature etc too").
Revision: https://developer.blender.org/D1460
Non-uniform scaled obmat will lead to transformation not preserving angles, so
we must ensure our normal is orthogonal to the edge **after** applying obmat.
When using unit system, step was multiplied by 100, could really not find any good reason to that.
Easy to revert anyway if needed, but in this case please explain why in code. ;)
Investigated and patch by Thomas Radeke (ThomasR), thanks.
Fairly large changes to bevel code to do a better job
of keeping UVs from crossing islands, etc.
Updated http://wiki.blender.org/index.php/Dev:2.5/Source/Modeling/Bevel
to explain algorithm used for maintaining UVs.
Updated the bevel_regression.blend tests in lib tests.
This basically does the 'timer' part of Jobs system: it sends a given notifier on every timer step.
This is needed for background tasks (not full-fledged jobs, lighter BLI_tasks based) that want to update UI
(like for up-comming new thumbnail handling in filebrowser).
Not much to add, you can now clear previews from current .blend file, or a set of non-opened files.
Likewise, you can generate previews (for mat/tex, objects, groups, scenes, ...).
Not tested for fedora-like and arch distro, would expect it to work though. Please report otherwise.
Also, always inatll git now (and a few other XOrg -dev packages).
Reading fcurves wasn't really optimal because restoring fcu->group pointer was
changing lasthit pointer, which required full lookup over the oldnewmap happened
at the next call to newdatadr().
This reduces loading franck_sheep.blend file from ~2.2sec to 1.5sec.
This is not so much common panel to access to and having it fully
visible just adds clutterness in cases when one only need to work
with render passes.
Order of saving and reading particle point cache was totally different which
made newdataadr() falling back to full data block list traversal for every
point cache entry.
This commit makes it so reading code uses the same order of reading structs
and lists ad the writing code. This required to add special version of list
linking which is capable of running a callback after linking a list element.
This seems to be more robust approach than splitting writing code into
several loops.
Use --skip-osd to skip building opensubdiv libs,
use --force-osd to force a rebuild of the libs.
I added all needed user information (where to find the include dir, which -D options to set) to the print_info method that is called at the end too, so it should be pretty intuitive to use.
Reviewers: sergey, mont29
Reviewed By: mont29
Subscribers: mont29
Differential Revision: https://developer.blender.org/D1452
This is likely weak design, but allows people to change several settings without having to wait
several tenth of seconds each time, when e.g. transferring UVs between heavy geometries.
Null-area face could generate an int overflow, and potential numerical imprecision in face area computation
could lead to negative number of rays-to-cast (though highly unlikely).
Also, use domnant axis of poly normal as 'flattening' one, instead of always using Z axis.
Points raised by Campbell, thanks!
I can't reproduce issue here but crash is most likely caused by passing
a NULL pointer to glUniform2fv.
This is caused by OpenSubdiv changes to the codegen module, which pass
mtex layers to the uniform system
even when not needed.
Since Sergey is demoing OpenSubdiv in a few days, I'll
go with the easy fix for now which is just checking for NULL pointer, but
this needs to be fixed properly at some point.
Sliders in for FCurves in the animation editors were leaving space for
one extra setting that they didn't need to be accounting for (and which
wasn't shown, as it isn't valid for FCurves).
Restored the "New Layer" button in the NKEY Grease Pencil panel (as was found
pre-2.73) for two cases:
1) When no Grease Pencil datablock is active - This shortcut makes it possible to
add a new layer to start drawing in with a single click again (instead of two
clicks - one to add a datablock, and a second to add the layer)
2) When there are no layers - There is no need to display the UI list in this case,
thus saving a bit more space in the rare cases where this applies.
After some testing of the behaviour of this stuff, it became clear that the current
pressure handling here isn't very useful. The initial point would invariably get a
low pressure value (due to the way that the initial tap needs time to "take"), while
the end of the stroke suffers from similar issues (i.e. when the pen is released).
Meanwhile, the line thickness would flicker while drawing the stroke, as the endpoint
pressure varied.
So, until we find a better way, all straight line segments are now drawn without
pressure sensitivity.
This is currently a requirement of OpenSudiv and original orientation code
was depending on this quite a lot.
This makes mesh conversion and comparison slower but solves some crashes.
With some trickery it could be optimized and become closer to original
performance.
Probably Campbell has some nice ideas here as well :)
Use first material slot for until multiple materials are fully supported.
Also respect setMaterial()'s return value to avoid drawing unnecessary
geometry.
Make it so CCGDM reports 0 number of geometry when it uses GPU backend for
drawing. This screws up a bit statistics in info header and requires to have
some special handle of CCGDM in the drawing code, but makes it so non of the
areas will try to access non-existing geometry.
Mirror modifier was reporting that it depends on geometry of the object
used for mirror center which is incorrect -- only object matrix is needed
for modifier evaluation.
This commit makes sure Linux and Windows buildbots are using OpenSubdiv
and also enables OpenSubdiv by default on Windows.
OSX is kept disabled still, this is due to OpenGL restrictions which are
not solved in any way yet.
Linux is defaults to OpenSubdiv disabled because it needs precompiled
library.
The documentation could be found there:
http://wiki.blender.org/index.php/User:Nazg-gul/OpenSubdiv
Recent changes to kernel broke compilation of the kernels again, need some
other kind of solution for this issue.
Don't have much time for this currently, but will be addressed before the
release.
Meanwhile it's better to have some buildbot builds instead of totally failing
one.
The issue was caused by the following construction:
def = env['SOMETHING']
defs.append('SOMETHING_MORE')
Since first assignment was actually referencing environment option it was totally
polluted hawing weird and wonderful side effects on all other areas of Blender.
The old method:
The "old" method used the node dimensions to get a number of lines and checked if they intersect with the node link. Issue with this is that only a small part of the actual node surface is checked, making the method a bit unpredictable or unresponsive.
The new method:
The new method checks for intersections within the entire node surface. If multiple links are intersected, the node with the smallest distance from the *upper left corner* to the link is chosen.
Reviewed by @campbellbarton (tm)
The idea is to cut as much code as possible and use compile-time
ifdefs rather than runtime if() statements.
Gives about 2x speedup on catmark_car model from OpenSubdiv repository
making our FPS much closer to what glViewer is capable of.
It works similar to getActionFrame(), you have to give a layer or not (for layer 0) as the argument and it returns the name of the animation that the object is currently playing.
Example:
```
import bge
own = bge.logic.getCurrentController().owner
own.playAction("SomeAction",0,20)
print(own.getActionName())
```
>> SomeAction
Here is an example file, just open the blend file with the terminal opened
and press P, you can see how the current animation is being printed:
{F217484}
Reviewers: moguri, hg1, panzergame, campbellbarton
Reviewed By: panzergame
Subscribers: campbellbarton, hg1, #game_engine
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1443
Use OpenGL 3.2 extension ARB_draw_elements_base_vertex, which allows us
to add offset in index buffer indices automatically. This should reduce
the number of draw calls significantly.
We may have some errors on the Mac with VBO setting off.
OSX OpenGL extensions don't play well with vertex arrays.
Will test that more later.
We might also use a full element buffer here, like we do when hiding
some quads, but this approach keeps the memory savings intended
originally.
The idea of this commit is to make it so we can enable OpenSubdiv by default
for the release builds but keep it limited to the viewport only for a specific
meshes. This is a temporary solution for until all the needed features are
supported on the OpenSubdiv side.
Flag itself is done as a dedicated field in modifier DNA so we can easily
remove it in the future without ending up with some temporary flag hanging
around forever.
Was overdrawing the buffer, in case of fast drawing just use one
draw call. Should also make performance quite smoother.
Note:
Just discovered we are doing one draw call - per grid - in multires
apparently to keep reusing the same element buffer.
This is horribly, dreadfully slow and will check about fixing it later.
The issue was caused by CCG code being confused by number of geometry returned
by utility functions in the case of the skipped grids.
Made it so that code is always only working with CCG data and handled drawing
code in a bit special way now.
This solves such crashes as i.e. snapping.
Cases like using subsurfed object as a boolean operand can't be evaluated
on GPU and needs to have all the CCG on CPU.
This commit resolves existing configuration to survive, but new configurations
would need to have some sort of forced object update so all the data is being
moved on CPU if it was previously on GPU.
Was intended to be disabled in rBa3b86611a8182, but disabled 3D View FPS drawing instead of VSE drawing. Triple checked but 3D View doesn't draw FPS now, so everything seems fine now.
Note: To recreate this you had to play animation once before scrubbing.
After scrubbing, Blender kept thinking an animation is played (see animation "Play" button), even after mouse release. This resulted in a couple of crashes, e.g. by pressing Alt+a and then Esc.
(Also minor cleanup)
Implements "Auto-offset" (called "insert offset" in code) feature for Node Editor, developed during and after LSOC :)
Idea and sponsoring by Sebastian König, blendFX, Mathias Eimann, Mikavaa, Knick Design
When you drop a node with at least one input and one output socket onto a an existing connection between two nodes, Auto-offset will, depending on the direction setting, automatically and animated move the left or right and all of its following nodes away to make room for the new node.
The direction for offsetting can be toggled while you are moving the node by pressing „T“.
The auto-offset is enabled by default but can be disabled in the header of the node-editor. The offset margin can be changed in the editing section of the User Preferences.
Thanks a lot to the sponsors, and especially to Sebastian who helped *a lot* with this. That's how users can help developing Blender!
Needed for node insert offset (Auto-offset in UI), but kept separate so people notice it without having to check insert offset commit (not for commit ratio of course ;) )
With multiple branches it was possible the search could run for a long time,
especially when there was no possible path to the target.
Now use a heap to keep track of the best path and finish immediately once its reached.
Two issues here, normal update was not happening due to own sillyness in
viewport refactor, also normal update code still used triangles.
Now reused Campbell's poly normal recalculation code.
This is an alternate fix for T40964 which resolves bad handling of
caustics reported in T45609.
There were too much transmission rays being discarded by the original
fix, which caused by caustic light being totally disabled. There is
still some room for investigation why exactly original paper didn't
work that well, could be caused by the way how the pdf is calculated.
In any case current results seems rather correct now.
Note that the collision modifier doesn't have any use for Loop indices,
so to avoid duplicating the loop array too,
MVertTri has been added which simply stores vertex indices (runtime only).
Notes:
* Code in rendering and in game engine will still convert
tangents to a tessface representation. Added code that
takes care of tangent layer only, might be removed
when BGE and rendering goes full mlooptri mode.
* Baking should work discovered some dead code while
I was working on the patch, also tangents are broken
when baking from multires (also in master), but those
are separate issues that can be fixed later.
This should fix T45491 as well
plane.
Make sure sculpt plane is recalculated for every tiled dab.
Note this is not the optimum thing to do, we could cache the original
sculpt plane and reuse that, but this would require us to rearrange the
logic of tiled sculpting somewhat. This can be a TODO, but for now this
will fix the issue.
* Did not check data2, this partially fixes T45583.
* Initialize data2 in some closures to avoid potential problems.
Differential Revision: https://developer.blender.org/D1436
Basically it's a clean keyframes tool, but also removes a channel if the
only remaining keyframe has the default value only and is not used by
drivers or generative modifiers.
It's was used to help with performance of keyframe-heavy scenes in
gooseberry.
Note, as always the curve left after the clean tool is used is not the
same as the original, so this tool is better used before doing custom
editing of fcurves and after initial keyframe insertion, to get rid
of any unwanted keyframes inserted while doing mass keyframe insertion
(by selecting all bones and pressing I for instance)
Originally D966 by @lukastoenne, with own additions
- trees can be initialized from Object's, BMesh,
or passed in as vert+polygon arrays.
- original indices of ngons/faces are used. (instead of tessellated indices).
- ray_cast, find_nearest methods
- find overlapping faces between 2 trees
This code is not thread-safe and there's no easy way to synchronize
render and viewport threads for this operation, so for until we've
got some nicer solution we just disable dangerous buttons.
The issue was caused by the non-threaded texture API used by the node.
While the node itself is single threaded there might be texture nodes
in different execution groups running in parallel.
Clipping wasn't working totally correct, need to check original coordinates,
not the integer ones,
Now CPU gives the same exact results for both SVM and OSL, CUDA is still doing
something crazy with edges.
- rename WITH_EXTERNAL_AUDASPACE to WITH_SYSTEM_AUDASPACE.
- rename C/PYAUDASPACE to AUDASPACE_C/PY
- simplifying cmake defines and includes.
- fixing include paths and enabling WITH_SYSTEM_AUDASPACE for windows.
- fixing scons building.
- other minor build system fixes.
The navigation mesh functionality was broken for quite a while. This patch
contains fixes: recalculating tesselations before getting the number of
tesselation faces (it otherwise returned 0) before calculating the navmesh,
and calling `DM_ensure_tessface()` on the navmesh's `DerivedMesh` object
(which fixes visualisation in Blender). This allows one to create a new
navmesh, which also works in the BGE.
Furthermore, the patch adds several return values, and shows more error
messages when things go wrong. In several places in the navmesh creation
code, return codes weren't checked and errors silently ignored.
Reviewers: nicks, brita_, campbellbarton, lordloki, moguri, panzergame
Reviewed By: panzergame
Differential Revision: https://developer.blender.org/D1435
Technically it was all wrong and it should have been called Extend instead
of Clip. Got confused by the naming in different libraries.
More options are still to come.
This commit fixes shader tree compilation, but the shading result wouldn't be
doing actual refraction because it's a bit involved change which isn't really
considered a bug for now. There are more closures which are falling back to
diffuse BSDF currently.
Previously Linux had disabled libs that were enabled on other platforms.
Use a reduced feature set on all, since libs such as Jack & OSL aren't totally reliable on Win/OSX.
Keep 'option_defaults_init' since platform maintainers may want to adjust later.
Actually for the the amount of GLSL textures units is limited by the amount of multitexture units (GL_MAX_TEXTURE_UNITS_ARB).
Most of the Nvidia graphic cards supports only 4 multitexture units, so Nvidia users can not use more then 4 GLSL textures for a custom shader.
This patch removes this limitation by using GL_MAX_TEXTURE_IMAGE_UNITS_ARB if GLSL is supported, but still limit the amount to the maximum texture limit of 8.
Reviewers: lordloki, agoose77, danielstokes, panzergame, sybren, moguri
Reviewed By: panzergame, sybren, moguri
Projects: #game_engine, #game_rendering
Maniphest Tasks: T37074
Differential Revision: https://developer.blender.org/D1389
The code does stupid box filter which doesn't give nice results and doesn't
match old compositor at all. Need some better gaussian weighting here. Will
look into it later.
Deprecate wrap (BRUSH_TORUS) option, we now have paint flags for tiling
and we can reuse those. Also allows seperate tiling in X/Y
direction for 2D painting now.
Only one tiling is allowed for now.
Options can be found in new "Tiling" panel under the tools tab.
For version patching, we just turn off brush wrapping,
to allow reuse of the flag in the future.
New option is paint mode wide instead of per brush so
a brush having the old wrap option will not enable it
for the whole mode in the version patch.
Upstream is not always configured ad might give empty results.
Ideally we need to re-use the same code as we use for buildinfo,
but it's also a bit of a question which exact hash we want to put
to the name by default.
Did this in packaging buildbot rule because of several reasons:
- CMake doesn't deliver name of package which we expect it to be for buildbot
- CMake doesn't really know that building happens for buildbot
- Making default CPAck name matching buildbot's naming is kinda stupid
Probably we can pass CPack name via command line arguments, but i'm happy with
the current state and one might change things in the future.
It now takes (almost) the whole available width of the region. Icons on the right hand side are hidden during text input now, they can't be used then anyway. Using this space for the text input button makes more sense.
This commit begins implementation of the idea about hidden face
separation outlined in
http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh-
We split hidden and visible faces to different parts of the triangle
buffer.
Mapped drawing will now skip iterating through hidden polys.
Of course the final target, when all derived mesh types use
VBO sorting, is to skip checking for hide flag per face
completely. All faces will be pre-sorted anyway and we'll
be able to draw them with one draw call.
Constraint on soft bodies are special and return 0 as constraint id.
So we have to check that the id is not 0 in function setParam, getParam, getAppliedImpulse and removeConstraint.
Loose edge count was double. It didn't fail on own
tests because they had a small number of loose edges,
but for bigger meshes it hit garbage indices at draw time
and crashed.
Also cleaned up the code to make it less verbose and easier to
understand how indices are counted.
Hope it's the last edge-related fix (fingers crossed)
This commit fixes issues with wrong socket type being added to the Cycles debug
pass compositor operation, which lead to crashes with non-value pass types.
This commit also reverts socket renaming thing because while it's was behaving
ok on runtime file reload might have loose the links which is annoying.
Currently only works correct with single float output, RGBA and vector are not
supported so if one need to use this passes he'll need to wait a bit still.
It is coming, don't worry.
Adds 3D-Tiling options to the sculpt tool. This is very similar to the
symmetry options in the sense that it replicates the strokes. For tiling
this replication happens with a linear offset to fill the whole object
along one or more axis.
This allows to create geometry that can be tiled seamless. One use case
is the creation of tileable textures by sculpting high resolution
geometry and then rendering it with an orthographic camera to create
maps for diffuse, normal, etc
Notes:
Patch by Tilman Blumhagen with minor changes (move tile flags to paint
symmetry flags).
After some feedback from artists, leaving tiling value to constant
offset, though I suspect that some method that uses the object
bounding box dynamically might be good to have too. It can
be added later though :)
Thanks a lot for the patch!
Patch: D1426
Also the refactor exposed an error where we requested too much
memory from the video memory in general for all mesh types.
Now we are back to normal :)
This is the same as D1427 / 89e5c75666
except for NlaStrip.fcurves instead of Action.fcurves. It makes finding
a specific fcurve in Python much easier, as you don't need a Python-side
loop any more.
Reviewers: aligorith
Reviewed By: aligorith
Differential Revision: https://developer.blender.org/D1430
This is a regression introduced in rBce729677db3e and rBb408d8af31c9.
RoundCapShader and SquareCapsShader had to remove (almost) overlapping
stroke vertices to avoid sudden thinning of line thickness. For instance,
the test .blend file from https://developer.blender.org/T36425#231460
suffered from the reported line thinning (although T36425 was originally
caused by a different bug).
Previous fix didn't work well enough because on Windows Python has different
environment than Blender ans setting variables in there made no effect from
Blender point of view.
Issue was introduced in b0df196.It's not the nicest ever solution but it's
quite close to be as nice as we can do it with current custom nodes and
notifier system design.
Weights were calculated using tessellation data, giving slightly uneven weighting.
Now only use tessellation for ray-cast but weight the influences from the original polygons.
Also cache arrays from derived-mesh, they we're called each intersection.
Now the conversion code uses mesh element mapping to speed up lookups.
Gives really nice speed improvement here, but the cost is higher memory
usage during refiner construction.
On the dragon scene here topology refiner construction time goes down
from 5 seconds to around 0.01.
It's possible to reduce the memory footprint by allocating mapping in
stages (don't allocate all of them at once, but do it on demand only
and free them after they're not needed anymore).
Caused by own rBff3d535bc2a6309 - since we now only write the exact amount of layers
needed to store saved customdata, we have to adjust CustomData->maxlayer too.
Otherwise, on next read, customdata code believes it has more layers allocated than
actual number.
Issue reported by Campbell over IRC, thanks.
The error was "ValueError: Function <function normal_at_I0D at 0x7f2aad1feb70>
has keyword-only arguments or annotations, use getfullargspec() API which can
support them", and was first seen in eeeb845d33
That was basically not an issue with interpolation, but rather missing wrapping
options and periodic wrapping was always used.
It's still a bit questionable why certain graphics cards were doing clamping in
the file from the report, that's not something what is expected to happen from
the settings of textures being passed to GPU. In any case this issue i still
didn't manage to reproduce on any of the available GPUs, might be something
related on driver glitch or so.
In any case CPU now should behave just fine, rest of the issues we'll need to be
able to reproduce first.
Currently only two mappings are supported by API, which is Repeat (old behavior)
and new Clip behavior. Internally this extension is being converted to periodic
flag which was already supported but wasn't exposed.
There's no support for OpenCL yet because of the way how we pack images into a
single texture.
Those settings are not exposed to UI or anywhere else and there should be no
functional changes so far.
Works totally similar to camera motion blur and majority of the changes are
related on just passing extra arguments to sync() functions.
Couple of things still to look into:
- Motion pass will not include motion caused by the zoom.
- Only perspective cameras are supported currently.
- Motion is being interpolated on projected coordinates, which might give
different results from constructing projection matrix from interpolated
field of view.
This could be good enough for us, but we need to consider improving this
at some point.
Reviewers: juicyfruit, dingto
Reviewed By: dingto
Differential Revision: https://developer.blender.org/D1383
I suspect code here can be cleaned up but for now try this.
Alternatively we can check for errors around buffer allocation
but this needs bigger changes.
Finding a specific F-Curve is often needed in Python, and usually
consists of a construct like:
```
[fcurve
for fcurve in ob.animation_data.action.fcurves
if fcurve.data_path == "location"][1]
```
This can now be written as
`ob.animation_data.action.fcurves.find('location', 1)`
This new function `Action.fcurves.find()` is still O(N) in the number
of FCurves in the Action, but at least it allows us to remove
boiler-plate code. It is also faster than the Python equivalent, as
only the found F-Curve is converted to Python.
Reviewers: campbellbarton, aligorith
Reviewed By: aligorith
Differential Revision: https://developer.blender.org/D1427
properly.
This should fix failure to use vertex arrays in OSX with high
polycounts.
Note this will not suffice as a fix when we move to VBOs exclusively
(GL 3+), we'll have to think of some way to separate huge meshes to many
VBOs.
Issue is rather well explained in T45471: our current customdata writing code easily generates several different blocks in blend file with same 'old' address. This is bad, because those addresses are used as 'uid' during reading process (it kind of work in Blender's own reading process, by mere luck mostly, but breaks the file specs).
Solution (suggested by Campbell, thanks) implemented by this patch is to avoid duplicating everything, and instead just overwrite what we needs to skip some cdlayers on write:
* the CustomData's `totlayer` number;
* the CustomData's `layers` array of CustomDataLayer (keeping its original address using the `writestruct_at_address` helper).
New design allows us to get completely rid of the no_free flag stuff in `write_customdata()`.
Note that this implies written data is **not** directly valid from Blend PoV, since its written typemap does not match written layers (this is not an issue because typemap is rebuilt on read anyway - and it's easy to fix this if really needed).
Also, the backward compatibility saving of mface data remains an issue here, see comment in code.
Reviewers: sergey, campbellbarton
Projects: #bf_blender
Maniphest Tasks: T45471
Differential Revision: https://developer.blender.org/D1425
This commit contains all the remained parts needed for initial integration of
OpenSubdiv into Blender's subdivision surface code. Includes both GPU and CPU
backends which works in the following way:
- When SubSurf modifier is the last in the modifiers stack then GPU pipeline
of OpenSubdiv is used, making viewport performance as fast as possible.
This also requires graphscard with GLSL 1.5 support. If this requirement is
not met, then no GPU pipeline is used at all.
- If SubSurf is not a last modifier or if DerivesMesh is being evaluated for
rendering then CPU limit evaluation API from OpenSubdiv is used. This only
replaces the legacy evaluation code from CCGSubSurf_legacy, but keeps CCG
structures exactly the same as they used to be for ages now.
This integration is fully covered with ifdef and not enabled by default
because there are several TODOs to be solved first:
- Face varying data interpolation is not really cleanly implemented for GPU
in OpenSubdiv 3.0. It is also not implemented for limit evaluation API.
This basically means we'll have really hard time supporting UVs.
- Limit evaluation only works with adaptivly subdivided meshes so far, which
basically means all the points of CCG are pushed to the limit. This gives
different result from old code.
- There are some serious optimizations possible on the topology refiner
creation, which would speed up initial OpenSubdiv mesh creation.
- There are some hardcoded asumptions in the GPU and DerivedMesh areas which
could be generalized.
That's something where Antony and Campbell can help, making it so the code
is structured in a way which is reusable by all planned viewport projects.
- There are also some workarounds in the dependency graph to make sure OpenGL
buffers are only freed from the main thread.
Those who'll be wanting to make experiments with this code should grab dev
branch (NOT master) from
https://github.com/Nazg-Gul/OpenSubdiv/tree/dev
There are some patches applied in there which we're working on on getting
into upstream.
Those files are still not in use (SCons will tyr to compile new CCGSubSurf files
but no code will be in use at all because those new files are fully wrapped by
ifdef WITH_OPENSUBDIV check).
This includes C-API bindings in intern/opensubdiv and CMAke module
which finds the OpenSubdiv library. This filea are not in use so
far, making it a separate commit to make actual integration commit
more clear.
This is a preparation commit for having OpenSubdiv integrated into Blender
and new layout is the following:
- CCGSubSurf.c contains implementation of common functions used by both
legacy subdivisions code and by the new code in the future.
- CCGSubSurf_inline.h contains internal functions which are to be inlined
due to the performance reasons. Those functions are only ment to be used
bu CCGSubSurf* files.
- CCGSubSurf_intern.h contains declarations of private functions and data
structures used by CCGSubSurf module.
- CCGSubSurf_legacy.c contains legacy implementation of subdivision algorithm.
- CCHSubSurf_util.c contains utility functions which are not directly related
on the subdivision code (i.e. debug functions, hash implementation etc).
There should be no functional changes so far.
defvert_find_index() & co now assert when '-1' invalid vgroup index is passed.
We used to rely on NULL value returned in this case, but with the assert...
The assert completely stalls blender actually (repeated for every vertex!).
So much better to not call that func when vgroup index is invalid.
It was always only using the flags from the first source layer of a given type, not from
the layer actually being handled.
This was (probably) more or less harmless for the CD_FLAG_NOCOPY test,
but could be really bad when checking CD_FLAG_NOFREE, and when
copying the flags over to new copied data!
Correcting the paths for buildinfo to point to the real header,
ended up breaking buildinfo (by not running every build).
It turns out we relied on the output _never_ existing,
so CMake generates a new buildinfo each time.
This is quite bad, but I didn't see a way for CMake to do this,
so explicitly point to a missing file and comment whats going on.
Fix T45381: Crash Blender 2.75 in Win7 x64 AMD card
The issue is basically caused by graphics card driver which crashes when
querying OpenCL platforms. This isn't something we can really solve from
the CLEW side, because opencl.dll does exist in old driver and even has
all the needed symbols, but first ever call to clGetPlatformIDs crashes.
While rest of the blender works fine with those older ATI/AMD cards it's
really needed to solve crashes of OpenCL device enumeration.
Solution here is to force disable OpenCL platforms if we've detected that
display card is using old ATI/AMD driver. It's not really proper solution
so it's done in the python side where it's easy to do tweaks. Reasoning
behind this change is:
- If one uses really old driver it's likely because it's the latest one
he/she can ever to install (because of discontinued support from AMD).
- If old card is used it's likely to not have dedicated GPUs for rendering.
- Even if there's a dedicated GPU device enumeration is likely to crash
because of attempt to query OpenCL from the old card.
There are still some tweaks needed likely, but this commit should make
some of the configurations to work.
extensions, once to get final context extensions.
Not so nice because we get a warning on startup from GLEW, but at least
it GL extensions should work now.
Several class member variables were removed (at the cost of computing their values
when retrieved) or changed to a type of smaller size. Also fixed whitespace.
There was possible race condition in the point density sampling caused
by access to the same data in particle system from sampling thread and
sampling initialization.
Could have happened when two different point density textures were using
same particle system
This commit implements point density texture for Cycles shading nodes.
It's done via creating voxel texture at shader compilation time, Not
totally memory efficient, but avoids adding sampling code to kernel
(which keeps render time as low as possible), In the future this will
be compensated by using OpenVDB for more efficient storage of sparse
volume data.
Sampling of the voxel texture is happening at blender side and the
same code is used as for Blender Internal's renderer.
This texture is controlled by only object, particle system and radius.
Linear falloff is used and there's no turbulence. This is because
falloff is expected to happen using Curve Mapping node. Turbulence
will be done as a distortion on the input coordinate. It's already
possible to fake it using nose textures and in the future we can add
more proper turbulence distortion node, which then could also be used
for 2D texture mapping.
Particle color support is done by Lukas, thanks!
The idea of this node is to sampling of 3D voxels at a given coordinate
supporting different mapping strategies (world space mapping, object
local space etc).
Currently not in use, it's a preparation step for supporting point density
textures.
The idea is to give artists a simplier way to control memory usage in such
scenes as grass fields by doing automatic object culling based on whether
object is visible in the frame or not.
This is controlled on per-object level. In order to use this option few steps
are required:
- Enable Simplify in scene settings
- Enable Camera Cull option in the Simplify panel
- Set camera cull margin (measured in relative value to the render resolution)
This setting is used to avoid possible flickering caused by changes in shadow
which are cast by objects outside of the frame.
- Enable Camera Cull for objects which are desired to be culled
(object culling option could be found in Option panel in object buttons).
There is still room for improvements, but this worked quite well during
Gooseberry open movie project, so think it's useful feature even in it's current
non-ideal state.
This means render devices now might skip building baking kernels in cases when
only actual render-related functionality is used.
For now it's only implemented for OpenCL split kernel device and mainly needed
to work around some compiler-specific bugs which crashes on building the kernel.
Using OpenCL for baking might still crash the driver, but at least there is now
higher probability of that GPU will be usable to render the scene.
Real fix should actually be done in the driver side.
The idea is to make all kernels as small as possible to work around possible
issues with buggy drivers which might fail building feature-complete kernels.
It's indeed just a workaround to make at last simple test scenes to render
on OpenCL. Real fix should happen from the driver side.
Main issue in previous code was that you could not shift-alt-rmb select several
contiguous strips, result was pretty much unusable.
Also, enhanced general behavior of this selection mode, now (similar to alt-rm clicking
on handles), when you alt-rmb click on a same strip several times, you alternate between:
* Strip is selected, neighbor handles are selected;
* Strip and its handles are selected, neighbor handles are selected.
…which allows you to either grab or slide the strip.
And refactored a bit code too, linked_handle has a complete different logic
than without this option, simpler and clearer to completely separate them in code.
Initial issue reported by Leon Cheung on IRC, thanks!
It gives issues with Glog compiled in release mode.
Need to revisit the directory layout here and compiler flag, because technically
libmv is now more an intern/ library and i'll actually prefer it to be covered
with strict flags as well. But it's a bit tricky because of libraries which we
don't maintain are in the libmv subfolder.
It is rather annoying attitude nowadays to use const qualifier all over the
place, including using it for multi-dimensional arrays. This isn't really
supported in GCC prior to version 5.0 because it considers such an arrays
to be a "pointer to a const pointer" which gives implicit casting errors.
It's not possible to disable this particular type of warnings treated as
errors in any GCC version prior to 5.0 as well, meaning currently usage of
-Werror globally in Blender code is not possible at all.
This commit makes it possible to use -Werror in areas which are complaint
with older GCC versions. New advanced CMake options are:
- WITH_COMPOSITOR_WERROR
- WITH_LIBMV_WERROR
- WITH_CYCLES_WERROR
This is basically a bad-level call: ui scripts are registered *after*
the modules. It only works for addons because those are loaded even
later.
Now the nodeitems_utils module just defines a function which is then
called by the UI script, rather than the other way around.
This stores loop indices into the loop array giving easier acess
to data such as vertex-colors and UV's,
removing the need to store an MFace duplicate of custom-data.
This doesn't yet move all internal code from MFace to LoopTri just yet.
Only applies to:
- opengl drawing
- sculpting (pbvh)
- vertex/weight paint
Thanks to @psy-fi for review, fixes and improvements to drawing!
Revert "BGE: Cleanup : merge 3 loop in 1 in function DupliGroupRecurse."
This reverts commit 371e5f25a0.
The fix is basically to revert the cleanup commit 371e5f25 (and 3d658bf7)
Also 5dc22fbbf had to be adapted to the reverted code.
Conflicts:
source/gameengine/Ketsji/KX_Scene.cpp
Issue was that with those files, Blender generate a float image by default, not a byte one...
Now, we ensure in two places we only get a byte imbuf for our thumbnails!
Issue was caused by deform vert layer existing in the mesh.
Solved in quite simple way, but it still might be missing
some other layers.
Any custom data experts around to check if it's correct?
Remove legacy code completely, now dyntopo, multires et al even work on
GL 1.1 for really hardcore users :p
Real purpose here though is to be able to have fast multires drawing
even with VBO off, since it requires using indices for vertex buffers.
Also made own code elf puke an eaten normal update function which
made multires not update normals in solid mode...sorry.
Turning on importance sampling on area lights increases noise on diffuse
surfaces. This was caused by PDF calculated for an intersected point on
light instead of original light position.
Patch by Stefan with some own modifications.
Get rid of legacy drawing, it's only used for selection,
in which case we can prepare a temporary color buffer and draw
at once. Code is not complete here because we still redundantly
set the draw color in the draw function and don't ommit hidden
faces automatically. Still it works 100% without immediate mode
now.
Missed adding return value in one place.
Thanks a lot to Thomas Szepe for reporting the issue and finding the solution!
Question remains: how could MSVC allow such a code to compile in some cases
(own win64 + scons buildbot win32 were OK with that it seems!).
Crappy compiler, not comming to the rescue of stupid dev...
Requires having latest El Capitan beta 3 OSX due to ome crucial fixes made in the
compiler. Supports same features as NVidia OpenCL apart from CMJ (there's no
experimental feature set support in megakernel yet).
Uses megakernel internally, which works much better than the split kernel. Split
kernel is not supported on OSX still, needs to be investigated still.
Some more details can be found there:
http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/OpenCL#AMD_on_OSX
In fact, filebrowser was not making any checks for invalid file/dir names here!
Added checks in the three places that should be protected:
* Renaming.
* Creating dirs.
* Typing in filename field.
BLI_filename_make_safe had several issues:
* Would replace all dots ('.'), not a great idea since it would break extensions.
* Was not checking for 'control' ASCII chars (though unlikely, better to be safe here).
* Win32 only: was not checking for forbidden names (con, aux, ltp0, com0, etc.).
New BLI_path_make_safe() simply checks each path's item with BLI_filename_make_safe().
With this patch "Particle Info" node from Cycles works in GLSL and BI
Alexander (Blend4Web Team)
Reviewers: psy-fi
Note: moved particle info to object render instance instead of
shadeinput during review - Antony.
Differential Revision: https://developer.blender.org/D1313
This patch changes the way we draw meshes by introducing
indexed drawing. This makes it possible to easily
upload and rearrange faces ad lib according to any criteria.
Currently we use material sorting but textured sorting and
hiding will be added to optimize textured drawing and skip
per face testing.
It also adds support for vertex buffers for subsurf
modifiers (Except from GLSL drawing), making drawing of
subsurf much faster without need for bogus modifiers.
Tests show that we gain approximately 20-25% performance
by that for solid mode drawing with up to 50% gains for
material drawing. Textured drawing should also have a
small performance gain, but more substantial optimizations
are possible there.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1406
Two issues fixed in this commit:
- Clearing or adding animation via python should ensure relations are valid.
- Animation component animation data might be null caused by removing animation
from python.
- avoid searching for vertex group for each vertex.
- add support for mass and spring weights to lattice.
- multiply the vertex group weight by the overall goal weight value.
This was causing the BGE to crash on Debug mode when built with "break on asserts", meaning the BGE was not debuggeable.
Please make sure to test patches in debug mode with the proper flags enabled before committing
This allows to match and transfer data between two meshes with similar shape but complete arbitrary different transform.
Note that the result will be best if the meshes (more precisely, their vertices) are exact copies of each other.
Otherwise, method used can only perform an approximated best match, which means you'll likely get better
results if you 'visually' make them match in 3D space (and use 'Object Transform') instead.
Title says pretty much everything. For now, only thing available is a solver of eigen
values/vectors for self-adjoint matrices.
We can easily add more when needed.
Thanks to Sergey and Campbell for quick review.
From artists perspective it makes sense to always apply displacement in a local
space.
TODO: Double-check that BVH is being packed properly. From quick tests seems it's
all fine, but might be missing some obvious failure still.
ImBuf types were getting stored as bitflags in a 32bit integer which had
already run out of space. Solved the problem by separating file type to
an ftype enum, and file specific options to foptions.
Reviewed by Campbell, thanks a lot!
Not sure it's totally correct solution, but seems reasonable because it's
possible dmcache is set to ISCHILD.
Someone more familiar with the particles code might want to revisit this :)
Patch from T36028 with minor edits.
Note: Renamed "Visual Sequence Editor" to "Visual Sequencer" to fit better into layout.
Also forgot to do commit --amend after fixing some merge conflicts and disabled two failing asserts, so this is a bit more than just the patch.
There was two different issues here actually:
* Own (very high) stupidity only gave 8 chars to file name (sic).
* list dir returns dirpaths without a trailing slahs, but expects them to have it it seems. :|
When using MIS, the world is treated as regular light and in this case
we can now also limit the maximum amount of bounces, the background light
will contribute to the scene.
This can improve performance in some cases, where it's e.g. sufficient to
only have a contribution on first 1-2 bounces.
Examples can be found in the differential.
Differential revision: https://developer.blender.org/D1399
The expression module now uses an EXP prefix and it follows a
distribution similar to blender.
Additionally the hash function in EXP_HashedPtr.h was simplified and the
files EXP_C-Api.h &.EXP_C-Api.cpp were deleted because were unused.
Reviewers: campbellbarton, moguri, sybren, hg1
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1221
BLI_add_slash appended to a char *, a potential buffer overflow
Also partially removed an assert, which failed after changing file format of a saved image. We need a better way to handle such cases.
Convert buffer to index in one loop,
also minor cleanup to backbuf/selection functions.
- Use IMB_rectcpy instead of inline pixel copy.
- Redundant WM_framebuffer_to_index call.
Actually this was an intentional change in rBaeeb23efa28dc to prevent Blender from trying to open the old file from the new directory. Issue is that this is really bad for saving and basically breaks "Save As".
Some more tweaks were needed to make it work like before, so now it keeps the name of the last selected file, but clears it when selecting a folder.
`BLI_space_transform_from_matrices()` defines a 'global-invariant' transform
(same point in global space, two different coordinates in local and target spaces).
New `BLI_space_transform_global_from_matrices()` is kind of opposite, it defines
a 'local-invariant' transform (two different points in global space, same coordinates in local and target spaces).
Useful to 'match' meshes.
- default alignment to lower center.
- placement is now relative,
so changing output size keeps correct placement.
- instead of center override, add align option (left/right/center).
Also don't use pixel-size for setting the font size, on new strips.
Better not have UI prefs impact low level API's.
This patch introduces a couple new stroke modifiers. The ones currently implemented are based on prototypes by @kjym3 and myself.
The new modifiers:
- Tangent
- Thickness noise
- Crease Angle
- Simplification
- Curvature 3D
The documentation for these new modifier types can be found [[ http://www.blender.org/manual/render/freestyle/parameter_editor/index.html | in the manual ]]:
{F134441}
(left: AnisotropicThicknessShader, right: NoiseThicknessShader)
{F140499}
(left: Curvature 3D, right: Simplification)
Author: Folkert de Vries (flokkievids)
Reviewers: kjym3
Subscribers: #user_interface, plasmasolutions, kjym3
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D963
This commit:
* Adds a 'compare_ff' function for absolute 'almost equal' comparison of floats.
* Makes 'compare_vxvx' functions use that new 'compare_ff' one.
* Adds a 'compare_ff_relative' function for secured ulp-based relative comparison of floats.
* Adds matching 'compare_vxvx_relative' functions.
* Adds some basic tests for compare_ff_relative.
See https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
Note that we could replace our python/mathutils' EXPP_FloatsAreEqual() by BLI's compare_ff_relative
(using a very small absolute max_diff), but these do not have exact same behavior...
Left a comment there for now, we can do it later if/when we are sure it won't break anything!
Selecting '..' entry was intentionally disabled in rB76b4fad6dbda1b10c, however, for file navigation this can be really useful. So this basically allows selecting '..' entry again, *if it is the only entry to select*. It won't be selected using box select, select all or when expanding selection.
From a user-POV this makes following changes:
* Adds support for using the Enter-key to open directories
* Updates the upper text-buttons for file and directory on selection
* Last selected file/directory is opened now (in sync with upper text-buttons)
* Changes text in open button to "Open Directory" if a directory is selected
D1349, Reviewed by @mont29
In org work, bvhtree helpers were modifying passed co/no in place according to given transform.
However, during review pass we decided this was bad, and made them modify copies. But this broke
some cases where we'd do extra tests after bvhtree query, expecting tmp_co to be in tree (aka source) space!
Further more, since in quite a few cases we were already doing that transform outside of bvhtree helpers,
decided to remove this alltogether from the helpers - makes things more clear and easy to follow,
avoids needless copy of vector, and ensures we are always using tmp_co in its transformed version!
The game.velocity_{min,max} and game.angular_velocity_{min,max} object
RNA properties did not use a subtype, and thus velocity was always
displayed as radians or blender units instead of the configured units.
Reviewed by: campbellbarton
This patch attempts to improve and review the documentation of bge.texture, as requested in the [[ http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/GameEngine#Video_Texture | TODO list ]].
More specifically, it
- fixes the rst syntax, including titles of the examples bge.texture.py and bge.texture.1.py;
- adds, standardizes and reviews description of the API elements, particularly signatures, types, etc.
- adds SOURCE_* constants to the doc
- splits the doc into thematical parts (Video, Image, Texture, and Filter Classes, Functions, Constants).
Notes:
- The parameter "mode" of ImageBuff.plot has to be described better. Actually, the whole set of IMB_BLEND_* constants (from IMB_imbuf.h) should be exposed to Python. I'll do that in a future diff, and complete the doc at the same moment (adding those IMB_BLEND_* constants to the Constants part of this doc).
- The option of using webcams in VideoFFmpeg is still particularly not well documented. I am planning to make a proposal about fixing T18634 (and its corresponding TODO in the list) by integrating OpenCV in the BGE (and Blender?). The idea would then probably be to add a new class, f.ex. ImageWebcam, making this functionnality more specialized. So for now I don't think it is worth to document that part much.
This patch fixes T44284 too.
Reviewers: moguri, kupoman, campbellbarton, panzergame, lordloki
Reviewed By: panzergame, lordloki
Subscribers: hg1
Projects: #game_engine, #game_python, #documentation
Maniphest Tasks: T44284
Differential Revision: https://developer.blender.org/D1352
The camera-aiming code was using a near-zero-length cross product, which
caused oscillations. Thresholding on the cross product length seems to
fix this.
Reviewers: lucky3, Matpi, lordloki
Reviewed By: lordloki
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1387
Have reconsidered and feel it best to try matching previous behavior
(doing "loop slides" where possible) as default. This will avoid the
need to change regression tests, among other things.
Current behavior of bevel is to 'loop slide' along unbeveled edges
when possible, but this produces uneven bevel widths sometimes,
so this option lets user choose between having the loop slide effect
or having more even bevel widths. Trying it out with default being
'no loop slide', so different from current behavior. May reverse this
choice later, depending on user reactions.
This patch add a new option for transparency meshes : Alpha to coverage, in the game setting panel in material.
The alpha to coverage request a multisample, the best is 8x but 4x and 2x can also give nice render.
4x alpha clip : http://www.pasteall.org/pic/show.php?id=89464
4x alpha to coverage : http://www.pasteall.org/pic/show.php?id=89463
Reviewers: moguri, kupoman, campbellbarton, psy-fi
Reviewed By: psy-fi
Subscribers: lordloki, rdb
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1354
PNG_COLOR_TYPE_GRAY colortype can have some values for alpha, in the same way as
PNG_COLOR_TYPE_PALETTE colortype.
In this case, we need two channels (grayscale and alpha), not one.
Actually it is only possible to pass float properties to a 2D filter (GLSL fragment shader).
This patch allows also to use integer properties for the 2D filter.
Reviewers: sybren, agoose77, kupoman, moguri, lordloki, panzergame
Reviewed By: lordloki, panzergame
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1370
We already had that for global keymaps (used e.g. to generate shortcuts for menu entries),
but this wasn’t possible for modal keymaps yet (e.g. help message in header during
transforms and other modal operation).
This commit only adds needing background code, it does not change anything from user PoV.
Modal operators will be updated to use it in comming weeks.
Thanks to Campbell for revisions & suggestions. :)
Differential Revision: https://developer.blender.org/D780
This commit adds a new operator that will compile the list of text
strips into an srt file. No positioning is supported yet but will
be added later.
The operator can be found in the effect panel in the strip properties.
Add support for material diffuse, specular… in KX_BlenderMaterial python proxy. And use mathutils in KX_BlenderMaterial for the specular and diffuse color in KX_BlenderMaterial.
Reviewers: sybren, brita_, kupoman, agoose77, dfelinto, moguri, campbellbarton, hg1
Reviewed By: moguri, campbellbarton, hg1
Subscribers: dfelinto
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1298
option.
This makes sense, since contexts get created at runtime, there is little
reason to require recompilation for this.
Only works on linux currently, will be doing more OSs later
Is pretty much what it says :)
Easy subtitles for everyone!
Supports size, positioning,
a cheap shadow effect (probably will need more work),
and autocentering on x axis.
Now you can go wild with long spanish names
in your soap opera videos.
Will probably be refined as days go by,
but at least it's now ready for testing.
The cleanup function was a bit too much aggressive here, made it much more
conservative. It means memory usage will not be so low anymore, and to
address this we'll need to make this function depsgraph aware.
- place return args last position
- move crazyspace function out of DerivedMesh header
- use bool for args
- flow control on own lines to ease debugging
Excuse the trashing here, but seems users prefer this most (though both can be useful).
Note that the UI remains the same,
so this is an option for 'Incremental' snapping instead of a new snapping mode.
Make sure SEQ_TYPE_EFFECT is only used as a flag, not as number
comparison.
This should allow us to add new non-effect types in between
effect types (every 8 indices).
Dirty, but alternative of separating type/subtype means we lose
forward compatibility.
This is not really supported by OpenCL but might happen in certain
configurations. There might be some remained cases when this happens
but so far can not find any,
This is a regression since dced56f and root of the issue comes to the fact
that grid distribution sets UNEXIST flag during distribution, which is then
being reset in initialize_all_particles().
This commit solves the issue, but it's not really nice and some smart guy
might want to revisit it.
It's quite tricky to see if the driver actually depends on time or not,
so currently used approach when we'll be doing some extra updates.
This seems to correspond to how old depsgraph was dealing with this.
Performance tests now have their own CMake macro, which ensures they do not get
added to ctest list, so we do not have to bother about them anymore, and can always
build them (when GTests are enabled, of course).
This is essential for video projection, and the alternative until now was to manually change the projection matrix via Python.
( http://www.blender.org/manual/game_engine/camera/introduction.html#camera-lens-shift
- this page will be removed as soon as I commit this)
Also this is working for perspective and orto cameras BUT if the sensor is not AUTO it will only look correct in blenderplayer (this is an unrelated bug, but just in case someone runs into it while testing this, now you know why you got the issue).
Kudos for the BlenderVR project for supporting this feature development.
Differential Revision: https://developer.blender.org/D1379
Parallel rendering was not working.
The idea of having parallel convergence mode to render as parallel but
visualize as off-axis was good, but it was leading to some complications
in the code.
I think it's more clear to the user if parallel looks and render as
parallel, and if she wants to pre-visualize the converged planes, simply
temporarily set the camera to off-axis.
The issue was caused by some changes made to msgfmt which were needed to make
modified (cleaned-up, stripped-comments messages) working.
Unfortunately that fix was merged into the release branch, so this fix is to
be ported there as well and verified against rc1 translations.
'ar->winy' may not be initialized, making regions zoom in (past limits)
and attempt to draw very large text (~10x10k size characters), often crashing.
Fix isn't complete since it only corrects factory startup.
Previous idea behind having vector during building and array for actual storage
was needed in order to minimize amount of re-allocations happening during the
build, but it lead to double memory overhead used by those arrays at the vector
to array conversion stage.
Issue with such approach was that for BVH without spatial split size of arrays
is known in advance and it never changes, which made vector to array conversion
totally redundant.
Also after testing with several rather complex from spatial split scenes (such
as trees) it seems even conservative approach of reallocation (when we perform
re-allocation when leaf does not fit into the memory) doesn't give measurable
difference in time.
This makes it so we can switch to array, which will avoid unneeded memory
re-allocations when spatial split is disabled without harming other cases.
it's a bit difficult to measure exact benefit of this change on our production
files here, but depending on the scene it might give quite reasonable memory
save.
Angular velocity clamping was missing from the BGE. It is implemented
similarly to the linear velocity clamping. It is needed to be able to
drive physical simulations of systems that have a limited rotational
speed.
Reviewed by: campbellbarton, panzergame, ton
Differential Revision: https://developer.blender.org/D1365
Simply backport small part of work from asset-experiments here (using double and
adding tera-bytes unit), looks like off_t is not always 64bits even on a 64bit OS...
This way we solve possible issues caused by regular allocator not being aware of
some classes preferring 16 bytes alignment needed for SSE to work properly. This
caused random crashes during rendering.
Now we always use aligned allocation in GuardedAllocator which shouldn't be any
measurable performance impact and the code is only used by developers after
defining special symbol, so there is no impact on release builds at all.
it is the same issue as described in the previous commit, original changes
in this area were wrong and only worked on a bugger optimus driver which
simply appeared to work by co-incident and in fact used wrong device..
It was annoying copy-paste happened across OpenCL device constructor, device
enumeration and split kernel checks. Now those areas are using an utility
function which returns pairs of platform and device IDs for devices which are
supported by Cycles and enumeration is happening inside that list.
This makes it so filtering is happening in a single place, so there's no need
to keep 3 different functions in sync.
This commit also fixes a bug with wrong enumeration of devices caused by recent
fixes. Those fixes were in fact wrong and only happened to appear to be working
on laptop with optimus card on Linux. Root of those issues is in fact in bad
Linux driver for optimus cards.
With multiview/multilayer OpenEXR file, `load_image_single()` will return NULL ibuf,
since it has already populated ima (with `image_create_multiview()` or
`image_create_multilayer()` calls).
Also, added some more checks before doing `IMB_ImBufFromStereo3d()`, to be sure
we do have enough slots in ibuf_arr, and we do not overwrite second ibuf either.
Issue is data race between preview job and GPU nodetree evaluation when
localizing the nodetree. Data race happens due to localizations doing
overrides on original nodes' new_node variable.
Solution here could probably be to use a hash for mapping of old to new
nodes but will prefer simple brute force lock for now.
This reverts commit 0e02ad8b64.
Initial commit was done so visual result fits with animation cursor
in timeline but this makes it so it looks like one extra frame is
rendered. Other idea would be to render one less frame for sequencer
but this is not so nice either. Generally here's no way to be
fully consistent here, but at least let's be workflow-consistent
Code here calculated speed based on underlying strip start position,
which was not really visible, making prediction of the result really
difficult. Things here are simple: As long as the strip exists,
manipulate the current frame by the provided factor.
Now we use color converted (if we do a color management) by the setter for background color in VideoTexture (ImageRender & ImageMirror).
Reviewers:panzergame
This was a mistake in the original code from D1079.
With the current way how direction ot mirror ball works camera should look
into negative Y direction. Corrected it in the camera matrix synchronization,
so no extra calculations are needed at the render time.
That's a bit annoying, but we'd better port it to the release branch, or
otherwise we'll end up with files created with wrong camera mapping after
2.75 release.
The idea is to make it possible to control linked duplicated objects motion
blur from the scene file without need to do overrides on the linked object
settings. Currently only supported for dupligroup duplication and all now
if duplicator object has motion blur disabled then it'll be inherited into
all the duplicated objects.
There should be no regressions/changes in look of existing files because
objects do have motion blur enabled by default.
Number of system threads is quite difficult to change without need of blender
restart, so we can cache result of the systcalls (which are not really cheap)
in order to be able to call BLI_system_thread_count() without worrying of
performance issues in that function.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1342
This gives quite the same problems as experimental CUDA kernels
and for until it's found a root cause of the problem we'd just
explicitly uninline the function.
Fix T38030.
In c++ source we use one list for triangles and an other for quads, but KX_PolyProxy doesn't care about that and return the vertex offset in its list. So we just have to compute the offset of each RAS_DisplayArray to its previous to have an absolute vertex index.
Reviewers: moguri, campbellbarton, kupoman, agoose77, brita_, hg1
Reviewed By: agoose77, hg1
Projects: #game_engine
Maniphest Tasks: T38030
Differential Revision: https://developer.blender.org/D1324
Basically, at this line body is always NULL and the code is never
executed
Reviewers: moguri, hg1, panzergame, agoose77
Reviewed By: hg1, panzergame, agoose77
Subscribers: blueprintrandom
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1331
This patch exposes smoke simulation velocities in the Python API,
similar to how density and flame grids are exposed.
This is useful to export velocities to an external renderer using Python.
Reviewers: campbellbarton, sergey
Reviewed By: sergey
Subscribers: sergey
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1366
Quite straightforward implementation -- all the conversion magic is
happening in IMB_exr_write_channels() and remained changes are only
needed to pass information whether channels is to be converted to
half float or not.
Regular file output will use full-float for Z pass, which matches
behavior of the single layer EXR files. But when saving happens
with File Output node then all the passes are respecting half float
settings because it's not possible to distinguish whether we're
saving Z pass or not.
Reviewers: juicyfruit, campbellbarton
Reviewed By: campbellbarton
Subscribers: maxon, effstops, fsiddi
Differential Revision: https://developer.blender.org/D1353
This is mainly useful for the render farms output when logging might stop at
the "Path Tracing Tile N/N" string, which makes it a bit difficult to follow
what exactly is happening (node going crazy, hardware issues or just last tile
is too much heavy).
This is more like an experiment, might be changed in the future.
They'll be checked for the version later and that check will fail anyway,
so better to not allow user to see unsupported device in the list.
Also corrected one more issue with the device enumeration.
This patch suppresses the outdated KX_PolygonMaterial.rst documentation file and moves the example contained in it into KX_BlenderMaterial.rst.
The file KX_BlenderMaterial.rst receives some extra formatting changes (lists are not supported in methods arguments types).
Reviewers: kupoman, campbellbarton, lordloki, panzergame, moguri
Reviewed By: panzergame, moguri
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1355
This reverts commit ab417f31f4.
This workaround caused serious memory corruption issues which is not really acceptable
for the release. We'll be likely sticking to a more limited release when using freestyle
with saved buffers for until proper solution is implemented.
Conflicts:
source/blender/render/intern/source/pipeline.c
The issue was caused by render pipeline freeing render parts prior to finishing
exr file writing which resulted in unfinished parts not being written into the
file by save_empty_result_tiles().
As a temporary solution we do explicitly write unfinished parts as empty tiles
to the exr file prior to freeing parts.
Not ideal solution, but should work for the release.
(it would behave like 'bone envelope resize' instead).
Issue comes from the fact this transform op shares some common points with both BoneResize
and BoneEnvelope operations. However, trying to re-use `TFM_BONE_ENVELOPE` itself in this case
is bad idea, since this mode gets stored in transform op and is directly re-used for redo,
by-passing the whole init phase that shall be done in `TFM_BONESIZE` mode... So now,
we add a real new mode, `TFM_BONE_ENVELOPE_DIST`, while keeping most of existing code
and all existing behavior.
This is slightly hackish - but was already anyway, and avoids creating a full new set of
function for pretty much the same thing. As a side note, also makes it possible to
resize envelope distance outside of envelope viewing mode (from py or by adding a custom
shortcut).
Skipped devices did not reflect in the device number, which might result in bad
array indices.
This might also resolve T45037, and need to be ported to a release branch.
We really don't need to iterate all edges of the mesh every frame to
search for loose edges, this calculation can be cached when filling the
edge index buffer.
This behaviour was confusing, since "selected keyframes" suggests that it covers
all selected keyframes (instead of trying to do this based on frame ranges).
Now internally the variables are processed as floats avoiding int->float->char conversions that are causing precision lost.
A check for int numbers is maintained to keep compatibility with old behaviour.
Reviewers: ben2610, campbellbarton, moguri, hg1
Reviewed By: moguri, hg1
Subscribers: campbellbarton
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1301
The main loop only handles transparent intersections from the camera ray.
Therefore we can simplify some things.
* Avoid PATH_RAY_CAMERA check, this is always true.
* Avoid path_state_next() call, we can just set transparent flag and increase transparent bounces. This way we avoid the function call and some branching.
Also remove debug num_ray_bounces++, this is incorrect here as no indirect bounce happens here.
Should be no functional changes.
Code there started becoming a bit too big, by splitting it up it'll make it
easier to do improvements or extending the features in there.
The layout is not totally final yet, would need to try de-duplicating parts
of code from split kernel with non-split integrators,
This patch adds the submodule app to bge. apps contains constants similar to bpy.app, particularly version (tuple of three ints like 2.75.1).
It was requested in T43918 and set as TODO.
The patch also adds rst doc for the module.
Reviewers: moguri, kupoman, lordloki, panzergame, campbellbarton
Reviewed By: lordloki, panzergame, campbellbarton
Subscribers: marcino15
Projects: #game_logic, #game_python, #game_engine
Differential Revision: https://developer.blender.org/D1348
This is needed for the new granular depsgraph, otherwise graph is not
containing all the operations needed for proper update.
And the same is actually needed onwhen removing shape key.
This commit fixes missing updates of masks with the new dependency graph
in a way which is safe for backport into master branch.
Compositor nodes will not receive needed update callback yet, this will
be solved after mask and compositor are becoming a proper node in the
graph, it is considered a TODO now.
This reverts commit 7b0c327b94.
The problem with this commit is that the "move to layer" functionality by hitting M,1 f.e. didn't work anymore...
Campbell, would be great if you could look into this again, as I'm not experienced in this specific region..
The issue was caused by using NotificationCenter which is only available
since 10.9 so trying to build blender on OSX with 10.7 SDK would fail.
Now it should be possible to build blender with SDK 10.7 and at the same
time official builds should still be doing proper weak-linking to a
notification center.
Would run register() twice causing warning with `register_module()`
which expects new classes to be defined.
Now run unregister() before re-registering.
Older OSX has major issues with sincos() function, it's likely a big in OSL
or LLVM. For until we've updated to new versions of this libraries we'll use
a workaround to prevent possible crashes on all the platforms.
Shouldn't be that bad because it's mainly used for anisotropic shader where
angle is usually constant.
This fix is safe for inclusion into final Blender 2.75 release.
Avoid data type re-declaration, it's not really working on current FreeBSD's 9
system and CLang-3.0 from OSX.
This is not a good idea to do such sort of copy-paste anyway.
If someone knows better way of dealing with this please go ahead and correct
the code :)
they are supported
aka, remove multiview properties from the texture panel, the textures
node (image), and any other parts.
The multiview options are now to be explicitly set in the image template
in order to have them available in the respective panel
The functionality was there, but the UI was missing, since I introduced
the use_mutliview option in the Image datablocks.
Note: when opening the image via the background image UI it has its
views data mangled. I'll look at that. Meanwhile the fix is to toggle
Use Multi-View manually in the UI.
Glass BSDF was doing some magic with copying weigths from initial closure
onto refraction one and the code was not checking properly for the number
of closures.
some 3d methods change the window arrangment, thus they shouldn't
toggle on/off just because there is no 3d elements being drawn
The optimized solution would be to draw only the left eye in those
cases, but there is some issue going on with that, so this commit will
do for now.
bpy.path.clean_name() and AddPresetBase.as_filename() were doing
inefficient search-replace of individual characters.
Use cached replacement table instead.
Not sure where this sneaked in, but we for sure need a valid context (otherwise
we'd need to pass a Main alog too).
This is to be backported to final 2.75.
For areas that require append, store the last node,
Previous behavior would too easily hide poorly performing code.
Also avoid (prepend, reverse) where possible.
* Unset active file on opening/resetting file list
* Accidentally placed NULL check in the middle of the function - not a
big deal as it's highly unlikely that it fails (removed it but added
assert)
TODO: We might want to refactor debug passes into PASS_DEBUG and some
debug_type (similar to Blender's side passes) to avoid issue of running
out of bits.
They're working just fine on AMD Tonga GPU and probably other architectures,
lets enable it under the experimental feature set and see what exact system
configuration gives issues.
The issue was caused because of the following circumstances:
- Making All Local will just iterate all IDs and clear linked flags
- It will not do anything with objects which are already local (and
since proxy rig is local nothing will be changing it).
This commit makes it so id_clear_lib_data() takes care of clearing
all related proxy pointers, avoiding situations when proxy rig will
point to a local armature.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1276
This commits makes scopes evaluation multithreaded by using OpenMP
for the outer loop of pixel processor. it also makes all the changes
needed for keeping performance as high as possible by keeping data
local to thread for as long as it's possible.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1334
Previously it was using accumulative counter of saved lines and so on in order
to detect cases when new sample is to be saved. This is not quite possible to
do with threaded scopes update.
Change it now with non-accumulative approach which saves a bit different lines
due to slightly different rounding, but this things are not strictly defined
anyway and results are close enough to each other.
Adds support for selecting/deselecting files in File Browser using the
arrow keys. All directions (up, down, left, right) are possible.
When to Select, When to Deselect?
Standard behaviour is selecting, however if we move into a block of
already selected files (meaning 2+ files are selected) we start
deselecting
Possible Selection Methods
Simple selection (arrow-key): All other files are deselected
Expand selection (Shift+arrow key): Add to/remove from existing
selection
ill-Expand selection (Ctrl+Shift+arrow key): Add to/remove from existing
selection and fill everything in-between
From which file do we start navigating?
From each available selection method (Mouse-, Walk-, All-, Border
Select), we use the last selected file. If there's no selection at all
we use the first (down/right arrow) or last (up/left arrow) file.
(Ideally, the view would automatically be set to the new selection, but
this behaviour overlaps with an other patch I've been working on, so
prefer to do that separately)
(Also tweaks color for highlighted file for better feedback)
D1297, Review done by @campbellbarton, thx a lot :)
This simplification is safe, as the call to volume_phase_eval() is guarded behind a CLOSURE_IS_PHASE check, which is equal to
CLOSURE_VOLUME_HENYEY_GREENSTEIN_ID. I don't think we will add more phase functions anytime soon, if at all.
This way it is now possible to select which exact debug pass is to be used
by the render engine. Accessible from the Passes panel.
Currently it could only be one debug pass, in the future we can make menus
and image users smarter and support multiple passes of the same type.
Quite straightforward implementation, but still needs some work for the split
kernel. Includes both regular and split kernel implementation for that.
The pass is not exposed to the interface yet because it's currently not really
easy to have same pass listed in the menu multiple times.
The issue was caused by memory optimization marking particle system to recalc,
and because of the way how particle flags works it was possible that it'll
cause particle's re-distribution. Now this memory optimization will act the
same as loading the file.
This commit appears to be safe according to our render farm and is safe to
be included into final release.
For now we solve this for non-multiview renders by merging exr file back into
full render result prior to rendering freestyle strokes. Multiview case is
still to be supported tho.
For now we work this around by copying python DLL to the
bin folder. Ideally the DLL should be shared between blender
and python, but that's a bit tricky to do on windows.
Was doing clamping as fix for T42984. Seems we can ommit clamping for
sculpting if we make sure overlap is not zero with negative values.
Control for clamping is moved to the "Use Clipping" function of curves
(which is on by default), so both bugs remain squashed and advanced
users can now properly utilize curves in sculpting, though not all
brushes work well with negative curves.
Adds an "Interface Style" menu containing the items "Flat" (default) and
"Classic". The classic option basically brings back widget outlines,
emboss, shading and old checkbox design.
Open design question:
Currently widget outlines, emboss and shading is hardcoded disabled for
the "Flat" option. Meaning that tweaks to their theme options don't have
any effect. I think it should be fine to just disable the theme buttons
for this, but I'm all ears for better approaches.
Requested by @campbellbarton and @ton
* Do not translate renderlayers' names, those are data, not UI (defined by user).
* Translate passes' names, even in button itself (menu items were already translated).
* Translate 'ID type' in ID eyedropper helper message.
Also, added i18n context to IDType private struct, and `BKE_idcode_to_translation_context()`
helper, much more generic and easy to maintain than the private util in interface_template.c.
ED_screen_duplicate() was never written to support non-fullscreen modes.
This is prior to the hidden ui fullscreen commit, and it's quite ancient
in Blender's code (since Jan/08 - 1363134d)
That's why duplicate window, and new screen operators are disabled when
screen is full.
As pretty much agreed on in T38070, this implements widget-rollover for
better visual feedback.
The added Sub-Button pipeline should provide us a solid base for future
ideas like using Sub-Buttons to trigger operators (thinking of 'X'-icons
within tabs or menus e.g.), open popups/menus, provide better cursor
feedback, etc. They are basically independent buttons within buttons.
https://developer.blender.org/F187781
Steps to reproduce were: Toggle fullscreen->F12->F3->ESC 2x->3D View
changed to Image Editor and didn't change back.
Actually it doesn't work 100% as wanted since it exits the fullscreen
when pressing ESC to exit Image Editor but it's hard to support all
cases with such a weird spaghetti code.
Revert "Nodes: Remove hardcoded BLENDER_MAX_THREADS number of threads"
This reverts commit fdc653e8ce.
The threads override is not affected by the scene, and hence the limit of the
threads was not giving correct result. Need to re-consider some things here.
The addons tab in the User Settings window would be empty, due to
a FileNotFound error. This error can be caused by a broken symlink,
which is now treated the same was as a file that misses its bl_info
dictionary.
Issue was caused by passing NULL bmain to the path remap function when
localizing the node tree.
Paths are to be remapped, otherwise mapping of paths to OSL scripts
might happen in a wrong way.
Round-up was only enabled for viewport render, which was for a long time hardcoded to
use 64 closures. This was done in order to avoid unnecessary kernel re-compilations
when tweaking the shader tree.
We could enable selective closure compilation in the viewport later if it'll give
measurable speed improvements, but even then round-up is to happen outside of the
device level,
This commit also removes early output which happened in cases when max closure did
not change. It was wrong because other requested kernel features might have been
changed.
This features are now based on the scene settings, so scenes without those features
used are rendered even faster.
This gives about 30% speedup on the AMD A10 APU here, but at the same time it does
not mean such an improvement will happen on all the hardware. That being said, the
Tonga device here seems to have no measurable difference.
In any case it seems handy to have for the future, when we'll want to support SSS
in the kernel or to port selective compilation/split kernel to CUDA devices.
The view would jump each time, now compensate by adjusting the cursor panning.
Less jarring and helps avoid problems when the cursor gets outside the view, see: T40353
Based on this mockup by @venomgfx: http://wiki.blender.org/index.php/
User:Venomgfx/User_Interface#Menu_Item_.26_Menu_Back
Main changes:
* Draw background for menu title in a different color (currently
hardcoded darker) instead of using a separation line
* Align submenu triangle icons vertically and add some extra space for
them so that they are not squashed in to the line (means shortcut text
is now always vertically aligned as well)
* More modern submenu triangle icon drawing
* Draw separation lines a bit more visible
* Don't add extra icon padding if the menu doesn't contain any icons
(text in menus often used to have some padding on the left so that the
text is nicely aligned even when some entries had icons in front of it.
This is all fine but wasn't needed/looked weird if there isn't any menu
entry with an icon at all - e.g. 3D View "Select" menu, most of the RMB-
menus)
* Cleanup
Screenshots:
* https://developer.blender.org/F185706
* https://developer.blender.org/F185707
* https://developer.blender.org/F185708
Made the test for whether one can "see" an adjacent edge less
knife-close to 180. This means it will chose to slide along
such an edge less often, and avoid some spikes.
As material is not NULL at this stage there is no need to do a NULL
check. Also to remove dead code
Reviewers: dfelinto, panzergame, hg1, moguri
Reviewed By: panzergame, hg1, moguri
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1330
Add slider to adjust the influence of weights relative to geometry distortion.
This allows subtle influences to be applied - without drastic changes in behavior.
Reported by pixaal on irc, basically reproducable by inserting bevel
modifier on cube and entering/exiting texture paint mode.
Now object stores last needsMapping variable as well as customdata mask.
Also now texture painting only needs mapping when we are in texture
paint selection mode, so modifiers that don't support mapping can still
be used to paint now.
Already committed similar fix (rBbeaed66f292dd) but saw it appearing on
other peoples screens a few times since them. Never was able to recreate
though.
This should make sure everything is initialized fine, so if we see it
appearing again, then it's likely because of manual tweaks or the
version saved in the .blend.
Mainly removed unnecessarily drawn edges and doubled line thickness for
area edges to clearly separate areas from regions.
For now I've added a theme option to control the color of the area
edges, we can check later if it's worth keeping it, but IMHO it's quite
important to have this controllable.
As proposed in T38037 this removes the outlines from widgets (except of
toggle buttons like layers and color buttons for now) to simplify/
flatten the look of the UI.
This needs some more polish and we could even remove the outline drawing
code completely instead of just disabling it, but I first want to get
overall design approval.
Also, changed the algorithm for generating the vertex meshes when not all
edges into a vertex are beveled. Now it tries to slide along edges that
form part of the silhouette when possible; when not possible, it tries
to snap to the best plane in between the beveled edges.
Also improved a bit behavior of adding new nodes, now they will not overlap that
badly. Still not ideal, but further improvements better not to happen at bcon4.
- label is shown on a UI_UNIT_Y heigh instead of 0.2 * total button size
- vertically centering non-ID previews labels
- making some constants dependent on ui units
- elongate the buttons to acomodate the icon without the label overlapping.
- removing the blue background
- adding a consistent margin all around the popup
The issue was caused by the reshuffle needed to make objects flags have proper
object's bounding box to solve regressions in SSS objects intersecting volumes.
There's actually a feedback loop happening here, which is now solved in quite
naive way -- for the true displacement we consider all objects are capable of
intersecting volumes, synchronize object flags prior to displacement shader
tasks runs and then re-update object flags for proper bounding box.
Not sure what will be the proper solution here, we can't do preliminary check
of intersection for displacement shader, but on the other hand we don't really
need this flag for displacement shader anyway.
We have to regenerate previews when we change language. But we also need to do it
when translation is changed or added for a language, etc.
Previously, we were storing one preview per language, which was also stuffing
preview dir with (potentially) tens of PNGs per font file, if user plays with translations.
Now we use a better system, which is storing an additional optional metadata in previews
(some hexdigest), that Blender can use in addition to datetime to decide when to regenerate
previews.
This is only used (and needed) by font previews so far, but can easily be reused for other
types of previews if needed.
This avoids some ugly 'missing char' in previews - not all cases of course, but most common ones.
A complete solution would be much much more involved, and probably not worth it here.
Definitively not before a release, at least!
We had some reports where users did not even read the "Not supported on
release builds" message, and arguably writing a file sort of indicates
that the file may include something useful.
This will help figuring out cases when node was not properly handled by the SVM
by aborting execution on CPU, where all the nodes are expected to be supported.
This commits finishes initial selective nodes compilation into kernel, which
helps a lot performance-wise for AMD OpenCL kernels.
Split by node groups is based on statistics from simple scenes like BMW and
more complex scenes like mango and gooseberry production files. Further
tweaks are always possible, but it should be a good starting point.
TODO: Still need to ignore unused nodes when calculating requested shader
features.
For now it's reported to the stdout, matching to the CUDA behavior.
In the future we can hide this into GLog logging once the kernels
are considered all stable and so.
We cannot `direct_link_packedfile()` twice on a same address, because this tries to
map again pf->data address, which leads to nothing (NULL).
So now, since `ima->packedfile` and `ima->packedfiles` are mutually exclusive
in 'live' blender data anyway, we either read one or the other.
Tested from/to official 2.74 and current master, everything looks fine now.
rBe5fbeba0b3a6e9eea not only restored forward compat, it also broke backward compat...
for no reason at all even, exising ima->packedfile is only used by read/versionning
code if .blend version is below 274.4 (i.e. no multi-image packing exists).
This patch adds some new functionality to the Freestyle Python API, notably:
- MaterialBP1D, checks whether the supplied arguments have the same material
- Fixes a potential crash in CurvePoint.fedge (due to NULL pointer)
- Makes (error handling in) boolean predicates more robust
- Adds a BoundingBox type, to make working with bounding boxes easier
- Adds several new functions (get_object_name, get_strokes, is_poly_clockwise, material_from_fedge)
- Adds a StrokeCollector StrokeShader, that collects all the strokes from a specific call to Operators.create()
- Adds hashing and rich comparison to the FrsMaterial type
These new features (most of them, anyway) are needed for making a more robust SVG exporter that supports holes in fills.
Reviewers: kjym3, campbellbarton
Subscribers: campbellbarton
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1245
when mipmap is off.
We used to always have nearest interpolation for texpaint but at least
make this work with mipmap off correctly.
Also added conversion casts to avoid integer overflow in filtering code
Like Camera Motion, only available in the Experimental kernel.
This should be it for the upcoming release, we now support almost everything, apart from Transparent Shadows, SSS and Volume.
T44869.
There are a couple of issues here:
* Code repeatedly calculated center of ready rendered parts even though
they would not change while the operation was done.
* Code would calculate distance of tiles from center multiple times
* Code would traverse all items, even the ones already sorted
* Traversal used linked lists which is quite slow.
Mitigated these by doing one pass for the center, a second to calculate
distances and a qsort at the end.
Should result in O (n * (log n + 2)) instead of O (n * (n * 2))
complexity, plus the number of repeated operations is much less as well.
Same as last commit, code is unused and this one actually would have required some fixes,
as these variants output values outside the 0-1 value range, which doesn't fit Cycles shader design.
Let's finally delete this code, after 4 years of being unused,
there really is no excuse anymore.
If we decide to extend the procedural textures in SVM, we can do this anytime in the future.
multires.
Code had special guards for such edges to stop this from happening. I
don't see why this is needed though since code above assigns smoothed
positions for all vertices in the grid.
After removing the guards I saw that this in fact was the only place
where grd adjacency was used, so I completely removed it.
We must take kerning into account everywhere! Note this will disappear in upcomming filebrowser
refactor anyway.
Reported through IRC by Pablo (venomgfx), thanks.
This adds description of the Font object and about its (only one)
attribute, as well as an example of use.
Reviewers: campbellbarton, fsiddi, dfelinto, moguri
Reviewed By: dfelinto
Subscribers: lordloki
Projects: #documentation, #game_engine
Differential Revision: https://developer.blender.org/D863
As used already for mesh & curves.
Add confirmation menu for curve & armature,
since this isn't such a common operation and undoing leaves object data
(long term bug/todo to fix).
This commit re-shuffles code in split kernel once again and makes it so common
parts which is in the headers is only responsible to making all the work needed
for specified ray index. Getting ray index, checking for it's validity and
enqueuing tasks are now happening in the device specified part of the kernel.
This actually makes sense because enqueuing is indeed device-specified and i.e.
with CUDA we'll want to enqueue kernels from kernel and avoid CPU roundtrip.
TODO:
- Kernel comments are still placed in the common header files, but since queue
related stuff is not passed to those functions those comments might need to
be split as well.
Just currently read them considering that they're also covering the way how
all devices are invoking the common code path.
- Arguments might need to be wrapped into KernelGlobals, so we don't ened to
pass all them around as function arguments.
It was possible race condition on empty curves -- it's possible that curve
object is fully updated and path is null in that cases, Proper way to deal
with this is to check curve_cache for non-NULL.
It was kept disabled due to render artifacts which weer in fact caused by bad
memory access, which is fixed in the previous commit.
We now also can make it enabled in regular AMD split kernel after someone tests
the updated code.
This is needed when you want to bake only part of an armature's bones, since they
all share a single action, otherwise you'd lose non-baked bones' animation...
This will print a warning and users will get overlap of pie buttons, but
it should be quick paper over the cracks and at least should keep
blender working until a more complete fix is coded.
Tweak event was being added to the end of the event queue (out of order),
meaning any mouse releases already in the queue wouldn't be used to exit the gesture.
Gestures could get stuck (mostly when the system wasn't able to handle events fast enough).
Now tweak events are now added in order.
This will fix exporting of metadata and importing for imbufs, but image
editor will not display these metadata since multilayer gets converted
to renderresult, which does not support metadata display yet.
This commit is more meant for external image editors/viewers.
Use first packed image as legacy image->packedfile, so saving .blend file with
latest builds makes it so packed images are not lost when opening with previous
releases.
This will only work reliably if mutliview is not used, otherwise it'll be only
first view in the .blend file, which is rather expected since previous releases
are not aware of views.
Enum's itemf callback can be called without context in some cases (UI, doc generation...).
Python's enum properties did not handle this at all - it's kind of odd this did not cause
more trouble and wasn't notice earlier... Probably dynamic enums using context are not
much used in py code.
Note about nodes: those are heavy users of dynamic enum with context. Now,
we expect `NodeCategory.poll()` and `NodeItem.poll()` to always be called with
a valid context (since when there is no context available, we can assume `poll()`
is always True). `NodeCategory.items()`, however, must accept NULL context, so if
you use custom `items` callable for your custom node categories, you may need
to update it (as was done here for builtin `node_group_items()`).
The code was failing to compile on runtime because of some path differences,
and it seems we don't need to specify full path to the file which originally
seemed to be needed to make include directives expansion working correct.
This was broken after the kernel file restructure.
Variables allocated in the __local address space can only be defined
inside a __kernel function.
We probably need to solve this a bit differently once we do the CUDA
kernel split, but this fix shoud be good enough until then.
Blenderplayer forgot to initialize the default material (defmaterail) with function init_def_material().
This reverts also the plumber commit 2fa4a48bce.
Reviewers: campbellbarton
Since the kernel split work we're now having quite a few of new files, majority
of which are related on the kernel entry points. Keeping those files in the
root kernel folder will eventually make it really hard to follow which files are
actual implementation of Cycles kernel.
Those files are now moved to kernel/kernels/<device_type>. This way adding extra
entry points will be less noisy. It is also nice to have all device-specific
files grouped together.
Another change is in the way how split kernel invokes logic. Previously all the
logic was implemented directly in the .cl files, which makes it a bit tricky to
re-use the logic across other devices. Since we'll likely be looking into doing
same split work for CUDA devices eventually it makes sense to move logic from
.cl files to header files. Those files are stored in kernel/split. This does not
mean the header files will not give error messages when tried to be included
from other devices and their arguments will likely be changed, but having such
separation is a good start anyway.
There should be no functional changes.
Reviewers: juicyfruit, dingto
Differential Revision: https://developer.blender.org/D1314
Angle limit for join-faces was more advice then actual limit.
Now joining entire selection, gives assurance that no faces above the limit will be merged.
The purpose of this was to allow users to isolate 2 faces and always join them.
Instead, support this by bypassing limit only when its not set and 2 faces are selected.
Problem was float precision issues across tile boundaries. Since we are
comparing pixels, give a small tolerance when comparing clipped vertices
against triangle lines.
SCons was checking for a particular compiler version to see whether compiler
flags are available or not, but compiler ID was only set on OSX.
Now it should be set on Linux as well.
Previously, it would only save the eraser size if the session ended properly,
instead of being cancelled. However, that wouldn't happen if exiting the session
using Esc.
We have too much of those cases in our UI, if we want to keep operators doing
several similar/related but yet different tasks, we should have a real way to
support it on label/icon/tip side too. Easier to say than to do though. :|
Note: maybe we could even make `RNA_property_is_unlink()` always return false
for enum properties? But well, guess being explicit here does not hurt...
They were lost during simplification of kernel loading but might be rather
crucial for the performance.
Also made it so cflags are shared across kernels. Surely it might lead to
some unwanted kernel re-compilation but at the same time they might easily
run out of sync with the changes in kernel and so.
Previously decimate on flat areas of a mesh would more or less randomly collapse edges.
(giving bad topology).
This commit includes a topology 'cost', so smaller edges on flat surfaces collapse first.
This way it is possible to have single threaded depsgraph but threaded other areas
which is handy for torubleshooting.
he argument is: --debug-depsgraph-no-threads
We're currently only supporting save to a default format color space, which
makes it a bit tricky to prevent ImBuf from being changed.
For until when saving to a custom colorspace works we'll just reload image
if the space changes.
Previously we don't merge material cached list, it create dangling pointer and memory leak.
Now we merge material cache list during the scene merge, and remove material in this list during the library free.
Reviewers: agoose77, dfelinto, hg1, pgi, campbellbarton, moguri
Reviewed By: campbellbarton, moguri
Subscribers: campbellbarton, youle, kupoman
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1278
color in GLSL
Issue here is that intermediate result was clipped as an optimization in
such nodes and thus not converted to the correct type properly. Now only
clip those values if types match.
This keeps both the optimization and the conversion. I looked at
converting uniform types always but it's more involved to compare types
at conversion time for such links because the type was getting
overridden during link duplication.
In certain configurations (for example when start resolution is set to small
value for background render and progressive refine enabled) number of tiles
might change in the tile manager. This situation will confuse progressive
refine feature and likely cause crash.
We might also add some settings verification in the session constructor, but
having an assert with brief explanation about what's wrong should already be
much better than nothing.
It was possible that two threads will start calculating proxy group's inverted
matrix and store it in the object itself. This isn't good idea because it means
some threads might be using partially written matrix.
Previously it was very easy to run into situation when two objects are sharing
the same materials with drivers which will cause threading access issues.
This actually only needed for the old depsgraph, but since it's still the one
we're using by default we'd better solve this issue.
There were some reported data race conditions in the python interpreter which
seems to be rather valid.
Surely this is not very pretty solution, but it might solve some annoying bugs
related on threading.
For a long time this function was only intended to be used from the main thread,
but since out implementation of parallel range (which is currently only used by
mesh deform modifier) we might want to switch to threaded alloc from object
update thread.
Now we're using spinlock around the check, which makes the code safe to be used
from all over the place.
We might consider using a bit of atomics operations magic there, but it's not so
much important for now, this code is not used in the performance critical code
path.
Fix for T36639 caused all path changes to reload (which could loose user content).
Change behavior:
- Only reload data when a flag is explicitly passed
(currently only used by Find Files operator)
- Don't reload images which have been painted onto and not saved (dirty flag set).
The problem was that it was aborting too early after stumbling across a point which
might fit within the bounds required. This commit improves the logic here to solve
this and a few other little bugs like that.
Disclaimer: There are still a few cases where it randomly ends up picking something
way off. However, this only seems to occur very sporadically, so it's hard to say
how bad the problem may be.
In pipeline.c the function add_freestyle() was supposed to be called once
per frame, but after the Multi-view merge the function are called as many
as the number of views. There were however a few Freestyle parameters
that have to be initialized per frame, and initializing one of the
parameters for each view was causing double freeing of allocated memory
which was enough to result in a crash.
Remane sound_scene_handle to playback handle.
sound_scene_handle was a part of scene so we could see code like scene-
often in the same function.
If I understand things correctly, in audaspace lingo, the
playback_handle corresponds to a Reader while the scene_sound
corresponds to a Factory.
More cleanups will be done here later, but changing this now because my
brain hurts trying to remember which is which...
Holds 30 frames in memory. Could make it check memory instead but that
should suffice for now to make sure blender does not crash on me with
movie files.
Previously the system would load eveything in memory so something like
playing caminandes in player would swap after 30 seconds in local
computer.
For animations, you often want an animated render seed (noise pattern).
This could be done by e.g. setting a driver on the seed value.
Now it's a little checkbox, that can be enabled.
The animated seed is based on the current Blender frame and
the seed value itself. Simply enabling it, will already result in an animated
seed (different on each Blender frame), but it can be randomized further
by setting a different seed value.
Disabled per default, so no backward compatibility break.
Differential Revision: https://developer.blender.org/D1285
team.
There are 3 options here:
1) Keep range (previous behaviour)
2) Seconds - allows a specified offset in seconds around current frame
3) keyframes - zoom to include a number of keyframes around the cursor
Options 2 and 3 have their own properties to tweak the behaviour and all
options can be found in User Preferences->Interface under the 2D
viewports section.
Number 3 will probably need some refinement so commiting here for the
hwoozeberry team to test first.
Experimental feature set id currently unavailable for megakernel, it'll
require some changes to the cache system to distinguish cached regular
kernels from cached experimental kernels.
Currently unused, but some features will be enabled soon.
Driver fails to compile kernel in reasonable time for those devices here,
so for easier testing of the OpenCL split kernel work disabling bake kernel
for now.
This required allocating some memory related on object transform needed
by ShaderData and currently it is done for all the platforms. Since we're
targeting full feature-complete platforms this is rather acceptable at
this point and in the future we'll do selective NO_HAIR/NO_SSS/NO_BLUR
kernels.
This is experimental still and in fact there're some major issues on
NVidia platform and it's not really clear if it's a bug in compiler,
some uninitizlied variable or other kind of issue.
Some stupid fixes like spaces around operator and missing semicolon,
plus fix for wrong detecting of ShaderData SOA size. Thar was harmless
since there's only one closure array, but still better to fix this.
This file was actually checking for features enabled on CPU and surely all
of them were enabled, so removing them does not cause any difference.
ideally we'll need to do runtime feature detection and just pass some stuff
as NULL to the kernel, or maybe also have variadic kernel entry points which
is also possible quite easily.
It's good for testing and seems to work quite reliably here.
This probably not totally cheap in terms of performance, but this we
could solve quite easily by selective kernel compilation once other
things are tested/proved to be reliable.
The actual character motion actuator triggers every frame the jump method.
Adding an edge detection to trigger the jump method.
Reviewers: lordloki, sybren, moguri
Reviewed By: moguri
Differential Revision: https://developer.blender.org/D1220
No need to store them in the class, they're unlikely to be changed
and if they do change we're in big trouble anyway.
More appropriate approach would be then to typedef this things in
kernel_types.h, but still use inlined sizeof(),
This resolves a problem where selected items edited for multi-value-editig
could include objects not in any visible views (unlocked layers, local view... etc).
Optimize the full rebuild case for now (though same code can be adapted to
partial redraws)
Main changes here:
* Calculate bounding centroid for faces only once (instead of every intermediate node)
* Faces do not get added to GSets immediately, instead we track a face
array which has faces that belong in a node in consecutive order.
Nodes just keep accounting of start and length in the array.
* Due to faces not being added to GSets, we can skip doing cleanup of GSets
and readdition for each intermediate node and instead only
add the faces to the final leafs node GSets when those nodes are created.
Results:
For a 1.9 million face test model, PBVH generation time (roughly measured by undoing) is
dropped from 6 seconds to about 4 seconds. Still too high, but still a nice improvement.
TODO:
Thread some parts. Unfortunately threading the GSet assignment part might not help much since
we'd need a lot of locking to avoid collisions with node assignments, especially for unique vertices.
EWA filtering with zero derivatives is introducing some fuzzyness into the
image. Currently solved by using regular sampling for cases when derivatives
are zero, which should also make compo faster in that areas.
Still need to look into checking if EWA filter can be tweaked in a way so
no fuzzyness is introduced.
Also use C++-style unused arguments tagging instead of legacy c-style.
It's less annoying this way because does not require adding argument to
two places of the function.
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
This commit only adds callbacks which then later be used with major dependency
graph commit, keeping the upcoming commit more clean to follow.
Should be no functional changes so far still.
This calls are not strictly speaking needed for the old dependency graph, but
due to more granular nature of upcoming depsgraph more actions requires update
of relations of IDs.
On the one hand this extra tags could be wrapped with if() statements, but on
the other hand it makes sense to keep tag in sync so it's clear if some issue
is caused by missing/extra tag or by depsgraph itself.
Currently this function only tags pose itself, totally matching previous
behavior. But this will be needed in the future once new dependency graph
is landed, because of it's granular nature which relies on the fact that
pose channels are all up to date when building the graph.
Should be no functional changes so far.
Currently it is just moving existing functions into a new file,
but in the future those new files will be grown much more due
to upcoming more granular scene updates.
Should be no functional changes.
- check for class/static methods assumed nonzero args.
- subclass references and set-flag items are now sorted.
- use 'order' for Py operator mix-ins,
so operator settings don't show in random order.
Most of this patch was created by Daniel Stokes, I'm mostly just cleaning
it up and testing it. Still todo: hardness. I need to figure out how to
handle the integer -> float conversion on a dynamic uniform.
Reviewers: psy-fi, brecht
Reviewed By: psy-fi
Subscribers: psy-fi
Differential Revision: https://developer.blender.org/D511
An assertion to check if `re->clipsta` < 0 (added as part of addressing
T36009 in rBrB795034c17d76bef2a15e576ac9c70ae2268a823b) was failing when
Freestyle viewport preview rendering takes place in the camera view with
an orthographic camera (in this case, the user-defined clipping range is
used without changes, so that `re->clipsta` is positive). The
`re->clipsta` property has a negative value only when the 3D viewport is
in an orthographic view but not in the camera view. It seems that this
viewport setting cannot be identified from rendering settings accessible
from Freestyle. Now a negative `re->clipsta` value is directly checked
instead, without relying on other render flags.
This commit mainly:
* Exposes PreviewImage struct in RNA, including ways for user to set images data.
* Adds a new kind of PreviewImage, using a file path and IMB_thumb to get image.
* Adds a new kind of custom icon using PreviewImage, unrelated to ID previews system.
* Adds a python API (utils.previews) to allow python scripts to access those custom previews/icons.
Note that loading image from files' thumbnails is done when needed (deferred loading), not
when defining the custom preview/icon.
WARNING: for release addons who would want to use this, please keep it to a strict minimum, really needed level.
We do not want our UI to explode under hundreds of different flashy icons!
For more info, see also the release notes of Blender 2.75 (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Addons)
and the example/templates featured with Blender.
Patch by Campbell (ideasman42), Inês (brita) and Bastien (mont29).
Differential Revision: https://developer.blender.org/D1255
Adds a Panel to the Object Context in the Properties Editor, currently
only containing a Menu to Add widgets. The menu contains 4 items,
Translate, Rotate, Scale and Custom, whereby we currently only draw a
translate widget for all of them. So yes, basic drawing also works.
Important is, that this makes it possible for users to attach custom
widgets to Objects. (Only the manipulator for the selected object is
drawn).
Enabled the manipulator widget code again and updated it to the current
system to continue work on it.
A customizable manipulator widget might be a good start for a bone
widget system.
Adds the basic cage widget to the Graph Editor backdrop. The backdrop
drawing while scaling needs to be corrected still, but besides from that
(almost) everything works now.
This commit adds a few generalizations to the VBO
code so that modifiers can create and populate their own GPU objects.
The VBO code originally supported CDDerivedMesh only. The design moves slightly
towards the viewport refactor where the rendering system requests data from the
modifiers.
In this commit only basic support for vertices and normals is provided and
some features from blender's VBO system, suchs as mapping to original faces,
unique element indices for vertices and loose vertex/edge support are missing.
Also, the quick navigation feature of the subsurf modifier won't be supported
for now.
What we do have is full support for solid shading with multiple materials,
flat/smooth shading and a big performance boost.
Now simply add a flag to the armature modifier to use facemaps. Facemaps
on the mesh object with the same name as the armature bones will get
displayed as widgets.
* Test display code that displays the active facemap. Will not work on
subsurf modifier yet (crash)
* Fix loading of files with facemaps
* Facemap data now reside on polys instead of tessfaces.
This commit adds a few generalizations to the VBO
code so that modifiers can create and populate their own GPU objects.
The VBO code originally supported CDDerivedMesh only. The design moves
slightly towards the viewport refactor where the rendering system
requests data from modifiers.
What we do have is support for solid shading with multiple
materials, flat/smooth shading and a big performance boost.
Performance could
In this commit only basic support for vertices and normals is provided
and some features from blender's VBO system, such as mapping to
original faces, unique element indices for vertices and loose vertex/
and can be added later. The one feature that is missing now is the quick
navigation feature of the multires modifier (which uses the same code).
- Why this commit is made on the widget branch -
Facemap widgets need to avoid drawing the whole mesh when we do
collision detection on them. For subsurf drawing we need to iterate
through the whole mesh every time. What we need instead is sort
indexed elemet drawing according to the facemap each face belongs to.
This screams VBOs but since I was going to add that, I thought that
I could push it a bit further and add proper solid shading support.
This commit adds a few generalizations to the VBO
code so that modifiers can create and populate their own GPU objects.
The VBO code originally supported CDDerivedMesh only. The design moves
slightly towards the viewport refactor where the rendering system
requests data from modifiers.
In this commit only basic support for vertices and normals is provided
and some features from blender's VBO system, such as mapping to
original faces, unique element indices for vertices and loose vertex/
and can be added later. The one feature that is missing now is the quick
navigation feature of the multires modifier (which uses the same code).
What we do have is full support for solid shading with multiple
materials, flat/smooth shading and a big performance boost.
Performance could
- Why this commit is made on the widget branch -
Facemap widgets need to avoid drawing the whole mesh when we do
collision detection on them. For subsurf drawing we need to iterate
through the whole mesh every time. What we need instead is sort
indexed elemet drawing according to the facemap each face belongs to.
This screams VBOs but since I was going to add that, I thought that
I could push it a bit further and add proper solid shading support.
A bone using a facemap will not be displayed at all, rather it will use
the facemap of the mesh as an interaction area. The facemap still does
nothing since it's not yet hooked up to the customdata and widget code.
That will come next.
They are set when a highlighted widget intersection is detected and on
area level.
There's a discussion about using owners and a stack or array for cursors
but that needs some more thought and design.
Due to this we -obviously- rename this to overdrop
I am not sure if others would agree here, but it's pretty safe to do
this on a branch first. Rationale is that it's much nicer to work on
full screen with this.
backdrop is now functional.
The widget could communicate with the sequencer properties directly, but
here we set it to control the operator properties as a demonstration.
After some minor stress testing, time to give this to gooseberry team.
Areas support more than one widgetmap - will be useful to partition area
in different transform regions like data, pixel, 3D (will be done in a
separate refactor).
Also get rid of the context widget hack in favour of adding the
widgetmap handler to the operator handler itself, so handling will
be unified when the widget controls a property or spawns an operator
Handle events for widgetmap first when and pass to operator when
operator is active.
This is still a pretty confusing design, working on a simpler one now.
* Minor cleanup - propname does not need to be stored anymore.
* Code to support modal widgetmap registration for operators - still
untested, but will be tested soon on sequencer cage widget
* Widgets take parameters to initialize property slots that are used for
feedback or control.
Cage now uses this to feed offset/scale to different properties.
* Initialize common properties during widget registration.
remove and add widgetgroup types from the system.
Start operator that will control sequencer backdrop. Architecture here
still needs a little work so good compatibility with Add-ons can be
ensured.
commit and operators to set faces in a group in edit mode.
Face maps are groupings of faces, similar to vertex groups, however,
each face can only belong to one face map.
They will be used for widget interaction, but there will possibly be
more uses for them in the future.
Code needs some cleanup still here, will apply as work is being done.
There is some code here for object mode interaction but it hasn't been
tested yet. This will probably be done with the widgets themselves.
transform the x direction of the backdrop in sequencer when a viewer
node is active.
There are still some issues with property transform not being a proper
operator, but we can fix that easily.
To make full 2D transform work we need positions stored in one property.
* Get rid of invalid flag (we avoid drawing widgets by dereferencing RNA
now so it should be OK)
* Add intersect function for 2D widgets (still needs correct mapping to
be any useful though)
Fix interaction when pivot is beside the camera. basically we now do all
calculations in 3D space and we do not scale correct the offset in 3D -
this creates a nasty dependency loop between drawing and calculation for
widgets bound to properties - ie offset depends on scale but scale
depends on screen position - ie offset.
Also added an extra callback to get the final position of the widget in
3d space and use that to calculate the scale. This takes care of
bringing a close to the camera widget to the background and the widget
keeping its initial size. The final position can be different from the
initial position, especially when the widget is offset from the original
position.
We now use plane/line intersection which seems to work quite well and
agrees to great extent with the transform system as well. There still
some small discrepancy but may also be related to scaling.
It may be better to use transform code for widgets but this will cause
nested operators for widget/operator and needs some consideration.
For transform e.g. we would have one transform operator taking care of
transformation of the widget, then feeding this back to regular object
transform.
Now widgetmaps get created and destroyed with the area. Not sure if it's
the best design but it avoids too many creations and recreations.
arrow offset now calculated at property binding time - no RNA access
during interaction means no chance of crash during undo.
To make this work, we need separate type/instance for the widgets. This
is a bit ugly but it is necessary if we want widgets on each editor to
depend of per editor-options or visibility state.
Still pretty much exploring the best way to move here but currently this
works by wrapping objects in RNA pointers, pretty much like buttons do.
Also modified the arrow widget for lamps to use the new code. The new
"unmbrella" widget works now as expected for lamps - of course fine
tuning is also needed.
* highlighted vs active widget.
Active widget takes all input and basically highjacks drawing of all
other widgets in the widgetmap.
* operator names for widgets. Now widgets will spawn operators based on
names that are passed on them. They will also modify a named property of
the operator and pass it on, after which operator can process it.
* Move lamp operators to a proper place
* Store a list of widgets to avoid polling too many times
* Fix wrong indices when widgetgroup was not used.
* Lamp widget now uses an arrow widget. This will be refined to make a
nice prototype for operator/widget interaction.
* Add option for shaded/non shaded widgets
* Normalize arrow widget size to 1.0 so size is predictable. Probably
will use the same scheme for other widgets as well
format (vertices + normals + triangle vertex indices)
This will allow us to create widgets in blender instead of defining them
programmatically.
May also support facegroups for different colors in the future though
they must be somehow tied to the UI colors.
Especially if we have many widgets on screen, sorting them will be
difficult and for mesh-armature widgets it will be unavoidable if we
want to avoid tweaking "back" surfaces.
There is first code for display of an arrow widget. The manipulator will
use those when they are ready.
Basically the manipulator is now a WidgetGroup. WidgetGroups are a new entity and
they manage a group of related widgets. They should be responsible for state update,
drawing and polling of their widgets and can be bound to specific rules.
There is a big design plan on a whiteboard beside me, it will take a few
big commits still to take shape though. One thing at a time, I am first making
reusable arrow widgets that will allow us replace the translate widgets properly.
There are a few reusable widgets planned, more to come later.
too.
Rationale - widgets might be useful to have even on rendered scenes -
we'll have to see about how this will work
Also use area initialization code to register region specific widgets once.
lala
This should use an "active" system, similar to buttons to detect if last
widget has changed and act accordingly. Currently, when the active
widget changes, there is no change in highlights.
Code that handles 3D object intersection via GPU selection. We might
want to use raycasting here, but leaving that for when we have it.
Manipulator code now uses this API to do intersection testing
Widgets use a similar notification system as operators. It might be
worth using WM_BREAK messages like the rest of the handlers. For now
this should do.
This commit has first WIP code for widgets API.
Generally widgets should be registered similar to dropboxes, that is,
any code can query for a widgetmap for a certain space and area type
and the window manager will take care of initializing the handlers
automatically.
The owner will be able remove and readd widgets to a certain widgetmap
dynamically. Generally owners should cleanup their widgets though initial code
cleans up leftover widgets automatically.
All this is the theory still, some parts are in that commit, more to come
later, but it's a solid base to build from for an initial commit.
2014-09-19 13:07:01 +02:00
1903 changed files with 112957 additions and 44078 deletions
# some of these libraries are problematic on Linux
# disable less important dependencies by default
set(_init_BUILDINFOOFF)
set(_init_CODEC_FFMPEGOFF)
set(_init_CYCLES_OSLOFF)
set(_init_IMAGE_OPENEXROFF)
set(_init_IMAGE_REDCODEOFF)
set(_init_INPUT_NDOFOFF)
set(_init_JACKOFF)
set(_init_LIBMV_SCHUR_SPECIALIZATIONOFF)
set(_init_OPENCOLLADAOFF)
set(_init_OPENCOLORIOOFF)
set(_init_SDLOFF)
set(_init_FFTW3OFF)
set(_init_GAMEENGINEOFF)
set(_init_OPENSUBDIVOFF)
elseif(WIN32)
set(_init_JACKOFF)
elseif(APPLE)
set(_init_INPUT_NDOFOFF)
set(_init_JACKOFF)
set(_init_OPENSUBDIVOFF)
endif()
@@ -197,7 +203,6 @@ option(WITH_PYTHON "Enable Embedded Python API (only disable for develop
option(WITH_PYTHON_SECURITY"Disables execution of scripts within blend files by default"ON)
mark_as_advanced(WITH_PYTHON)# dont want people disabling this unless they really know what they are doing.
mark_as_advanced(WITH_PYTHON_SECURITY)# some distributions see this as a security issue, rather than have them patch it, make a build option.
set(WITH_PYTHON_SECURITYONCACHEBOOL"ON"FORCE)# temp force on.
option(WITH_PYTHON_SAFETY"Enable internal API error checking to track invalid data to prevent crash on access (at the expense of some effeciency, only enable for development)."OFF)
Example of using a :class:`bge.types.SCA_MouseSensor`, and two :class:`bge.types.KX_ObjectActuator` to implement MouseLook:
Example of using a :class:`bge.types.SCA_MouseSensor`,
and two :class:`bge.types.KX_ObjectActuator` to implement MouseLook:
..note::
This can also be achieved with the :class:`bge.types.KX_MouseActuator`.
@@ -77,7 +78,9 @@ Constants
..DATA:: VSYNC_ADAPTIVE
Enables adaptive vsync if supported. Adaptive vsync enables vsync if the framerate is above the monitors refresh rate. Otherwise, vsync is diabled if the framerate is too low.
Enables adaptive vsync if supported.
Adaptive vsync enables vsync if the framerate is above the monitors refresh rate.
Otherwise, vsync is diabled if the framerate is too low.
..data:: LEFT_EYE
@@ -108,40 +111,55 @@ Functions
Set the width and height of the window (in pixels). This also works for fullscreen applications.
..note:: Only works in the standalone player, not the Blender-embedded player.
:arg width:width in pixels
:type width:integer
:arg height:height in pixels
:type height:integer
..function:: setFullScreen(enable)
Set whether or not the window should be fullscreen.
..note:: Only works in the standalone player, not the Blender-embedded player.
:arg enable:``True`` to set full screen, ``False`` to set windowed.
:type enable:bool
..function:: getFullScreen()
Returns whether or not the window is fullscreen.
..note:: Only works in the standalone player, not the Blender-embedded player; there it always returns False.
:rtype:bool
..function:: getDisplayDimensions()
Get the actual display dimensions, in pixels, of the physical display (e.g., the monitor).
Get the display dimensions, in pixels, of the display (e.g., the
monitor). Can return the size of the entire view, so the
combination of all monitors; for example, ``(3840, 1080)`` for two
side-by-side 1080p monitors.
:type dimension:list [width,heigh]
:rtype:tuple (width,height)
..function:: makeScreenshot(filename)
Writes an image file with the current displayed frame.
The image is written to *'filename'*. The path may be absolute (eg. "/home/foo/image") or relative when started with
"//" (eg. "//image"). Note that absolute paths are not portable between platforms.
If the filename contains a "#", it will be replaced by an incremental index so that screenshots can be taken multiple
times without overwriting the previous ones (eg. "image-#").
The image is written to *'filename'*.
The path may be absolute (eg. ``/home/foo/image``) or relative when started with
``//`` (eg. ``//image``). Note that absolute paths are not portable between platforms.
If the filename contains a ``#``,
it will be replaced by an incremental index so that screenshots can be taken multiple
times without overwriting the previous ones (eg. ``image-#``).
Settings for the image are taken from the render settings (file format and respective settings, gamma and colospace
conversion, etc). The image resolution matches the framebuffer, meaning, the window size and aspect ratio.
When running from the standalone player, instead of the embedded player, only PNG files are supported. Additional
color conversions are also not supported.
Settings for the image are taken from the render settings (file format and respective settings,
gamma and colospace conversion, etc).
The image resolution matches the framebuffer, meaning, the window size and aspect ratio.
When running from the standalone player, instead of the embedded player, only PNG files are supported.
Additional color conversions are also not supported.
:arg filename:path and name of the file to write
:type filename:string
@@ -149,13 +167,14 @@ Functions
..function:: enableVisibility(visible)
Doesn't really do anything...
Deprecated; doesn't do anything.
..function:: showMouse(visible)
Enables or disables the operating system mouse cursor.
:arg visible:
:type visible:boolean
@@ -163,15 +182,15 @@ Functions
Sets the mouse cursor position.
:arg x:X-coordinate in screen pixel coordinates.
:type x:integer
:arg y:Y-coordinate in screen pixel coordinates.
:type y:integer
..function:: setBackgroundColor(rgba)
Sets the window background color. (Deprecated: use KX_WorldInfo.background_color)
:type rgba:list [r, g, b, a]
Deprecated and no longer functional. Use :py:meth:`bge.types.KX_WorldInfo.backgroundColor` instead.
..function:: setEyeSeparation(eyesep)
@@ -215,6 +234,7 @@ Functions
Set the material mode to use for OpenGL rendering.
Look from a point/object to another point/object and find first object hit within dist that matches prop.
if poly is 0, returns a 3-tuple with object reference, hit point and hit normal or (None, None, None) if no hit.
@@ -828,6 +851,8 @@ base class --- :class:`SCA_IObject`
* 2: return value is a 5-tuple and the 5th element is a 2-tuple (u, v) with the UV mapping of the hit point or None if no hit, or the object doesn't use a mesh collision shape, or doesn't have a UV mapping.
:type poly:integer
:arg mask:collision mask: The collision mask (16 layers mapped to a 16-bit integer) is combined with each object's collision group, to hit only a subset of the objects in the scene. Only those objects for which ``collisionGroup & mask`` is true can be hit.
:type mask:bitfield
:return:(object, hitpoint, hitnormal) or (object, hitpoint, hitnormal, polygon) or (object, hitpoint, hitnormal, polygon, hituv).
* object, hitpoint and hitnormal are None if no hit.
@@ -949,6 +974,16 @@ base class --- :class:`SCA_IObject`
:return:The current frame of the action
:rtype:float
..method:: getActionName(layer=0)
Gets the name of the current action playing in the supplied layer.
:arg layer:The layer that you want to get the action name from.
:type layer:integer
:return:The name of the current action
:rtype:string
..method:: setActionFrame(frame, layer=0)
Set the current frame of the action playing in the supplied layer.
The uniform is an integer representing an internal texture used for certain effect
Represents an internal texture used for certain effect
(color band, etc).
:value:12
:type:integer
..data:: GPU_DYNAMIC_SAMPLER_2DIMAGE
The uniform is an integer representing a texture loaded from an image file.
Represents a texture loaded from an image file.
:value:13
:type:integer
..data:: GPU_DYNAMIC_SAMPLER_2DSHADOW
The uniform is an float representing the bumpmap scaling.
Represents a texture loaded from a shadow buffer file.
:value:14
..data:: GPU_DYNAMIC_OBJECT_AUTOBUMPSCALE
The uniform is an integer representing a shadow buffer corresponding to a lamp
casting shadow.
:value:15
:type:integer
GLSL attribute type
GLSL Mist Uniforms
^^^^^^^^^^^^^^^^^^
..data:: GPU_DYNAMIC_MIST_ENABLE:
See :class:`bpy.types.WorldMistSettings.use_mist`.
:type:float (0 or 1)
..data:: GPU_DYNAMIC_MIST_START
See :class:`bpy.types.WorldMistSettings.start`.
:type:float
See :class:`bpy.types.WorldMistSettings.depth`.
..data:: GPU_DYNAMIC_MIST_DISTANCE
:type:float
See :class:`bpy.types.WorldMistSettings.intensity`.
..data:: GPU_DYNAMIC_MIST_INTENSITY
:type:float
..data:: GPU_DYNAMIC_MIST_TYPE
See :class:`bpy.types.WorldMistSettings.falloff`.
:type:float (used as an index into the type)
..data:: GPU_DYNAMIC_MIST_COLOR
GLSL World Uniforms
^^^^^^^^^^^^^^^^^^^
..data:: GPU_DYNAMIC_HORIZON_COLOR
See :class:`bpy.types.World.horizon_color`.
:type:float3
..data:: GPU_DYNAMIC_AMBIENT_COLOR
See :class:`bpy.types.World.ambient_color`.
:type:float3
GLSL Material Uniforms
^^^^^^^^^^^^^^^^^^^^^^
..data:: GPU_DYNAMIC_MAT_DIFFRGB
See :class:`bpy.types.Material.diffuse_color`.
:type:float3
..data:: GPU_DYNAMIC_MAT_REF
See :class:`bpy.types.Material.diffuse_intensity`.
:type:float
..data:: GPU_DYNAMIC_MAT_SPECRGB
See :class:`bpy.types.Material.specular_color`.
:type:float3
..data:: GPU_DYNAMIC_MAT_SPEC
See :class:`bpy.types.Material.specular_intensity`.
:type:float
..data:: GPU_DYNAMIC_MAT_HARD
See :class:`bpy.types.Material.specular_hardness`.
:type:float
..data:: GPU_DYNAMIC_MAT_EMIT
See :class:`bpy.types.Material.emit`.
:type:float
..data:: GPU_DYNAMIC_MAT_AMB
See :class:`bpy.types.Material.ambient`.
:type:float
..data:: GPU_DYNAMIC_MAT_ALPHA
See :class:`bpy.types.Material.alpha`.
:type:float
GLSL Attribute Type
-------------------
.._attribute-type:
@@ -291,9 +429,7 @@ layer that contains the vertex attribute.
..code-block::python
mesh.uv_textures[attribute["name"]]
:value:5
mesh.uv_layers[attribute["name"]]
..data:: CD_MCOL
@@ -306,8 +442,6 @@ layer that contains the vertex attribute.
mesh.vertex_colors[attribute["name"]]
:value:6
..data:: CD_ORCO
Vertex attribute is original coordinates. Data type is vector 3 float.
@@ -319,8 +453,6 @@ layer that contains the vertex attribute.
mesh.vertices
:value:14
..data:: CD_TANGENT
Vertex attribute is the tangent vector. Data type is vector 4 float.
@@ -330,8 +462,6 @@ layer that contains the vertex attribute.
C function to compute the tangent layer from the other layers can be obtained from
blender.org.
:value:18
Functions
=========
@@ -341,8 +471,12 @@ Functions
..function:: export_shader(scene,material)
Extracts the GLSL shader producing the visual effect of material in scene for the purpose of
reusing the shader in an external engine. This function is meant to be used in material exporter
so that the GLSL shader can be exported entirely. The return value is a dictionary containing the
reusing the shader in an external engine.
This function is meant to be used in material exporter
so that the GLSL shader can be exported entirely.
The return value is a dictionary containing the
shader source code and all associated data.
:arg scene:the scene in which the material in rendered.
@@ -354,76 +488,91 @@ Functions
The dictionary contains the following elements:
* ["fragment"]: string
-``["fragment"]``: string
fragment shader source code.
* ["vertex"]: string
-``["vertex"]``: string
vertex shader source code.
* ["uniforms"]: sequence
-``["uniforms"]``: sequence
list of uniforms used in fragment shader, can be empty list. Each element of the
sequence is a dictionary with the following elements:
* ["varname"]: string
-``["varname"]``: string
name of the uniform in the fragment shader. Always of the form 'unf<number>'.
* ["datatype"]: integer
-``["datatype"]``: integer
data type of the uniform variable. Can be one of the following:
*:data:`gpu.GPU_DATA_1I` : use glUniform1i
*:data:`gpu.GPU_DATA_1F` : use glUniform1fv
*:data:`gpu.GPU_DATA_2F` : use glUniform2fv
*:data:`gpu.GPU_DATA_3F` : use glUniform3fv
*:data:`gpu.GPU_DATA_4F` : use glUniform4fv
*:data:`gpu.GPU_DATA_9F` : use glUniformMatrix3fv
*:data:`gpu.GPU_DATA_16F` : use glUniformMatrix4fv
..hlist::
:columns:2
*["type"] : integer
-:data:`gpu.GPU_DATA_1I` : use ``glUniform1i``
-:data:`gpu.GPU_DATA_1F` : use ``glUniform1fv``
-:data:`gpu.GPU_DATA_2F` : use ``glUniform2fv``
-:data:`gpu.GPU_DATA_3F` : use ``glUniform3fv``
-:data:`gpu.GPU_DATA_4F` : use ``glUniform4fv``
-:data:`gpu.GPU_DATA_9F` : use ``glUniformMatrix3fv``
-:data:`gpu.GPU_DATA_16F` : use ``glUniformMatrix4fv``
-``["type"]``: integer
type of uniform, determines the origin and method of calculation. See uniform-type_.
Depending on the type, more elements will be be present.
* ["lamp"]: :class:`bpy.types.Object`
Reference to the lamp object from which the uniforms value are extracted. Set for the following uniforms types:
-``["lamp"]``: :class:`bpy.types.Object`
Reference to the lamp object from which the uniforms value are extracted.
Set for the following uniforms types:
..hlist::
:columns:3
:columns:2
*:data:`gpu.GPU_DYNAMIC_LAMP_DYNVEC`
*:data:`gpu.GPU_DYNAMIC_LAMP_DYNCO`
*:data:`gpu.GPU_DYNAMIC_LAMP_DYNIMAT`
*:data:`gpu.GPU_DYNAMIC_LAMP_DYNPERSMAT`
*:data:`gpu.GPU_DYNAMIC_LAMP_DYNENERGY`
*:data:`gpu.GPU_DYNAMIC_LAMP_DYNCOL`
*:data:`gpu.GPU_DYNAMIC_SAMPLER_2DSHADOW`
-:data:`gpu.GPU_DYNAMIC_LAMP_DYNVEC`
-:data:`gpu.GPU_DYNAMIC_LAMP_DYNCO`
-:data:`gpu.GPU_DYNAMIC_LAMP_DYNIMAT`
-:data:`gpu.GPU_DYNAMIC_LAMP_DYNPERSMAT`
-:data:`gpu.GPU_DYNAMIC_LAMP_DYNENERGY`
-:data:`gpu.GPU_DYNAMIC_LAMP_DYNCOL`
-:data:`gpu.GPU_DYNAMIC_SAMPLER_2DSHADOW`
Notes:
* The uniforms:data:`gpu.GPU_DYNAMIC_LAMP_DYNVEC`, :data:`gpu.GPU_DYNAMIC_LAMP_DYNCO`, :data:`gpu.GPU_DYNAMIC_LAMP_DYNIMAT` and :data:`gpu.GPU_DYNAMIC_LAMP_DYNPERSMAT`
refer to the lamp object position and orientation, both of can be derived from the object world matrix:
- The uniforms
:data:`gpu.GPU_DYNAMIC_LAMP_DYNVEC`,
:data:`gpu.GPU_DYNAMIC_LAMP_DYNCO`,
:data:`gpu.GPU_DYNAMIC_LAMP_DYNIMAT` and
:data:`gpu.GPU_DYNAMIC_LAMP_DYNPERSMAT`
refer to the lamp object position and orientation,
both of can be derived from the object world matrix:
..code-block::python
obmat=uniform["lamp"].matrix_world
where obmat is the mat4_lamp_to_world_ matrix of the lamp as a 2 dimensional array,
the lamp world location location is in obmat[3].
the lamp world location location is in ``obmat[3]``.
* The uniform types:data:`gpu.GPU_DYNAMIC_LAMP_DYNENERGY` and :data:`gpu.GPU_DYNAMIC_LAMP_DYNCOL` refer to the lamp data bloc that you get from:
- The uniform types
:data:`gpu.GPU_DYNAMIC_LAMP_DYNENERGY` and
:data:`gpu.GPU_DYNAMIC_LAMP_DYNCOL`
refer to the lamp data bloc that you get from:
..code-block::python
la=uniform["lamp"].data
from which you get la.energy and la.color
from which you get ``lamp.energy`` and ``lamp.color``
* Lamp duplication is not supported: if you have duplicated lamps in your scene
- Lamp duplication is not supported: if you have duplicated lamps in your scene
(i.e. lamp that are instantiated by dupligroup, etc), this element will only
give you a reference to the orignal lamp and you will not know which instance
of the lamp it is refering too. You can still handle that case in the exporter
by distributing the uniforms amongst the duplicated lamps.
* ["image"]: :class:`bpy.types.Image`
Reference to the image databloc. Set for uniform type :data:`gpu.GPU_DYNAMIC_SAMPLER_2DIMAGE`. You can get the image data from:
-``["image"]``: :class:`bpy.types.Image`
Reference to the image databloc.
Set for uniform type
:data:`gpu.GPU_DYNAMIC_SAMPLER_2DIMAGE`.
You can get the image data from:
..code-block::python
@@ -432,60 +581,63 @@ Functions
# image size as a 2-dimensional array of int
uniform["image"].size
* ["texnumber"]: integer
-``["texnumber"]``: integer
Channel number to which the texture is bound when drawing the object.
Set for uniform types:data:`gpu.GPU_DYNAMIC_SAMPLER_2DBUFFER`, :data:`gpu.GPU_DYNAMIC_SAMPLER_2DIMAGE` and :data:`gpu.GPU_DYNAMIC_SAMPLER_2DSHADOW`.
Set for uniform types
:data:`gpu.GPU_DYNAMIC_SAMPLER_2DBUFFER`,
:data:`gpu.GPU_DYNAMIC_SAMPLER_2DIMAGE` and
:data:`gpu.GPU_DYNAMIC_SAMPLER_2DSHADOW`.
This is provided for information only: when reusing the shader outside blencer,
you are free to assign the textures to the channel of your choice and to pass
that number channel to the GPU in the uniform.
* ["texpixels"]: byte array
texture data for uniform type :data:`gpu.GPU_DYNAMIC_SAMPLER_2DBUFFER`. Although
the corresponding uniform is a 2D sampler, the texture is always a 1D texture
of n x 1 pixel. The texture size n is provided in ["texsize"] element.
-``["texpixels"]``: byte array
texture data for uniform type :data:`gpu.GPU_DYNAMIC_SAMPLER_2DBUFFER`.
Although the corresponding uniform is a 2D sampler,
the texture is always a 1D texture of n x 1 pixel.
The texture size n is provided in ["texsize"] element.
These texture are only used for computer generated texture (colorband, etc).
The texture data is provided so that you can make a real image out of it in the
exporter.
The texture data is provided so that you can make a real image out of it in the exporter.
* ["texsize"]: integer
-``["texsize"]``: integer
horizontal size of texture for uniform type :data:`gpu.GPU_DYNAMIC_SAMPLER_2DBUFFER`.
The texture data is in ["texpixels"].
* ["attributes"]: sequence
-``["attributes"]``: sequence
list of attributes used in vertex shader, can be empty. Blender doesn't use
standard attributes except for vertex position and normal. All other vertex
attributes must be passed using the generic glVertexAttrib functions.
attributes must be passed using the generic ``glVertexAttrib`` functions.
The attribute data can be found in the derived mesh custom data using RNA.
Each element of the sequence is a dictionary containing the following elements:
* ["varname"]: string
-``["varname"]``: string
name of the uniform in the vertex shader. Always of the form 'att<number>'.
* ["datatype"]: integer
-``["datatype"]``: integer
data type of vertex attribute, can be one of the following:
*:data:`gpu.GPU_DATA_2F`: use glVertexAttrib2fv
*:data:`gpu.GPU_DATA_3F`: use glVertexAttrib3fv
*:data:`gpu.GPU_DATA_4F`: use glVertexAttrib4fv
*:data:`gpu.GPU_DATA_4UB`: use glVertexAttrib4ubv
-:data:`gpu.GPU_DATA_2F`: use ``glVertexAttrib2fv``
-:data:`gpu.GPU_DATA_3F`: use ``glVertexAttrib3fv``
-:data:`gpu.GPU_DATA_4F`: use ``glVertexAttrib4fv``
-:data:`gpu.GPU_DATA_4UB`: use ``glVertexAttrib4ubv``
* ["number"]: integer
generic attribute number. This is provided for information only. Blender
doesn't use glBindAttribLocation to place generic attributes at specific location,
-``["number"]``: integer
Generic attribute number. This is provided for information only.
Blender doesn't use ``glBindAttribLocation`` to place generic attributes at specific location,
it lets the shader compiler place the attributes automatically and query the
placement with glGetAttribLocation. The result of this placement is returned in
this element.
placement with ``glGetAttribLocation``.
The result of this placement is returned in this element.
When using this shader in a render engine, you should either use
glBindAttribLocation to force the attribute at this location or use
glGetAttribLocation to get the placement chosen by the compiler of your GPU.
``glBindAttribLocation`` to force the attribute at this location or use
``glGetAttribLocation`` to get the placement chosen by the compiler of your GPU.
* ["type"]: integer
-``["type"]``: integer
type of the mesh custom data from which the vertex attribute is loaded.
See attribute-type_.
* ["name"]: string or integer
-``["name"]``: string or integer
custom data layer name, used for attribute type :data:`gpu.CD_MTFACE` and :data:`gpu.CD_MCOL`.
Example:
@@ -512,14 +664,14 @@ Notes
.._mat4_lamp_to_perspective:
1. Calculation of the *mat4_lamp_to_perspective* matrix for a spot lamp.
#. Calculation of the ``mat4_lamp_to_perspective`` matrix for a spot lamp.
The following pseudo code shows how the *mat4_lamp_to_perspective* matrix is computed
The following pseudo code shows how the ``mat4_lamp_to_perspective`` matrix is computed
in blender for uniforms of :data:`gpu.GPU_DYNAMIC_LAMP_DYNPERSMAT` type:
..code-block::python
#Get the lamp datablock with:
#Get the lamp datablock with:
lamp=bpy.data.objects[uniform["lamp"]].data
# Compute the projection matrix:
@@ -531,11 +683,11 @@ Notes
# The size of the projection plane is computed with the usual formula:
When writing your own scripts python is great for new developers to pick up and become productive, but you can also pick up odd habits or at least write scripts that are not easy for others to understand.
When writing your own scripts python is great for new developers to pick up and become productive,
but you can also pick up odd habits or at least write scripts that are not easy for others to understand.
For your own work this is of course fine, but if you want to collaborate with others or have your work included with blender there are practices we encourage.
For your own work this is of course fine,
but if you want to collaborate with others or have your work included with blender there are practices we encourage.
Style Conventions
=================
For Blender/Python development we have chosen to follow python suggested style guide to avoid mixing styles amongst our own scripts and make it easier to use python scripts from other projects.
For Blender/Python development we have chosen to follow python suggested style guide to avoid mixing styles
amongst our own scripts and make it easier to use python scripts from other projects.
Using our style guide for your own scripts makes it easier if you eventually want to contribute them to blender.
@@ -18,22 +22,17 @@ This style guide is known as pep8 and can be found `here <http://www.python.org/
A brief listing of pep8 criteria.
* camel caps for class names: MyClass
* all lower case underscore separated module names: my_module
* indentation of 4 spaces (no tabs)
* spaces around operators. ``1 + 1``, not ``1+1``
* only use explicit imports, (no importing '*')
* don't use single line: ``if val: body``, separate onto 2 lines instead.
- camel caps for class names: MyClass
- all lower case underscore separated module names: my_module
- indentation of 4 spaces (no tabs)
- spaces around operators. ``1 + 1``, not ``1+1``
- only use explicit imports, (no importing ``*``)
- don't use single line: ``if val: body``, separate onto 2 lines instead.
As well as pep8 we have other conventions used for blender python scripts.
* Use single quotes for enums, and double quotes for strings.
- Use single quotes for enums, and double quotes for strings.
Both are of course strings but in our internal API enums are unique items from a limited set. eg.
@@ -42,9 +41,11 @@ As well as pep8 we have other conventions used for blender python scripts.
* pep8 also defines that lines should not exceed 79 characters, we felt this is too restrictive so this is optional per script.
- pep8 also defines that lines should not exceed 79 characters,
we felt this is too restrictive so this is optional per script.
Periodically we run checks for pep8 compliance on blender scripts, for scripts to be included in this check add this line as a comment at the top of the script.
Periodically we run checks for pep8 compliance on blender scripts,
for scripts to be included in this check add this line as a comment at the top of the script.
``# <pep8 compliant>``
@@ -58,72 +59,75 @@ User Interface Layout
Some notes to keep in mind when writing UI layouts:
* UI code is quite simple. Layout declarations are there to easily create a decent layout.
- UI code is quite simple. Layout declarations are there to easily create a decent layout.
General rule here: If you need more code for the layout declaration,
then for the actual properties, you do it wrong.
General rule here: If you need more code for the layout declaration, then for the actual properties, you do it wrong.
Example layouts:
* layout()
- layout()
The basic layout is a simple Top -> Bottom layout.
The basic layout is a simple Top -> Bottom layout.
.. code-block:: python
layout.prop()
layout.prop()
layout.prop()
layout.prop()
* layout.row()
- layout.row()
Use row(), when you want more than 1 property in one line.
Use row(), when you want more than 1 property in one line.
.. code-block:: python
row=layout.row()
row.prop()
row.prop()
* layout.column()
row = layout.row()
row.prop()
row.prop()
- layout.column()
Use column(), when you want your properties in a column.
.. code-block:: python
col=layout.column()
col.prop()
col.prop()
* layout.split()
col = layout.column()
col.prop()
col.prop()
This can be used to create more complex layouts. For example you can split the layout and create two column() layouts next to each other.
- layout.split()
This can be used to create more complex layouts.
For example you can split the layout and create two column() layouts next to each other.
Don't use split, when you simply want two properties in a row. Use row() for that.
..code-block::python
split=layout.split()
col=split.column()
col.prop()
col.prop()
col=split.column()
col.prop()
col.prop()
split=layout.split()
col=split.column()
col.prop()
col.prop()
col=split.column()
col.prop()
col.prop()
Declaration names:
Try to only use these variable names for layout declarations:
* row for a row() layout
* col for a column() layout
* split for a split() layout
* flow for a column_flow() layout
* sub for a sub layout (a column inside a column for example)
- row for a row() layout
- col for a column() layout
- split for a split() layout
- flow for a column_flow() layout
- sub for a sub layout (a column inside a column for example)
Script Efficiency
=================
List Manipulation (General Python Tips)
---------------------------------------
@@ -133,7 +137,8 @@ Searching for list items
In Python there are some handy list functions that save you having to search through the list.
Even though you're not looping on the list data **python is**, so you need to be aware of functions that will slow down your script by searching the whole list.
Even though you're not looping on the list data **python is**,
so you need to be aware of functions that will slow down your script by searching the whole list.
..code-block::python
@@ -145,11 +150,16 @@ Even though you're not looping on the list data **python is**, so you need to be
Modifying Lists
^^^^^^^^^^^^^^^
In python we can add and remove from a list, this is slower when the list length is modified, especially at the start of the list, since all the data after the index of modification needs to be moved up or down 1 place.
In python we can add and remove from a list, this is slower when the list length is modified,
especially at the start of the list, since all the data after the index of
modification needs to be moved up or down 1 place.
The most simple way to add onto the end of the list is to use``my_list.append(list_item)`` or ``my_list.extend(some_list)`` and the fastest way to remove an item is ``my_list.pop()`` or ``del my_list[-1]``.
The most simple way to add onto the end of the list is to use
``my_list.append(list_item)`` or ``my_list.extend(some_list)`` and the fastest way to
remove an item is ``my_list.pop()`` or ``del my_list[-1]``.
To use an index you can use ``my_list.insert(index, list_item)`` or ``list.pop(index)`` for list removal, but these are slower.
To use an index you can use ``my_list.insert(index, list_item)`` or ``list.pop(index)``
for list removal, but these are slower.
Sometimes its faster (but more memory hungry) to just rebuild the list.
@@ -193,7 +203,8 @@ Use...
my_list.extend([a,b,c...])
Note that insert can be used when needed, but it is slower than append especially when inserting at the start of a long list.
Note that insert can be used when needed,
but it is slower than append especially when inserting at the start of a long list.
This example shows a very sub-optimal way of making a reversed list.
@@ -205,7 +216,8 @@ This example shows a very sub-optimal way of making a reversed list.
reverse_list.insert(0,list_item)
Python provides more convenient ways to reverse a list using the slice method, but you may want to time this before relying on it too much:
Python provides more convenient ways to reverse a list using the slice method,
but you may want to time this before relying on it too much:
..code-block::python
@@ -220,7 +232,8 @@ Use ``my_list.pop(index)`` rather than ``my_list.remove(list_item)``
This requires you to have the index of the list item but is faster since ``remove()`` will search the list.
Here is an example of how to remove items in 1 loop, removing the last items first, which is faster (as explained above).
Here is an example of how to remove items in 1 loop,
removing the last items first, which is faster (as explained above).
..code-block::python
@@ -232,7 +245,9 @@ Here is an example of how to remove items in 1 loop, removing the last items fir
my_list.pop(list_index)
This example shows a fast way of removing items, for use in cases where you can alter the list order without breaking the scripts functionality. This works by swapping 2 list items, so the item you remove is always last.
This example shows a fast way of removing items,
for use in cases where you can alter the list order without breaking the scripts functionality.
This works by swapping 2 list items, so the item you remove is always last.
..code-block::python
@@ -251,7 +266,9 @@ When removing many items in a large list this can provide a good speedup.
Avoid Copying Lists
^^^^^^^^^^^^^^^^^^^
When passing a list/dictionary to a function, it is faster to have the function modify the list rather than returning a new list so python doesn't have to duplicate the list in memory.
When passing a list/dictionary to a function,
it is faster to have the function modify the list rather than returning
a new list so python doesn't have to duplicate the list in memory.
Functions that modify a list in-place are more efficient than functions that create new lists.
@@ -296,20 +313,26 @@ Python’s string joining function. To join a list of strings
join is fastest on many strings,`string formatting <http://docs.python.org/py3k/library/string.html#string-formatting>`_ is quite fast too (better for converting data types). String arithmetic is slowest.
is quite fast too (better for converting data types). String arithmetic is slowest.
Parsing Strings (Import/Exporting)
----------------------------------
Since many file formats are ASCII, the way you parse/export strings can make a large difference in how fast your script runs.
Since many file formats are ASCII,
the way you parse/export strings can make a large difference in how fast your script runs.
There are a few ways to parse strings when importing them into Blender.
Parsing Numbers
^^^^^^^^^^^^^^^
Use ``float(string)`` rather than ``eval(string)``, if you know the value will be an int then ``int(string)``, float() will work for an int too but it's faster to read ints with int().
Use ``float(string)`` rather than ``eval(string)``, if you know the value will be an int then ``int(string)``,
float() will work for an int too but it's faster to read ints with int().
Checking String Start/End
^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -322,7 +345,8 @@ Use...
>>> if line.startswith("vert "):
Using ``startswith()`` is slightly faster (approx 5%) and also avoids a possible error with the slice length not matching the string length.
Using ``startswith()`` is slightly faster (approx 5%) and also avoids a possible
error with the slice length not matching the string length.
my_string.endswith("foo_bar") can be used for line endings too.
@@ -336,15 +360,19 @@ Use try/except Sparingly
The **try** statement is useful to save time writing error checking code.
However **try** is significantly slower than an **if** since an exception has to be set each time, so avoid using **try** in areas of your code that execute in a loop and runs many times.
However **try** is significantly slower than an **if** since an exception has to be set each time,
so avoid using **try** in areas of your code that execute in a loop and runs many times.
There are cases where using **try** is faster than checking whether the condition will raise an error, so it is worth experimenting.
There are cases where using **try** is faster than checking whether the condition will raise an error,
so it is worth experimenting.
Value Comparison
----------------
Python has two ways to compare values ``a == b`` and ``a is b``, the difference is that ``==`` may run the objects comparison function ``__cmp__()`` whereas ``is`` compares identity, that both variables reference the same item in memory.
Python has two ways to compare values ``a == b`` and ``a is b``,
the difference is that ``==`` may run the objects comparison function ``__cmp__()`` whereas ``is`` compares identity,
that both variables reference the same item in memory.
In cases where you know you are checking for the same value which is referenced from multiple places, ``is`` is faster.
@@ -362,3 +390,4 @@ While developing a script it's good to time it to be aware of any changes in per
This document attempts to help you work with the Blender API in areas that can be troublesome and avoid practices that are known to give instability.
This document attempts to help you work with the Blender API in areas
that can be troublesome and avoid practices that are known to give instability.
.._using_operators:
@@ -10,16 +11,15 @@ This document attempts to help you work with the Blender API in areas that can b
Using Operators
===============
Blender's operators are tools for users to access, that python can access them too is very useful nevertheless operators have limitations that can make them cumbersome to script.
Blender's operators are tools for users to access, that Python can access them too is very useful
nevertheless operators have limitations that can make them cumbersome to script.
Main limits are...
* Can't pass data such as objects, meshes or materials to operate on (operators use the context instead)
* The return value from calling an operator gives the success (if it finished or was canceled),
- Can't pass data such as objects, meshes or materials to operate on (operators use the context instead)
- The return value from calling an operator gives the success (if it finished or was canceled),
in some cases it would be more logical from an API perspective to return the result of the operation.
* Operators poll function can fail where an API function would raise an exception giving details on exactly why.
- Operators poll function can fail where an API function would raise an exception giving details on exactly why.
Why does an operator's poll fail?
@@ -32,20 +32,28 @@ When calling an operator gives an error like this:
Which raises the question as to what the correct context might be?
Typically operators check for the active area type, a selection or active object they can operate on, but some operators are more picky about when they run.
Typically operators check for the active area type, a selection or active object they can operate on,
but some operators are more picky about when they run.
In most cases you can figure out what context an operator needs simply be seeing how it's used in Blender and thinking about what it does.
In most cases you can figure out what context an operator needs
simply be seeing how it's used in Blender and thinking about what it does.
Unfortunately if you're still stuck - the only way to **really** know whats going on is to read the source code for the poll function and see what its checking.
Unfortunately if you're still stuck - the only way to **really** know
whats going on is to read the source code for the poll function and see what its checking.
For python operators it's not so hard to find the source since it's included with Blender and the source file/line is included in the operator reference docs.
For Python operators it's not so hard to find the source
since it's included with Blender and the source file/line is included in the operator reference docs.
Downloading and searching the C code isn't so simple, especially if you're not familiar with the C language but by searching the operator name or description you should be able to find the poll function with no knowledge of C.
Downloading and searching the C code isn't so simple,
especially if you're not familiar with the C language but by searching the
operator name or description you should be able to find the poll function with no knowledge of C.
..note::
Blender does have the functionality for poll functions to describe why they fail, but its currently not used much, if you're interested to help improve our API feel free to add calls to ``CTX_wm_operator_poll_msg_set`` where its not obvious why poll fails.
Blender does have the functionality for poll functions to describe why they fail,
but its currently not used much, if you're interested to help improve our API
feel free to add calls to ``CTX_wm_operator_poll_msg_set`` where its not obvious why poll fails.
>>> bpy.ops.gpencil.draw()
RuntimeError: Operator bpy.ops.gpencil.draw.poll() Failed to find Grease Pencil data to draw into
@@ -54,36 +62,45 @@ Downloading and searching the C code isn't so simple, especially if you're not f
The operator still doesn't work!
--------------------------------
Certain operators in Blender are only intended for use in a specific context, some operators for example are only called from the properties window where they check the current material, modifier or constraint.
Certain operators in Blender are only intended for use in a specific context,
some operators for example are only called from the properties window where they check the current material,
modifier or constraint.
Examples of this are:
*:mod:`bpy.ops.texture.slot_move`
*:mod:`bpy.ops.constraint.limitdistance_reset`
*:mod:`bpy.ops.object.modifier_copy`
*:mod:`bpy.ops.buttons.file_browse`
-:mod:`bpy.ops.texture.slot_move`
-:mod:`bpy.ops.constraint.limitdistance_reset`
-:mod:`bpy.ops.object.modifier_copy`
-:mod:`bpy.ops.buttons.file_browse`
Another possibility is that you are the first person to attempt to use this operator in a script and some modifications need to be made to the operator to run in a different context, if the operator should logically be able to run but fails when accessed from a script it should be reported to the bug tracker.
Another possibility is that you are the first person to attempt to use this operator
in a script and some modifications need to be made to the operator to run in a different context,
if the operator should logically be able to run but fails when accessed from a script
it should be reported to the bug tracker.
Stale Data
==========
No updates after setting values
-------------------------------
Sometimes you want to modify values from python and immediately access the updated values, eg:
Sometimes you want to modify values from Python and immediately access the updated values, eg:
Once changing the objects :class:`bpy.types.Object.location` you may want to access its transformation right after from :class:`bpy.types.Object.matrix_world`, but this doesn't work as you might expect.
Once changing the objects :class:`bpy.types.Object.location`
you may want to access its transformation right after from :class:`bpy.types.Object.matrix_world`,
but this doesn't work as you might expect.
Consider the calculations that might go into working out the object's final transformation, this includes:
* animation function curves.
* drivers and their pythons expressions.
* constraints
* parent objects and all of their f-curves, constraints etc.
- animation function curves.
- drivers and their Python expressions.
- constraints
- parent objects and all of their f-curves, constraints etc.
To avoid expensive recalculations every time a property is modified, Blender defers making the actual calculations until they are needed.
To avoid expensive recalculations every time a property is modified,
Blender defers making the actual calculations until they are needed.
However, while the script runs you may want to access the updated values.
In this case you need to call :class:`bpy.types.Scene.update` after modifying values, for example:
@@ -94,7 +111,9 @@ In this case you need to call :class:`bpy.types.Scene.update` after modifying va
bpy.context.scene.update()
Now all dependent data (child objects, modifiers, drivers... etc) has been recalculated and is available to the script.
Now all dependent data (child objects, modifiers, drivers... etc)
has been recalculated and is available to the script.
Can I redraw during the script?
-------------------------------
@@ -103,23 +122,33 @@ The official answer to this is no, or... *"You don't want to do that"*.
To give some background on the topic...
While a script executes Blender waits for it to finish and is effectively locked until its done, while in this state Blender won't redraw or respond to user input.
Normally this is not such a problem because scripts distributed with Blender tend not to run for an extended period of time, nevertheless scripts *can* take ages to execute and its nice to see whats going on in the view port.
While a script executes Blender waits for it to finish and is effectively locked until its done,
while in this state Blender won't redraw or respond to user input.
Normally this is not such a problem because scripts distributed with Blender
tend not to run for an extended period of time,
nevertheless scripts *can* take ages to execute and its nice to see whats going on in the view port.
Tools that lock Blender in a loop and redraw are highly discouraged since they conflict with Blenders ability to run multiple operators at once and update different parts of the interface as the tool runs.
Tools that lock Blender in a loop and redraw are highly discouraged
since they conflict with Blenders ability to run multiple operators
at once and update different parts of the interface as the tool runs.
So the solution here is to write a **modal** operator, that is - an operator which defines a modal() function, See the modal operator template in the text editor.
So the solution here is to write a **modal** operator, that is - an operator which defines a modal() function,
See the modal operator template in the text editor.
Modal operators execute on user input or setup their own timers to run frequently, they can handle the events or pass through to be handled by the keymap or other modal operators.
Modal operators execute on user input or setup their own timers to run frequently,
they can handle the events or pass through to be handled by the keymap or other modal operators.
Transform, Painting, Fly-Mode and File-Select are example of a modal operators.
Writing modal operators takes more effort than a simple ``for`` loop that happens to redraw but is more flexible and integrates better with Blenders design.
Writing modal operators takes more effort than a simple ``for`` loop
that happens to redraw but is more flexible and integrates better with Blenders design.
**Ok, Ok! I still want to draw from python**
**Ok, Ok! I still want to draw from Python**
If you insist - yes its possible, but scripts that use this hack wont be considered for inclusion in Blender and any issues with using it wont be considered bugs, this is also not guaranteed to work in future releases.
If you insist - yes its possible, but scripts that use this hack wont be considered
for inclusion in Blender and any issues with using it wont be considered bugs,
this is also not guaranteed to work in future releases.
..code-block::python
@@ -129,16 +158,18 @@ If you insist - yes its possible, but scripts that use this hack wont be conside
Modes and Mesh Access
=====================
When working with mesh data you may run into the problem where a script fails to run as expected in edit-mode. This is caused by edit-mode having its own data which is only written back to the mesh when exiting edit-mode.
When working with mesh data you may run into the problem where a script fails to run as expected in edit-mode.
This is caused by edit-mode having its own data which is only written back to the mesh when exiting edit-mode.
A common example is that exporters may access a mesh through ``obj.data`` (a :class:`bpy.types.Mesh`) but the user is in edit-mode, where the mesh data is available but out of sync with the edit mesh.
A common example is that exporters may access a mesh through ``obj.data`` (a :class:`bpy.types.Mesh`)
but the user is in edit-mode, where the mesh data is available but out of sync with the edit mesh.
In this situation you can...
* Exit edit-mode before running the tool.
* Explicitly update the mesh by calling :class:`bmesh.types.BMesh.to_mesh`.
* Modify the script to support working on the edit-mode data directly, see: :mod:`bmesh.from_edit_mesh`.
* Report the context as incorrect and only allow the script to run outside edit-mode.
- Exit edit-mode before running the tool.
- Explicitly update the mesh by calling :class:`bmesh.types.BMesh.to_mesh`.
- Modify the script to support working on the edit-mode data directly, see: :mod:`bmesh.from_edit_mesh`.
- Report the context as incorrect and only allow the script to run outside edit-mode.
.._info_gotcha_mesh_faces:
@@ -146,35 +177,55 @@ In this situation you can...
NGons and Tessellation Faces
============================
Since 2.63 NGons are supported, this adds some complexity since in some cases you need to access triangles/quads still (some exporters for example).
Since 2.63 NGons are supported, this adds some complexity
since in some cases you need to access triangles/quads still (some exporters for example).
There are now 3 ways to access faces:
*:class:`bpy.types.MeshPolygon` - this is the data structure which now stores faces in object mode (access as ``mesh.polygons`` rather then ``mesh.faces``).
*:class:`bpy.types.MeshTessFace` - the result of triangulating (tessellated) polygons, the main method of face access in 2.62 or older (access as ``mesh.tessfaces``).
*:class:`bmesh.types.BMFace` - the polygons as used in editmode.
-:class:`bpy.types.MeshPolygon` -
this is the data structure which now stores faces in object mode
(access as ``mesh.polygons`` rather than ``mesh.faces``).
-:class:`bpy.types.MeshTessFace` -
the result of triangulating (tessellated) polygons,
the main method of face access in 2.62 or older (access as ``mesh.tessfaces``).
-:class:`bmesh.types.BMFace` -
the polygons as used in editmode.
For the purpose of the following documentation, these will be referred to as polygons, tessfaces and bmesh-faces respectively.
For the purpose of the following documentation,
these will be referred to as polygons, tessfaces and bmesh-faces respectively.
Using the :mod:`bmesh` api is completely separate api from :mod:`bpy`, typically you would would use one or the other based on the level of editing needed, not simply for a different way to access faces.
Using the :mod:`bmesh` api is completely separate api from :mod:`bpy`,
typically you would would use one or the other based on the level of editing needed,
not simply for a different way to access faces.
Creating
@@ -182,9 +233,18 @@ Creating
All 3 datatypes can be used for face creation.
* polygons are the most efficient way to create faces but the data structure is _very_ rigid and inflexible, you must have all your vertes and faces ready and create them all at once. This is further complicated by the fact that each polygon does not store its own verts (as with tessfaces), rather they reference an index and size in :class:`bpy.types.Mesh.loops` which are a fixed array too.
* tessfaces ideally should not be used for creating faces since they are really only tessellation cache of polygons, however for scripts upgrading from 2.62 this is by far the most straightforward option. This works by creating tessfaces and when finished - they can be converted into polygons by calling :class:`bpy.types.Mesh.update`. The obvious limitation is ngons can't be created this way.
* bmesh-faces are most likely the easiest way for new scripts to create faces, since faces can be added one by one and the api has features intended for mesh manipulation. While :class:`bmesh.types.BMesh` uses more memory it can be managed by only operating on one mesh at a time.
- polygons are the most efficient way to create faces but the data structure is _very_ rigid and inflexible,
you must have all your vertes and faces ready and create them all at once.
This is further complicated by the fact that each polygon does not store its own verts (as with tessfaces),
rather they reference an index and size in :class:`bpy.types.Mesh.loops` which are a fixed array too.
- tessfaces ideally should not be used for creating faces since they are really only tessellation cache of polygons,
however for scripts upgrading from 2.62 this is by far the most straightforward option.
This works by creating tessfaces and when finished -
they can be converted into polygons by calling :class:`bpy.types.Mesh.update`.
The obvious limitation is ngons can't be created this way.
- bmesh-faces are most likely the easiest way for new scripts to create faces,
since faces can be added one by one and the api has features intended for mesh manipulation.
While :class:`bmesh.types.BMesh` uses more memory it can be managed by only operating on one mesh at a time.
Editing
@@ -192,18 +252,24 @@ Editing
Editing is where the 3 data types vary most.
*polygons are very limited for editing, changing materials and options like smooth works but for anything else they are too inflexible and are only intended for storage.
* tessfaces should not be used for editing geometry because doing so will cause existing ngons to be tessellated.
* bmesh-faces are by far the best way to manipulate geometry.
-Polygons are very limited for editing,
changing materials and options like smooth works but for anything else
they are too inflexible and are only intended for storage.
- Tessfaces should not be used for editing geometry because doing so will cause existing ngons to be tessellated.
- BMesh-Faces are by far the best way to manipulate geometry.
Exporting
---------
All 3 data types can be used for exporting, the choice mostly depends on whether the target format supports ngons or not.
All 3 data types can be used for exporting,
the choice mostly depends on whether the target format supports ngons or not.
*polygons are the most direct & efficient way to export providing they convert into the output format easily enough.
*tessfaces work well for exporting to formats which dont support ngons, in fact this is the only place where their use is encouraged.
* bmesh-faces can work for exporting too but may not be necessary if polygons can be used since using bmesh gives some overhead because its not the native storage format in object mode.
-Polygons are the most direct & efficient way to export providing they convert into the output format easily enough.
-Tessfaces work well for exporting to formats which dont support ngons,
in fact this is the only place where their use is encouraged.
- BMesh-Faces can work for exporting too but may not be necessary if polygons can be used
since using bmesh gives some overhead because its not the native storage format in object mode.
Upgrading Importers from 2.62
@@ -213,9 +279,9 @@ Importers can be upgraded to work with only minor changes.
The main change to be made is used the tessellation versions of each attribute.
Once the data is created call :class:`bpy.types.Mesh.update` to convert the tessfaces into polygons.
@@ -223,7 +289,9 @@ Once the data is created call :class:`bpy.types.Mesh.update` to convert the tess
Upgrading Exporters from 2.62
-----------------------------
For exporters the most direct way to upgrade is to use tessfaces as with importing however its important to know that tessfaces may **not** exist for a mesh, the array will be empty as if there are no faces.
For exporters the most direct way to upgrade is to use tessfaces as with importing
however its important to know that tessfaces may **not** exist for a mesh,
the array will be empty as if there are no faces.
So before accessing tessface data call: :class:`bpy.types.Mesh.update```(calc_tessface=True)``.
@@ -231,7 +299,8 @@ So before accessing tessface data call: :class:`bpy.types.Mesh.update` ``(calc_t
EditBones, PoseBones, Bone... Bones
===================================
Armature Bones in Blender have three distinct data structures that contain them. If you are accessing the bones through one of them, you may not have access to the properties you really need.
Armature Bones in Blender have three distinct data structures that contain them.
If you are accessing the bones through one of them, you may not have access to the properties you really need.
..note::
@@ -241,7 +310,9 @@ Armature Bones in Blender have three distinct data structures that contain them.
Edit Bones
----------
``bpy.context.object.data.edit_bones`` contains a editbones; to access them you must set the armature mode to edit mode first (editbones do not exist in object or pose mode). Use these to create new bones, set their head/tail or roll, change their parenting relationships to other bones, etc.
``bpy.context.object.data.edit_bones`` contains a editbones;
to access them you must set the armature mode to edit mode first (editbones do not exist in object or pose mode).
Use these to create new bones, set their head/tail or roll, change their parenting relationships to other bones, etc.
Example using :class:`bpy.types.EditBone` in armature editmode:
@@ -261,7 +332,9 @@ Returns an editbone only in edit mode.
Bones (Object Mode)
-------------------
``bpy.context.object.data.bones`` contains bones. These *live* in object mode, and have various properties you can change, note that the head and tail properties are read-only.
``bpy.context.object.data.bones`` contains bones.
These *live* in object mode, and have various properties you can change,
note that the head and tail properties are read-only.
Example using :class:`bpy.types.Bone` in object or pose mode:
@@ -281,7 +354,9 @@ Accessible but read-only
Pose Bones
----------
``bpy.context.object.pose.bones`` contains pose bones. This is where animation data resides, i.e. animatable transformations are applied to pose bones, as are constraints and ik-settings.
This is where animation data resides, i.e. animatable transformations
are applied to pose bones, as are constraints and ik-settings.
Examples using :class:`bpy.types.PoseBone` in object or pose mode:
@@ -296,19 +371,27 @@ Examples using :class:`bpy.types.PoseBone` in object or pose mode:
..note::
Notice the pose is accessed from the object rather than the object data, this is why blender can have 2 or more objects sharing the same armature in different poses.
Notice the pose is accessed from the object rather than the object data,
this is why blender can have 2 or more objects sharing the same armature in different poses.
..note::
Strictly speaking PoseBone's are not bones, they are just the state of the armature, stored in the :class:`bpy.types.Object` rather than the :class:`bpy.types.Armature`, the real bones are however accessible from the pose bones - :class:`bpy.types.PoseBone.bone`
Strictly speaking PoseBone's are not bones, they are just the state of the armature,
stored in the :class:`bpy.types.Object` rather than the :class:`bpy.types.Armature`,
the real bones are however accessible from the pose bones - :class:`bpy.types.PoseBone.bone`
Armature Mode Switching
-----------------------
While writing scripts that deal with armatures you may find you have to switch between modes, when doing so take care when switching out of editmode not to keep references to the edit-bones or their head/tail vectors. Further access to these will crash blender so its important the script clearly separates sections of the code which operate in different modes.
While writing scripts that deal with armatures you may find you have to switch between modes,
when doing so take care when switching out of edit-mode not to keep references
to the edit-bones or their head/tail vectors.
Further access to these will crash blender so its important the script
clearly separates sections of the code which operate in different modes.
This is mainly an issue with editmode since pose data can be manipulated without having to be in pose mode, however for operator access you may still need to enter pose mode.
This is mainly an issue with editmode since pose data can be manipulated without having to be in pose mode,
however for operator access you may still need to enter pose mode.
Data Names
@@ -343,10 +426,13 @@ Or with name assignment...
Data names may not match the assigned values if they exceed the maximum length, are already used or an empty string.
Its better practice not to reference objects by names at all, once created you can store the data in a list, dictionary, on a class etc, there is rarely a reason to have to keep searching for the same data by name.
Its better practice not to reference objects by names at all,
once created you can store the data in a list, dictionary, on a class etc,
there is rarely a reason to have to keep searching for the same data by name.
If you do need to use name references, its best to use a dictionary to maintain a mapping between the names of the imported assets and the newly created data, this way you don't run this risk of referencing existing data from the blend file, or worse modifying it.
If you do need to use name references, its best to use a dictionary to maintain
a mapping between the names of the imported assets and the newly created data,
this way you don't run this risk of referencing existing data from the blend file, or worse modifying it.
..code-block::python
@@ -358,18 +444,22 @@ If you do need to use name references, its best to use a dictionary to maintain
# normally some code, or function calls...
# use own dictionary rather then bpy.data
# use own dictionary rather than bpy.data
mesh=mesh_name_mapping[meshid]
Library Collisions
------------------
Blender keeps data names unique - :class:`bpy.types.ID.name` so you can't name two objects, meshes, scenes etc the same thing by accident.
Blender keeps data names unique - :class:`bpy.types.ID.name` so you can't name two objects,
meshes, scenes etc the same thing by accident.
However when linking in library data from another blend file naming collisions can occur, so its best to avoid referencing data by name at all.
However when linking in library data from another blend file naming collisions can occur,
so its best to avoid referencing data by name at all.
This can be tricky at times and not even blender handles this correctly in some case (when selecting the modifier object for eg you can't select between multiple objects with the same name), but its still good to try avoid problems in this area.
This can be tricky at times and not even blender handles this correctly in some case
(when selecting the modifier object for eg you can't select between multiple objects with the same name),
but its still good to try avoid problems in this area.
If you need to select between local and library data, there is a feature in ``bpy.data`` members to allow for this.
@@ -394,21 +484,23 @@ If you need to select between local and library data, there is a feature in ``bp
Relative File Paths
===================
Blenders relative file paths are not compatible with standard python modules such as ``sys`` and ``os``.
Blenders relative file paths are not compatible with standard Python modules such as ``sys`` and ``os``.
Built in python functions don't understand blenders ``//`` prefix which denotes the blend file path.
Built in Python functions don't understand blenders ``//`` prefix which denotes the blend file path.
A common case where you would run into this problem is when exporting a material with associated image paths.
>>> bpy.path.abspath(image.filepath)
>>> bpy.path.abspath(image.filepath)
When using blender data from linked libraries there is an unfortunate complication since the path will be relative to the library rather then the open blend file. When the data block may be from an external blend file pass the library argument from the :class:`bpy.types.ID`.
When using blender data from linked libraries there is an unfortunate complication
since the path will be relative to the library rather than the open blend file.
When the data block may be from an external blend file pass the library argument from the :class:`bpy.types.ID`.
These returns the absolute path which can be used with native python modules.
These returns the absolute path which can be used with native Python modules.
Unicode Problems
@@ -449,23 +541,28 @@ Here are 2 ways around filesystem encoding issues:
>>> bpy.context.object.name = filepath_utf8
Unicode encoding/decoding is a big topic with comprehensive python documentation, to avoid getting stuck too deep in encoding problems - here are some suggestions:
Unicode encoding/decoding is a big topic with comprehensive Python documentation,
to avoid getting stuck too deep in encoding problems - here are some suggestions:
* Always use utf-8 encoiding or convert to utf-8 where the input is unknown.
- Always use utf-8 encoding or convert to utf-8 where the input is unknown.
- Avoid manipulating filepaths as strings directly, use ``os.path`` functions instead.
- Use ``os.fsencode()`` / ``os.fsdecode()`` instead of built in string decoding functions when operating on paths.
- To print paths or to include them in the user interface use ``repr(path)`` first
or ``"%r" % path`` with string formatting.
* Avoid manipulating filepaths as strings directly, use ``os.path`` functions instead.
..note::
* Use ``os.fsencode()`` / ``os.fsdecode()`` rather then the built in string decoding functions when operating on paths.
* To print paths or to include them in the user interface use ``repr(path)`` first or ``"%r" % path`` with string formatting.
***Possibly** - use bytes instead of python strings, when reading some input its less trouble to read it as binary data though you will still need to decide how to treat any strings you want to use with Blender, some importers do this.
Sometimes it's preferrable to avoid string encoding issues by using bytes instead of Python strings,
when reading some input its less trouble to read it as binary data
though you will still need to decide how to treat any strings you want to use with Blender,
some importers do this.
Strange errors using 'threading' module
=======================================
Python threading with Blender only works properly when the threads finish up before the script does. By using ``threading.join()`` for example.
Python threading with Blender only works properly when the threads finish up before the script does.
By using ``threading.join()`` for example.
Heres an example of threading supported by Blender:
@@ -504,7 +601,8 @@ Heres an example of threading supported by Blender:
t.join()
This an example of a timer which runs many times a second and moves the default cube continuously while Blender runs **(Unsupported)**.
This an example of a timer which runs many times a second and moves
the default cube continuously while Blender runs **(Unsupported)**.
..code-block::python
@@ -521,38 +619,48 @@ This an example of a timer which runs many times a second and moves the default
my_timer()
Use cases like the one above which leave the thread running once the script finishes may seem to work for a while but end up causing random crashes or errors in Blender's own drawing code.
Use cases like the one above which leave the thread running once the script finishes
may seem to work for a while but end up causing random crashes or errors in Blender's own drawing code.
So far, no work has gone into making Blender's python integration thread safe, so until its properly supported, best not make use of this.
So far, no work has gone into making Blender's Python integration thread safe,
so until its properly supported, best not make use of this.
..note::
Pythons threads only allow co-currency and won't speed up your scripts on multi-processor systems, the ``subprocess`` and ``multiprocess`` modules can be used with Blender and make use of multiple CPU's too.
Pythons threads only allow co-currency and won't speed up your scripts on multi-processor systems,
the ``subprocess`` and ``multiprocess`` modules can be used with Blender and make use of multiple CPU's too.
Help! My script crashes Blender
===============================
Ideally it would be impossible to crash Blender from python however there are some problems with the API where it can be made to crash.
Ideally it would be impossible to crash Blender from Python
however there are some problems with the API where it can be made to crash.
Strictly speaking this is a bug in the API but fixing it would mean adding memory verification on every access since most crashes are caused by the python objects referencing Blenders memory directly, whenever the memory is freed, further python access to it can crash the script. But fixing this would make the scripts run very slow, or writing a very different kind of API which doesn't reference the memory directly.
Strictly speaking this is a bug in the API but fixing it would mean adding memory verification
on every access since most crashes are caused by the Python objects referencing Blenders memory directly,
whenever the memory is freed, further Python access to it can crash the script.
But fixing this would make the scripts run very slow,
or writing a very different kind of API which doesn't reference the memory directly.
Here are some general hints to avoid running into these problems.
* Be aware of memory limits, especially when working with large lists since Blender can crash simply by running out of memory.
* Many hard to fix crashes end up being because of referencing freed data, when removing data be sure not to hold any references to it.
* Modules or classes that remain active while Blender is used, should not hold references to data the user may remove, instead, fetch data from the context each time the script is activated.
* Crashes may not happen every time, they may happen more on some configurations/operating-systems.
- Be aware of memory limits,
especially when working with large lists since Blender can crash simply by running out of memory.
- Many hard to fix crashes end up being because of referencing freed data,
when removing data be sure not to hold any references to it.
- Modules or classes that remain active while Blender is used,
should not hold references to data the user may remove, instead,
fetch data from the context each time the script is activated.
- Crashes may not happen every time, they may happen more on some configurations/operating-systems.
..note::
To find the line of your script that crashes you can use the ``faulthandler`` module.
See `faulthandler docs <http://docs.python.org/dev/library/faulthandler.html>`_.
While the crash may be in Blenders C/C++ code, this can help a lot to track down the area of the script that causes the crash.
While the crash may be in Blenders C/C++ code,
this can help a lot to track down the area of the script that causes the crash.
Undo/Redo
@@ -572,28 +680,36 @@ This example shows how you can tell undo changes the memory locations.
>>> hash(bpy.context.object)
-9223372036849951740
As suggested above, simply not holding references to data when Blender is used interactively by the user is the only way to ensure the script doesn't become unstable.
As suggested above, simply not holding references to data when Blender is used
interactively by the user is the only way to ensure the script doesn't become unstable.
Undo & Library Data
^^^^^^^^^^^^^^^^^^^
One of the advantages with Blenders library linking system that undo can skip checking changes in library data since it is assumed to be static.
One of the advantages with Blenders library linking system that undo
can skip checking changes in library data since it is assumed to be static.
Tools in Blender are not allowed to modify library data.
Python however does not enforce this restriction.
This can be useful in some cases, using a script to adjust material values for example.
But its also possible to use a script to make library data point to newly created local data, which is not supported since a call to undo will remove the local data but leave the library referencing it and likely crash.
But its also possible to use a script to make library data point to newly created local data,
which is not supported since a call to undo will remove the local data
but leave the library referencing it and likely crash.
So it's best to consider modifying library data an advanced usage of the API and only to use it when you know what you're doing.
So it's best to consider modifying library data an advanced usage of the API
and only to use it when you know what you're doing.
Edit Mode / Memory Access
-------------------------
Switching edit-mode ``bpy.ops.object.mode_set(mode='EDIT')`` / ``bpy.ops.object.mode_set(mode='OBJECT')`` will re-allocate objects data, any references to a meshes vertices/polygons/uvs, armatures bones, curves points etc cannot be accessed after switching edit-mode.
any references to a meshes vertices/polygons/uvs, armatures bones,
curves points etc cannot be accessed after switching edit-mode.
Only the reference to the data its self can be re-accessed, the following example will crash.
@@ -608,7 +724,8 @@ Only the reference to the data its self can be re-accessed, the following exampl
print(polygons)
So after switching edit-mode you need to re-access any object data variables, the following example shows how to avoid the crash above.
So after switching edit-mode you need to re-access any object data variables,
the following example shows how to avoid the crash above.
..code-block::python
@@ -622,13 +739,15 @@ So after switching edit-mode you need to re-access any object data variables, th
print(polygons)
These kinds of problems can happen for any functions which re-allocate the object data but are most common when switching edit-mode.
These kinds of problems can happen for any functions which re-allocate
the object data but are most common when switching edit-mode.
Array Re-Allocation
-------------------
When adding new points to a curve or vertices's/edges/polygons to a mesh, internally the array which stores this data is re-allocated.
When adding new points to a curve or vertices's/edges/polygons to a mesh,
internally the array which stores this data is re-allocated.
..code-block::python
@@ -639,15 +758,20 @@ When adding new points to a curve or vertices's/edges/polygons to a mesh, intern
# this will crash!
point.co=1.0,2.0,3.0
This can be avoided by re-assigning the point variables after adding the new one or by storing indices's to the points rather then the points themselves.
This can be avoided by re-assigning the point variables after adding the new one or by storing
indices's to the points rather than the points themselves.
The best way is to sidestep the problem altogether add all the points to the curve at once. This means you don't have to worry about array re-allocation and its faster too since reallocating the entire array for every point added is inefficient.
The best way is to sidestep the problem altogether add all the points to the curve at once.
This means you don't have to worry about array re-allocation and its faster too
since reallocating the entire array for every point added is inefficient.
Removing Data
-------------
**Any** data that you remove shouldn't be modified or accessed afterwards, this includes f-curves, drivers, render layers, timeline markers, modifiers, constraints along with objects, scenes, groups, bones.. etc.
**Any** data that you remove shouldn't be modified or accessed afterwards,
this includes f-curves, drivers, render layers, timeline markers, modifiers, constraints
along with objects, scenes, groups, bones.. etc.
The ``remove()`` api calls will invalidate the data they free to prevent common mistakes.
@@ -658,12 +782,13 @@ The following example shows how this precortion works.
mesh=bpy.data.meshes.new(name="MyMesh")
# normally the script would use the mesh here...
bpy.data.meshes.remove(mesh)
print(mesh.name)# <- give an exception rather then crashing:
print(mesh.name)# <- give an exception rather than crashing:
# ReferenceError: StructRNA of type Mesh has been removed
But take care because this is limited to scripts accessing the variable which is removed, the next example will still crash.
But take care because this is limited to scripts accessing the variable which is removed,
the next example will still crash.
..code-block::python
@@ -676,9 +801,11 @@ But take care because this is limited to scripts accessing the variable which is
sys.exit
========
Some python modules will call ``sys.exit()`` themselves when an error occurs, while not common behavior this is something to watch out for because it may seem as if blender is crashing since ``sys.exit()`` will quit blender immediately.
Some Python modules will call ``sys.exit()`` themselves when an error occurs,
while not common behavior this is something to watch out for because it may seem
as if Blender is crashing since ``sys.exit()`` will close Blender immediately.
For example, the ``optparse`` module will print an error and exit if the arguments are invalid.
An ugly way of troubleshooting this is to set ``sys.exit = None`` and see what line of python code is quitting, you could of course replace ``sys.exit`` with your own function but manipulating python in this way is bad practice.
For example, the ``argparse`` module will print an error and exit if the arguments are invalid.
An ugly way of troubleshooting this is to set ``sys.exit = None`` and see what line of Python code is quitting,
you could of course replace ``sys.exit`` with your own function but manipulating Python in this way is bad practice.
This document is to give an understanding of how python and blender fit together, covering some of the functionality that isn't obvious from reading the API reference and example scripts.
This document is to give an understanding of how Python and Blender fit together,
covering some of the functionality that isn't obvious from reading the API reference and example scripts.
Python in Blender
=================
Blender embeds a python interpreter which is started with blender and stays active. This interpreter runs scripts to draw the user interface and is used for some of Blender's internal tools too.
Blender embeds a Python interpreter which is started with Blender and stays active.
This interpreter runs scripts to draw the user interface and is used for some of Blender's internal tools too.
This is a typical python environment so tutorials on how to write python scripts will work running the scripts in blender too. Blender provides the :mod:`bpy` module to the python interpreter. This module can be imported in a script and gives access to blender data, classes, and functions. Scripts that deal with blender data will need to import this module.
This is a typical Python environment so tutorials on how to write Python scripts
will work running the scripts in Blender too.
Blender provides the :mod:`bpy` module to the Python interpreter.
This module can be imported in a script and gives access to Blender data, classes, and functions.
Scripts that deal with Blender data will need to import this module.
Here is a simple example of moving a vertex of the object named **Cube**:
@@ -21,84 +28,96 @@ Here is a simple example of moving a vertex of the object named **Cube**:
This modifies Blender's internal data directly. When you run this in the interactive console you will see the 3D viewport update.
This modifies Blender's internal data directly.
When you run this in the interactive console you will see the 3D viewport update.
The Default Environment
=======================
When developing your own scripts it may help to understand how blender sets up its python environment. Many python scripts come bundled with blender and can be used as a reference because they use the same API that script authors write tools in. Typical usage for scripts include: user interface, import/export, scene manipulation, automation, defining your own toolset and customization.
When developing your own scripts it may help to understand how Blender sets up its Python environment.
Many Python scripts come bundled with Blender and can be used as a reference
because they use the same API that script authors write tools in.
Typical usage for scripts include: user interface, import/export,
scene manipulation, automation, defining your own toolset and customization.
On startup blender scans the ``scripts/startup/`` directory for python modules and imports them. The exact location of this directory depends on your installation. `See the directory layout docs <http://wiki.blender.org/index.php/Doc:2.6/Manual/Introduction/Installing_Blender/DirectoryLayout>`_
On startup Blender scans the ``scripts/startup/`` directory for Python modules and imports them.
The exact location of this directory depends on your installation.
This may seem obvious but it's important to note the difference between executing a script directly or importing it as a module.
This may seem obvious but it's important to note the difference
between executing a script directly or importing it as a module.
Scripts that extend blender - define classes that exist beyond the scripts execution, this makes future access to these classes (to unregister for example) more difficult than importing as a module where class instance is kept in the module and can be accessed by importing that module later on.
Scripts that extend Blender - define classes that exist beyond the scripts execution,
this makes future access to these classes (to unregister for example)
more difficult than importing as a module where class instance is kept
in the module and can be accessed by importing that module later on.
For this reason it's preferable to only use directly execute scripts that don't extend blender by registering classes.
For this reason it's preferable to only use directly execute scripts that don't extend Blender by registering classes.
Here are some ways to run scripts directly in blender.
Here are some ways to run scripts directly in Blender.
* Loaded in the text editor and press **Run Script**.
- Loaded in the text editor and press **Run Script**.
- Typed or pasted into the interactive console.
- Execute a Python file from the command line with Blender, eg:
* Typed or pasted into the interactive console.
..code-block::sh
* Execute a python file from the command line with blender, eg:
``blender --python /home/me/my_script.py``
blender --python /home/me/my_script.py
To run as modules:
* The obvious way, ``import some_module`` command from the text window or interactive console.
* Open as a text block and tick "Register" option, this will load with the blend file.
* copy into one of the directories ``scripts/startup``, where they will be automatically imported on startup.
* define as an addon, enabling the addon will load it as a python module.
- The obvious way, ``import some_module`` command from the text window or interactive console.
- Open as a text block and tick "Register" option, this will load with the blend file.
- copy into one of the directories ``scripts/startup``, where they will be automatically imported on startup.
- define as an addon, enabling the addon will load it as a Python module.
Addons
------
Some of blenders functionality is best kept optional, alongside scripts loaded at startup we have addons which are kept in their own directory ``scripts/addons``, and only load on startup if selected from the user preferences.
Some of Blenders functionality is best kept optional,
alongside scripts loaded at startup we have addons which are kept in their own directory ``scripts/addons``,
and only load on startup if selected from the user preferences.
The only difference between addons and built-in python modules is that addons must contain a **bl_info** variable which blender uses to read metadata such as name, author, category and URL.
The only difference between addons and built-in Python modules is that addons must contain a ``bl_info``
variable which Blender uses to read metadata such as name, author, category and URL.
The user preferences addon listing uses **bl_info** to display information about each addon.
`See Addons <http://wiki.blender.org/index.php/Dev:2.5/Py/Scripts/Guidelines/Addons>`_ for details on the **bl_info** dictionary.
Running python scripts in the text editor is useful for testing but you’ll want to extend blender to make tools accessible like other built-in functionality.
Running Python scripts in the text editor is useful for testing but you'll
want to extend Blender to make tools accessible like other built-in functionality.
The blender python api allows integration for:
The Blender Python api allows integration for:
*:class:`bpy.types.Panel`
*:class:`bpy.types.Menu`
*:class:`bpy.types.Operator`
*:class:`bpy.types.PropertyGroup`
*:class:`bpy.types.KeyingSet`
*:class:`bpy.types.RenderEngine`
-:class:`bpy.types.Panel`
-:class:`bpy.types.Menu`
-:class:`bpy.types.Operator`
-:class:`bpy.types.PropertyGroup`
-:class:`bpy.types.KeyingSet`
-:class:`bpy.types.RenderEngine`
This is intentionally limited. Currently, for more advanced features such as mesh modifiers, object types, or shader nodes, C/C++ must be used.
This is intentionally limited. Currently, for more advanced features such as mesh modifiers,
object types, or shader nodes, C/C++ must be used.
For python intergration Blender defines methods which are common to all types. This works by creating a python subclass of a Blender class which contains variables and functions specified by the parent class which are pre-defined to interface with Blender.
For Python integration Blender defines methods which are common to all types.
This works by creating a Python subclass of a Blender class which contains variables and functions
specified by the parent class which are pre-defined to interface with Blender.
For example:
@@ -115,15 +134,20 @@ For example:
bpy.utils.register_class(SimpleOperator)
First note that we subclass a member of :mod:`bpy.types`, this is common for all classes which can be integrated with blender and used so we know if this is an Operator and not a Panel when registering.
First note that we subclass a member of :mod:`bpy.types`,
this is common for all classes which can be integrated with Blender and
used so we know if this is an Operator and not a Panel when registering.
Both class properties start with a **bl_** prefix. This is a convention used to distinguish blender properties from those you add yourself.
Both class properties start with a ``bl_`` prefix.
This is a convention used to distinguish Blender properties from those you add yourself.
Next see the execute function, which takes an instance of the operator and the current context. A common prefix is not used for functions.
Next see the execute function, which takes an instance of the operator and the current context.
A common prefix is not used for functions.
Lastly the register function is called, this takes the class and loads it into blender. See `Class Registration`_.
Lastly the register function is called, this takes the class and loads it into Blender. See `Class Registration`_.
Regarding inheritance, blender doesn't impose restrictions on the kinds of class inheritance used, the registration checks will use attributes and functions defined in parent classes.
Regarding inheritance, Blender doesn't impose restrictions on the kinds of class inheritance used,
the registration checks will use attributes and functions defined in parent classes.
class mix-in example:
@@ -141,11 +165,20 @@ class mix-in example:
bpy.utils.register_class(SimpleOperator)
Notice these classes don't define an ``__init__(self)`` function. While ``__init__()`` and ``__del__()`` will be called if defined, the class instances lifetime only spans the execution. So a panel for example will have a new instance for every redraw, for this reason there is rarely a cause to store variables in the panel instance. Instead, persistent variables should be stored in Blenders data so that the state can be restored when blender is restarted.
Notice these classes don't define an ``__init__(self)`` function.
While ``__init__()`` and ``__del__()`` will be called if defined,
the class instances lifetime only spans the execution.
So a panel for example will have a new instance for every redraw,
for this reason there is rarely a cause to store variables in the panel instance.
Instead, persistent variables should be stored in Blenders
ata so that the state can be restored when Blender is restarted.
..note:: Modal operators are an exception, keeping their instance variable as blender runs, see modal operator template.
..note::
So once the class is registered with blender, instancing the class and calling the functions is left up to blender. In fact you cannot instance these classes from the script as you would expect with most python API's.
Modal operators are an exception, keeping their instance variable as Blender runs, see modal operator template.
So once the class is registered with Blender, instancing the class and calling the functions is left up to Blender.
In fact you cannot instance these classes from the script as you would expect with most Python API's.
To run operators you can call them through the operator api, eg:
@@ -154,7 +187,8 @@ To run operators you can call them through the operator api, eg:
importbpy
bpy.ops.object.simple_operator()
User interface classes are given a context in which to draw, buttons window, file header, toolbar etc, then they are drawn when that area is displayed so they are never called by python scripts directly.
User interface classes are given a context in which to draw, buttons window, file header, toolbar etc,
then they are drawn when that area is displayed so they are never called by Python scripts directly.
Registration
@@ -164,9 +198,10 @@ Registration
Module Registration
-------------------
Blender modules loaded at startup require ``register()`` and ``unregister()`` functions. These are the *only* functions that blender calls from your code, which is otherwise a regular python module.
Blender modules loaded at startup require ``register()`` and ``unregister()`` functions.
These are the *only* functions that Blender calls from your code, which is otherwise a regular Python module.
A simple blender/python module can look like this:
A simple Blender/Python module can look like this:
..code-block::python
@@ -184,12 +219,16 @@ A simple blender/python module can look like this:
if__name__=="__main__":
register()
These functions usually appear at the bottom of the script containing class registration sometimes adding menu items. You can also use them for internal purposes setting up data for your own tools but take care since register won't re-run when a new blend file is loaded.
These functions usually appear at the bottom of the script containing class registration sometimes adding menu items.
You can also use them for internal purposes setting up data for your own tools but take care
since register won't re-run when a new blend file is loaded.
The register/unregister calls are used so it's possible to toggle addons and reload scripts while blender runs.
If the register calls were placed in the body of the script, registration would be called on import, meaning there would be no distinction between importing a module or loading its classes into blender.
The register/unregister calls are used so it's possible to toggle addons and reload scripts while Blender runs.
If the register calls were placed in the body of the script, registration would be called on import,
meaning there would be no distinction between importing a module or loading its classes into Blender.
This becomes problematic when a script imports classes from another module making it difficult to manage which classes are being loaded and when.
This becomes problematic when a script imports classes from another module
making it difficult to manage which classes are being loaded and when.
The last 2 lines are only for testing:
@@ -199,19 +238,24 @@ The last 2 lines are only for testing:
register()
This allows the script to be run directly in the text editor to test changes.
This ``register()`` call won't run when the script is imported as a module since ``__main__`` is reserved for direct execution.
This ``register()`` call won't run when the script is imported as a module
since ``__main__`` is reserved for direct execution.
Class Registration
------------------
Registering a class with blender results in the class definition being loaded into blender, where it becomes available alongside existing functionality.
Registering a class with Blender results in the class definition being loaded into Blender,
where it becomes available alongside existing functionality.
Once this class is loaded you can access it from :mod:`bpy.types`, using the bl_idname rather than the classes original name.
Once this class is loaded you can access it from :mod:`bpy.types`,
using the bl_idname rather than the classes original name.
When loading a class, blender performs sanity checks making sure all required properties and functions are found, that properties have the correct type, and that functions have the right number of arguments.
When loading a class, Blender performs sanity checks making sure all required properties and functions are found,
that properties have the correct type, and that functions have the right number of arguments.
Mostly you will not need concern yourself with this but if there is a problem with the class definition it will be raised on registering:
Mostly you will not need concern yourself with this but if there is a problem
with the class definition it will be raised on registering:
Using the function arguments ``def execute(self, context, spam)``, will raise an exception:
@@ -225,9 +269,13 @@ Using ``bl_idname = 1`` will raise.
Multiple-Classes
^^^^^^^^^^^^^^^^
Loading classes into blender is described above, for simple cases calling :mod:`bpy.utils.register_class` (SomeClass) is sufficient, but when there are many classes or a packages submodule has its own classes it can be tedious to list them all for registration.
Loading classes into Blender is described above,
for simple cases calling :mod:`bpy.utils.register_class` (SomeClass) is sufficient,
but when there are many classes or a packages submodule has its own
classes it can be tedious to list them all for registration.
For more convenient loading/unloading :mod:`bpy.utils.register_module` (module) and :mod:`bpy.utils.unregister_module` (module) functions exist.
For more convenient loading/unloading :mod:`bpy.utils.register_module` (module)
and :mod:`bpy.utils.unregister_module` (module) functions exist.
A script which defines many of its own operators, panels menus etc. you only need to write:
@@ -239,13 +287,19 @@ A script which defines many of its own operators, panels menus etc. you only nee
defunregister():
bpy.utils.unregister_module(__name__)
Internally blender collects subclasses on registrable types, storing them by the module in which they are defined. By passing the module name to :mod:`bpy.utils.register_module` blender can register all classes created by this module and its submodules.
Internally Blender collects subclasses on registrable types, storing them by the module in which they are defined.
By passing the module name to :mod:`bpy.utils.register_module`
Blender can register all classes created by this module and its submodules.
Inter Classes Dependencies
^^^^^^^^^^^^^^^^^^^^^^^^^^
When customizing blender you may want to group your own settings together, after all, they will likely have to co-exist with other scripts. To group these properties classes need to be defined, for groups within groups or collections within groups you can find yourself having to deal with order of registration/unregistration.
When customizing Blender you may want to group your own settings together,
after all, they will likely have to co-exist with other scripts.
To group these properties classes need to be defined,
for groups within groups or collections within groups
you can find yourself having to deal with order of registration/unregistration.
Custom properties groups are themselves classes which need to be registered.
@@ -311,7 +365,9 @@ Say you want to store material settings for a custom engine.
Manipulating Classes
^^^^^^^^^^^^^^^^^^^^
Properties can be added and removed as blender runs, normally happens on register or unregister but for some special cases it may be useful to modify types as the script runs.
Properties can be added and removed as Blender runs,
normally happens on register or unregister but for some
special cases it may be useful to modify types as the script runs.
For example:
@@ -341,7 +397,8 @@ This works just as well for PropertyGroup subclasses you define yourself.
Dynamic Defined-Classes (Advanced)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In some cases the specifier for data may not be in blender, renderman shader definitions for example and it may be useful to define types and remove them on the fly.
In some cases the specifier for data may not be in Blender,
renderman shader definitions for example and it may be useful to define types and remove them on the fly.
..code-block::python
@@ -360,7 +417,8 @@ In some cases the specifier for data may not be in blender, renderman shader def
..note::
Notice ``type()`` is called to define the class. This is an alternative syntax for class creation in python, better suited to constructing classes dynamically.
``type()`` is called to define the class.
This is an alternative syntax for class creation in Python, better suited to constructing classes dynamically.
@@ -32,13 +33,15 @@ The Blender/Python API **can't** (yet)...
Before Starting
===============
This document isn't intended to fully cover each topic. Rather, its purpose is to familiarize you with Blender Python API.
This document isn't intended to fully cover each topic.
Rather, its purpose is to familiarize you with Blender Python API.
A quick list of helpful things to know before starting:
- Blender uses Python 3.x; some online documentation still assumes 2.x.
- The interactive console is great for testing one-liners, It also has autocompletion so you can inspect the API quickly.
- The interactive console is great for testing one-liners.
It also has autocompletion so you can inspect the API quickly.
- Button tool tips show Python attributes and operator names.
- Right clicking on buttons and menu items directly links to API documentation.
- For more examples, the text menu has a templates section where some example operators can be found.
@@ -51,15 +54,19 @@ A quick list of helpful things to know before starting:
Running Scripts
---------------
The two most common ways to execute Python scripts are using the built-in text editor or entering commands in the Python console.
The two most common ways to execute Python scripts are using the built-in
text editor or entering commands in the Python console.
Both the **Text Editor** and **Python Console** are space types you can select from the view header.
Both the *Text Editor* and *Python Console* are space types you can select from the view header.
Rather then manually configuring your spaces for Python development, you may prefer to use the **Scripting** screen, included default with Blender, accessible from the top headers screen selector.
Rather than manually configuring your spaces for Python development,
you may prefer to use the *Scripting* screen, included default with Blender,
accessible from the top headers screen selector.
From the text editor you can open ``.py`` files or paste then from the clipboard, then test using **Run Script**.
From the text editor you can open ``.py`` files or paste then from the clipboard, then test using *Run Script*.
The Python Console is typically used for typing in snippets and for testing to get immediate feedback, but can also have entire scripts pasted into it.
The Python Console is typically used for typing in snippets and for testing to get immediate feedback,
but can also have entire scripts pasted into it.
Scripts can also run from the command line with Blender but to learn Blender/Python this isn't essential.
@@ -73,9 +80,11 @@ Data Access
Accessing DataBlocks
^^^^^^^^^^^^^^^^^^^^
Python accesses Blender's data in the same way as the animation system and user interface; this implies that any setting that can be changed via a button can also be changed from Python.
Python accesses Blender's data in the same way as the animation system and user interface;
this implies that any setting that can be changed via a button can also be changed from Python.
Accessing data from the currently loaded blend file is done with the module :mod:`bpy.data`. This gives access to library data. For example:
Accessing data from the currently loaded blend file is done with the module :mod:`bpy.data`.
This gives access to library data. For example:
>>> bpy.data.objects
<bpy_collection[3], BlendDataObjects>
@@ -92,7 +101,8 @@ About Collections
You'll notice that an index as well as a string can be used to access members of the collection.
Unlike Python's dictionaries, both methods are acceptable; however, the index of a member may change while running Blender.
Unlike Python's dictionaries, both methods are acceptable;
however, the index of a member may change while running Blender.
@@ -107,7 +117,10 @@ Unlike Python's dictionaries, both methods are acceptable; however, the index of
Accessing Attributes
^^^^^^^^^^^^^^^^^^^^
Once you have a data block, such as a material, object, groups etc., its attributes can be accessed much like you would change a setting using the graphical interface. In fact, the tooltip for each button also displays the Python attribute which can help in finding what settings to change in a script.
Once you have a data block, such as a material, object, groups etc.,
its attributes can be accessed much like you would change a setting using the graphical interface.
In fact, the tooltip for each button also displays the Python attribute
which can help in finding what settings to change in a script.
>>> bpy.data.objects[0].name
'Camera'
@@ -119,7 +132,8 @@ Once you have a data block, such as a material, object, groups etc., its attribu
bpy.data.materials['MyMaterial']
For testing what data to access it's useful to use the "Console", which is its own space type. This supports auto-complete, giving you a fast way to dig into different data in your file.
For testing what data to access it's useful to use the "Console", which is its own space type.
This supports auto-complete, giving you a fast way to dig into different data in your file.
Example of a data path that can be quickly found via the console:
@@ -132,7 +146,8 @@ Example of a data path that can be quickly found via the console:
Data Creation/Removal
^^^^^^^^^^^^^^^^^^^^^
Those of you familiar with other Python API's may be surprised that new datablocks in the bpy API can't be created by calling the class:
Those of you familiar with other Python API's may be surprised that
new datablocks in the bpy API can't be created by calling the class:
>>> bpy.types.Mesh()
Traceback (most recent call last):
@@ -141,7 +156,8 @@ Those of you familiar with other Python API's may be surprised that new databloc
This is an intentional part of the API design.
The Blender/Python API can't create Blender data that exists outside the main Blender database (accessed through :mod:`bpy.data`), because this data is managed by Blender (save/load/undo/append... etc).
The Blender/Python API can't create Blender data that exists outside the main Blender database
(accessed through :mod:`bpy.data`), because this data is managed by Blender (save/load/undo/append... etc).
Data is added and removed via methods on the collections in :mod:`bpy.data`, eg:
@@ -155,8 +171,10 @@ Data is added and removed via methods on the collections in :mod:`bpy.data`, eg:
Custom Properties
^^^^^^^^^^^^^^^^^
Python can access properties on any datablock that has an ID (data that can be linked in and accessed from :mod:`bpy.data`.
When assigning a property, you can make up your own names, these will be created when needed or overwritten if they exist.
Python can access properties on any datablock that has an ID
(data that can be linked in and accessed from :mod:`bpy.data`.
When assigning a property, you can make up your own names,
these will be created when needed or overwritten if they exist.
This data is saved with the blend file and copied with objects.
@@ -192,8 +210,10 @@ These properties are valid outside of Python. They can be animated by curves or
Context
-------
While it's useful to be able to access data directly by name or as a list, it's more common to operate on the user's selection.
The context is always available from ``bpy.context`` and can be used to get the active object, scene, tool settings along with many other attributes.
While it's useful to be able to access data directly by name or as a list,
it's more common to operate on the user's selection.
The context is always available from ``bpy.context`` and can be used to get the active object, scene,
tool settings along with many other attributes.
Common-use cases:
@@ -201,7 +221,9 @@ Common-use cases:
>>> bpy.context.selected_objects
>>> bpy.context.visible_bones
Note that the context is read-only. These values cannot be modified directly, though they may be changed by running API functions or by using the data API.
Note that the context is read-only.
These values cannot be modified directly,
though they may be changed by running API functions or by using the data API.
So ``bpy.context.object = obj`` will raise an error.
@@ -209,7 +231,8 @@ But ``bpy.context.scene.objects.active = obj`` will work as expected.
The context attributes change depending on where they are accessed.
The 3D view has different context members than the console, so take care when accessing context attributes that the user state is known.
The 3D view has different context members than the console,
so take care when accessing context attributes that the user state is known.
See :mod:`bpy.context` API reference.
@@ -217,7 +240,9 @@ See :mod:`bpy.context` API reference.
Operators (Tools)
-----------------
Operators are tools generally accessed by the user from buttons, menu items or key shortcuts. From the user perspective they are a tool but Python can run these with its own settings through the :mod:`bpy.ops` module.
Operators are tools generally accessed by the user from buttons, menu items or key shortcuts.
From the user perspective they are a tool but Python can run these with its own settings
through the :mod:`bpy.ops` module.
Examples:
@@ -230,14 +255,16 @@ Examples:
..note::
The menu item: :menuselection:`Help --> Operator Cheat Sheet` gives a list of all operators and their default values in Python syntax, along with the generated docs.
The menu item: :menuselection:`Help --> Operator Cheat Sheet`
gives a list of all operators and their default values in Python syntax, along with the generated docs.
This is a good way to get an overview of all Blender's operators.
Operator Poll()
^^^^^^^^^^^^^^^
Many operators have a "poll" function which may check that the mouse is in a valid area or that the object is in the correct mode (Edit Mode, Weight Paint etc).
Many operators have a "poll" function which may check that the cursor
is in a valid area or that the object is in the correct mode (Edit Mode, Weight Paint etc).
When an operator's poll function fails within Python, an exception is raised.
For example, calling ``bpy.ops.view3d.render_border()`` from the console raises the following error:
@@ -248,7 +275,8 @@ For example, calling ``bpy.ops.view3d.render_border()`` from the console raises
In this case the context must be the 3d view with an active camera.
To avoid using try/except clauses wherever operators are called you can call the operators own .poll() function to check if it can run in the current context.
To avoid using try/except clauses wherever operators are called you can call the operators
own ``poll()`` function to check if it can run in the current context.
@@ -334,7 +367,8 @@ Blender's Python API can be split up into 3 categories.
Native Types
------------
In simple cases returning a number or a string as a custom type would be cumbersome, so these are accessed as normal Python types.
In simple cases returning a number or a string as a custom type would be cumbersome,
so these are accessed as normal Python types.
- Blender float/int/boolean -> float/int/boolean
- Blender enumerator -> string
@@ -359,7 +393,8 @@ Used for Blender datablocks and collections: :class:`bpy.types.bpy_struct`
For data that contains its own attributes groups/meshes/bones/scenes... etc.
There are 2 main types that wrap Blenders data, one for datablocks (known internally as ``bpy_struct``), another for properties.
There are 2 main types that wrap Blenders data, one for datablocks
(known internally as ``bpy_struct``), another for properties.
>>> bpy.context.object
bpy.data.objects['Cube']
@@ -375,7 +410,9 @@ Mathutils Types
Used for vectors, quaternion, eulers, matrix and color types, accessible from :mod:`mathutils`
Some attributes such as :class:`bpy.types.Object.location`,:class:`bpy.types.PoseBone.rotation_euler` and :class:`bpy.types.Scene.cursor_location` can be accessed as special math types which can be used together and manipulated in various useful ways.
Some attributes such as :class:`bpy.types.Object.location`,
:class:`bpy.types.PoseBone.rotation_euler` and :class:`bpy.types.Scene.cursor_location`
can be accessed as special math types which can be used together and manipulated in various useful ways.
Example of a matrix, vector multiplication:
@@ -410,7 +447,9 @@ Animation
There are 2 ways to add keyframes through Python.
The first is through key properties directly, which is similar to inserting a keyframe from the button as a user. You can also manually create the curves and keyframe data, then set the path to the property. Here are examples of both methods.
The first is through key properties directly, which is similar to inserting a keyframe from the button as a user.
You can also manually create the curves and keyframe data, then set the path to the property.
Here are examples of both methods.
Both examples insert a keyframe on the active object's Z axis.
Here are various suggestions that you might find useful when writing scripts.
Some of these are just python features that scripters may not have thought to use with blender, others are blender specific.
Some of these are just Python features that scripters may not have thought to use with Blender,
others are Blender specific.
.._use_the_terminal:
@@ -12,18 +14,21 @@ Some of these are just python features that scripters may not have thought to us
Use The Terminal
================
When writing python scripts, it's useful to have a terminal open, this is not the built-in python console but a terminal application which is used to start blender.
When writing Python scripts, it's useful to have a terminal open,
this is not the built-in Python console but a terminal application which is used to start Blender.
There are 3 main uses for the terminal, these are:
* You can see the output of ``print()`` as your script runs, which is useful to view debug info.
* The error trace-back is printed in full to the terminal which won't always generate an error popup in blender's user interface (depending on how the script is executed).
* If the script runs for too long or you accidentally enter an infinite loop, Ctrl+C in the terminal (Ctrl+Break on Windows) will quit the script early.
- You can see the output of ``print()`` as your script runs, which is useful to view debug info.
- The error trace-back is printed in full to the terminal which won't always generate an error popup in
Blender's user interface (depending on how the script is executed).
- If the script runs for too long or you accidentally enter an infinite loop,
:kbd:`Ctrl-C` in the terminal (:kbd:`Ctrl-Break` on Windows) will quit the script early.
..note::
For Linux and OSX users this means starting the terminal first, then running blender from within it. On Windows the terminal can be enabled from the help menu.
For Linux and OSX users this means starting the terminal first, then running Blender from within it.
On Windows the terminal can be enabled from the help menu.
Interface Tricks
@@ -33,43 +38,56 @@ Interface Tricks
Access Operator Commands
------------------------
You may have noticed that the tooltip for menu items and buttons includes the ``bpy.ops``... command to run that button, a handy (hidden) feature is that you can press Ctrl+C over any menu item/button to copy this command into the clipboard.
You may have noticed that the tooltip for menu items and buttons includes the ``bpy.ops.[...])`` command
to run that button, a handy (hidden) feature is that you can press :kbd:`Ctrl-C` over
any menu item/button to copy this command into the clipboard.
Access Data Path
----------------
To find the path from an :class:`ID` datablock to its setting isn't always so simple since it may be nested away. To get this quickly you can right click on the setting and select select **Copy Data Path**,
To find the path from an :class:`ID` datablock to its setting isn't always so simple since it may be nested away.
To get this quickly you can right click on the setting and select select **Copy Data Path**,
if this can't be generated, only the property name is copied.
..note::
This uses the same method for creating the animation path used by:class:`bpy.types.FCurve.data_path` and :class:`bpy.types.DriverTarget.data_path` drivers.
This uses the same method for creating the animation path used by
While blender logs operators in the Info space, this only reports operators with the ``REGISTER`` option enabeld so as not to flood the Info view with calls to ``bpy.ops.view3d.smoothview`` and ``bpy.ops.view3d.zoom``.
While Blender logs operators in the Info space,
this only reports operators with the ``REGISTER`` option enabeld so as not to flood the *Info* view
with calls to ``bpy.ops.view3d.smoothview`` and ``bpy.ops.view3d.zoom``.
However, for testing it can be useful to see **every** operator called in a terminal, do this by enabling the debug option either by passing the ``--debug-wm`` argument when starting blender or by setting :mod:`bpy.app.debug_wm` to True while blender is running.
However, for testing it can be useful to see **every** operator called in a terminal,
do this by enabling the debug option either by passing the ``--debug-wm`` argument when starting Blender
or by setting :mod:`bpy.app.debug_wm` to ``True`` while Blender is running.
Use an External Editor
======================
Blenders text editor is fine for small changes and writing tests but its not full featured, for larger projects you'll probably want to use a standalone editor or python IDE.
Blenders text editor is fine for small changes and writing tests but its not full featured,
for larger projects you'll probably want to use a standalone editor or Python IDE.
Editing a text file externally and having the same text open in blender does work but isn't that optimal so here are 2 ways you can easily use an external file from blender.
Editing a text file externally and having the same text open in Blender does work but isn't that optimal
so here are 2 ways you can easily use an external file from Blender.
Using the following examples you'll still need textblock in Blender to execute,
but reference an external file rather than including it directly.
Using the following examples you'll still need textblock in blender to execute, but reference an external file rather then including it directly.
Executing External Scripts
--------------------------
This is the equivalent to running the script directly, referencing a scripts path from a 2 line textblock.
This is the equivalent to running the script directly, referencing a scripts path from a 2 line text-block.
..code-block::python
@@ -102,12 +120,17 @@ This example shows loading a script in as a module and executing a module functi
myscript.main()
Notice that the script is reloaded every time, this forces use of the modified version, otherwise the cached one in ``sys.modules`` would be used until blender was restarted.
Notice that the script is reloaded every time, this forces use of the modified version,
otherwise the cached one in ``sys.modules`` would be used until Blender was restarted.
The important difference between this and executing the script directly is it has to call a function in the module, in this case ``main()`` but it can be any function, an advantage with this is you can pass arguments to the function from this small script which is often useful for testing different settings quickly.
The important difference between this and executing the script directly is it
has to call a function in the module, in this case ``main()`` but it can be any function,
an advantage with this is you can pass arguments to the function from this
small script which is often useful for testing different settings quickly.
The other issue with this is the script has to be in pythons module search path.
While this is not best practice - for testing you can extend the search path, this example adds the current blend files directory to the search path, then loads the script as a module.
The other issue with this is the script has to be in Pythons module search path.
While this is not best practice - for testing you can extend the search path,
this example adds the current blend files directory to the search path, then loads the script as a module.
..code-block::python
@@ -128,71 +151,86 @@ While this is not best practice - for testing you can extend the search path, th
Don't Use Blender!
==================
While developing your own scripts blenders interface can get in the way, manually reloading, running the scripts, opening file import etc. adds overhead.
While developing your own scripts Blenders interface can get in the way,
manually reloading, running the scripts, opening file import etc. adds overhead.
For scripts that are not interactive it can end up being more efficient not to use blenders interface at all and instead execute the script on the command line.
For scripts that are not interactive it can end up being more efficient not to use
Blenders interface at all and instead execute the script on the command line.
..code-block::python
..code-block::sh
blender --background --python myscript.py
You might want to run this with a blend file so the script has some data to operate on.
Depending on your setup you might have to enter the full path to the blender executable.
Depending on your setup you might have to enter the full path to the Blender executable.
Once the script is running properly in background mode, you'll want to check the output of the script, this depends completely on the task at hand however here are some suggestions.
Once the script is running properly in background mode, you'll want to check the output of the script,
this depends completely on the task at hand however here are some suggestions.
* render the output to an image, use an image viewer and keep writing over the same image each time.
* save a new blend file, or export the file using one of blenders exporters.
* if the results can be displayed as text - print them or write them to a file.
- render the output to an image, use an image viewer and keep writing over the same image each time.
- save a new blend file, or export the file using one of Blenders exporters.
- if the results can be displayed as text - print them or write them to a file.
This can take a little time to setup, but it can be well worth the effort to reduce the time it takes to test changes - you can even have blender running the script ever few seconds with a viewer updating the results, so no need to leave your text editor to see changes.
While this can take a little time to setup, it can be well worth the effort
to reduce the time it takes to test changes - you can even have
Blender running the script every few seconds with a viewer updating the results,
so no need to leave your text editor to see changes.
Use External Tools
==================
When there are no readily available python modules to perform specific tasks it's worth keeping in mind you may be able to have python execute an external command on your data and read the result back in.
When there are no readily available Python modules to perform specific tasks it's
worth keeping in mind you may be able to have Python execute an external command
on your data and read the result back in.
Using external programs adds an extra dependency and may limit who can use the script but to quickly setup your own custom pipeline or writing one-off scripts this can be handy.
Using external programs adds an extra dependency and may limit who can use the script
but to quickly setup your own custom pipeline or writing one-off scripts this can be handy.
Examples include:
* Run The Gimp in batch mode to execute custom scripts for advanced image processing.
* Write out 3D models to use external mesh manipulation tools and read back in the results.
* Convert files into recognizable formats before reading.
- Run The Gimp in batch mode to execute custom scripts for advanced image processing.
- Write out 3D models to use external mesh manipulation tools and read back in the results.
- Convert files into recognizable formats before reading.
Bundled Python & Extensions
===========================
The Blender releases distributed from blender.org include a complete python installation on all platforms, this has the disadvantage that any extensions you have installed in your systems python wont be found by blender.
The Blender releases distributed from blender.org include a complete Python installation on all platforms,
this has the disadvantage that any extensions you have installed in your systems Python wont be found by Blender.
There are 2 ways around this:
* remove blender python sub-directory, blender will then fallback on the systems python and use that instead**python version must match the one that blender comes with**.
- remove Blender Python sub-directory, Blender will then fallback on the systems Python and use that instead
..warning::
* copy the extensions into blender's python sub-directory so blender can access them, you could also copy the entire python installation into blenders sub-directory, replacing the one blender comes with. This works as long as the python versions match and the paths are created in the same relative locations. Doing this has the advantage that you can redistribute this bundle to others with blender and/or the game player, including any extensions you rely on.
The Python version must match the one that Blender comes with.
- copy the extensions into Blender's Python sub-directory so Blender can access them,
you could also copy the entire Python installation into Blenders sub-directory,
replacing the one Blender comes with.
This works as long as the Python versions match and the paths are created in the same relative locations.
Doing this has the advantage that you can redistribute this bundle to others with Blender and/or the game player,
including any extensions you rely on.
Drop Into a Python Interpreter in Your Script
=============================================
In the middle of a script you may want to inspect some variables, run some function and generally dig about to see whats going on.
In the middle of a script you may want to inspect some variables,
run some function and generally dig about to see whats going on.
..code-block::python
@@ -217,10 +255,13 @@ The next example is an equivalent single line version of the script above which
``code.interact`` can be added at any line in the script and will pause the script an launch an interactive interpreter in the terminal, when you're done you can quit the interpreter and the script will continue execution.
``code.interact`` can be added at any line in the script
and will pause the script an launch an interactive interpreter in the terminal,
when you're done you can quit the interpreter and the script will continue execution.
If you have **IPython** installed you can use their``embed()`` function which will implicitly use the current namespace, this has autocomplete and some useful features that the standard python eval-loop doesn't have.
If you have **IPython** installed you can use its``embed()`` function which uses the current namespace.
The IPython prompt has auto-complete and some useful features that the standard Python eval-loop doesn't have.
..code-block::python
@@ -228,7 +269,7 @@ If you have **IPython** installed you can use their ``embed()`` function which w
IPython.embed()
Admittedly this highlights the lack of any python debugging support built into blender, but its still handy to know.
Admittedly this highlights the lack of any Python debugging support built into Blender, but its still handy to know.
..note::
@@ -242,27 +283,32 @@ Advanced
Blender as a module
-------------------
From a python perspective it's nicer to have everything as an extension which lets the python script combine many components.
From a Python perspective it's nicer to have everything as an extension
which lets the Python script combine many components.
Advantages include:
* you can use external editors/IDE's with blenders python API and execute scripts within the IDE (step over code, inspect variables as the script runs).
* editors/IDE's can auto complete blender modules & variables.
* existing scripts can import blender API's without having to run inside blender.
- you can use external editors/IDE's with Blenders Python API and execute scripts within the IDE
(step over code, inspect variables as the script runs).
- editors/IDE's can auto complete Blender modules & variables.
- existing scripts can import Blender API's without having to run inside Blender.
This is marked advanced because to run blender as a python module requires a special build option.
This is marked advanced because to run Blender as a Python module requires a special build option.
For instructions on building see`Building blender as a python module <http://wiki.blender.org/index.php/User:Ideasman42/BlenderAsPyModule>`_
For instructions on building see
`Building Blender as a Python module <http://wiki.blender.org/index.php/User:Ideasman42/BlenderAsPyModule>`_
Python Safety (Build Option)
----------------------------
Since it's possible to access data which has been removed (see Gotcha's), this can be hard to track down the cause of crashes.
Since it's possible to access data which has been removed (see Gotcha's),
this can be hard to track down the cause of crashes.
To raise python exceptions on accessing freed data (rather then crashing), enable the CMake build option WITH_PYTHON_SAFETY.
To raise Python exceptions on accessing freed data (rather than crashing),
enable the CMake build option WITH_PYTHON_SAFETY.
This enables data tracking which makes data access about 2x slower
which is why the option isn't enabled in release builds.
This enables data tracking which makes data access about 2x slower which is why the option is not enabled in release builds.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
