Casting a ray onto an editmesh was building a derivedMesh, raytree, then freeing for every ray-cast.
Noticed while using ruler+snapping in editmode.
Instead of attempting to align the MFace and edit-mesh tessfaces, just use editmesh for ray-casting.
Reverted the trunk revision 56136 and part of revision 56127 concerning the local Main
for Freestyle and temporary scene generation for stroke rendering.
The function do_merge_fullsample() in pipeline.c has access to the Scene of each Render,
so that the temporary Scene generated by Freestyle has to be kept for FSAA even after
stroke rendering has been done. By the same token, the local Main has been moved from
the BlenderStrokeRenderer class to Render. It is noted that free_all_freestyle_renders()
in pipeline.c is intended to get the temporary Scene of each Render released specifically
taking account of the FSAA case.
Add numpy installation to blender player configuration,
this is so because player is building first and it installs
python, which prevented numpy installation from blender
configuration.
- disabling ruler snap wasn't setting the points depth back to its previous value before snapping.
- adding a new ruler uses the depth of the previous active ruler (fallback to view center as before)
- deleting the ruler now sets the prev/next ruler active.
the operator the previous time. However for these menus it makes more sense to
always use edge/face bevel and to leave vertex bevel for Mesh > Vertex > Bevel.
- enable site-packages for bundled python distrobution, py3.2 had a problem where it would try to parse headers we didnt include, but its resolved now.
- workaround for glitch I was having on arch-linux where lib64 would be be used for the bundled python directory when it was just a symlink.
Changing actions via RNA (or apparently from the Action Editor browse menu too)
didn't perform all the necessary updates/tagging/recalc needed to have the
results of the new action get immediately applied in the 3D view. This caused
problems for exporters, as the first frames exported would be incorrect (though
this could probably be worked around by manually stepping the current frame
forward one frame then back again).
Allow separate control for tex/mask/cursor overlay. This commit implements
separate overlays for mask textures and cursor curves. The user can turn on
and off separate parts of the overlay by using the appropriate widgets.
The cursor overlay widgets are located at the tool selection panel
Also fixed alpha masks not getting correctly masked and mask texture mapping
not having the correct update callback
properties were continuously redrawing, which slowed down everything else.
The problem was integer overflow, with a short only capable of storing values
up to 32767. Note that sockets are collapsed by default since the previous
release, and that's it's not very useful to edit such complex node setups in
the properties editor, it's mainly meant for simple setups or group nodes to
present just a few sockets.
Two main things:
- Made a python operator for selection in a viewport
which will de-select everything if nothing is under
the mouse.
To do so needed to modify VIEW3D_OT_select, so invoke
sets mouse location which is later used by exec
function.
This way it's possible to select stuff from python
defined operator.
Not best-ever solution since ideally exec() shall not
do OpenGL stuff, but we've got this issue in some
other operators. We'll solve this later.
- Used a keymap from Gianmichele Mariani as a reference,
updated his keymap to latest changes in operators.
We shall match Maya keymap much better now, thanks
for the keymap dude!
and preview running at the same time.
It seems there's something in OSL/LLVM that's not thread safe, but I couldn't
figure out what exactly. Now all renders share the same OSL ShadingSystem which
should avoid the problem.
Most of the places which relied on RNA_path_resolve() did so believing that if
it returned true, that it had found a valid property, and that the returned
pointer+property combination would be what the path referred to. However, it
turns out that if the property at the end of the path turns out to be a
"pointer" property (e.g. "data" for Object.data), this would automatically
become the pointer part, while the prop part would be set to null. Hence, if a
user accidentally (or otherwise) specifies a path for the single-property driver
variable type like this, then Blender would crash.
This commit introduces two convenience functions - RNA_path_resolve_property()
and RNA_path_resolve_property_full() - which mirror/wrap the existing
RNA_path_resolve() functions. The only difference though is that these include a
check to ensure that what was found from resolving the path was in fact a
property (they only return true iff this is the case), and make it explicitly
clear in the name that this is what they will do so that there's no further
confusion. It is possible to do without these wrapper functions by doing these
checks inline, but the few cases that had been patched already were pretty
hideous looking specimens. Using these just make it clearer and simpler for all.
I've also beefed up the docs on these a bit, and changed these to using bools.
Displays such information as current frame dimension,
frame number within image sequence/movie and in case
of image sequence input displays current file name of
a frame.
Not entirely happy with such approach, but was requested
a lot by artists.
Issue was cause dby ima->ibufs being stored in a ma on
undo/redo and ima->rr not. In case of multilayer image
ibufs hares pointer with render result, so current
undo/redo policy lead to a dead pointer stored in ibuf.
Made it so ima->rr also stores in the map and restores
on redo/undo keeping all the pointers fine.
