3) View3D buffer queries (depth buffer, normal buffer, selection buffer(s)...) from Python.
Depth buffer and color buffer are possible to get with bgl (the opengl wrapper). -- Dalai 2012/5/6 Dima Glibitsky <[email protected]> > This is the list of functionalities I often find myself wishing > Blender's Python side to have: > > > 1) Selection state of elements and active element of collections > > 1.a) bpy.types.MetaElement.select -- user can select/deselect > metaelements, but there's no way to get/set it from Python. > > 1.b) bpy.types.SplineBezierPoints.active, > bpy.types.SplinePoints.active -- likewise, Python scripts currently > can't get/set active spline point. > > To be more general, every selectable element should have a "select" > property, and every collection that can have active item, should have > an "active" property. > > 1.c) Also, it would be nice if every collection of selectable elements > had a "selected" iterator (and, perhaps, a "total_sel" int property) > -- when there are many items, but only few of them are selected, > scripts operating on selections could benefit from that substantially. > > > 2) User interface > > 2.a) An ability to set "emboss" property for all types of layout > elements, not just layout.prop() and layout.operator(). > > 2.b) An ability to specify icons for items in bpy.props.EnumProperty(). > E.g. as an optional fourth tuple element in items: > EnumProperty(items=[('VISIBLE', "Visible", "Apply to all visible > objects", 'RESTRICT_VIEW_OFF')]) > > 2.c) An ability to override tooltips for layout elements. I often > encounter situations when I can write a generic operator or a generic > property definition to use in many places, so having context-specific > tooltips would be quite helpful. > > 2.d) A way to specify operator properties for layout.operator_enum(), > layout.operator_menu_enum() and layout.menu(): > E.g. layout.operator_menu_enum(...) to return an OperatorProperties > object, which would set the corresponding properties for every > operator in the menu. > Also, I can think of another alternative: add an "operator_properties" > attribute to UILayout, so that all operators drawn within this layout > would "inherit" these properties. > > 2.e) Have an access to locale strings mapping -- this is useful for > localization-aware GL text drawing, composite texts/labels, etc. E.g. > WindowManager.translate(text, interface=True, tooltips=True) -- which > would return the translated (or not translated) string, depending on > use_international_fonts, use_translate_interface, > use_translate_tooltips. > > > 3) View3D buffer queries (depth buffer, normal buffer, selection > buffer(s)...) from Python. > This is useful for writing (or, at least, prototyping in Python) > interactive tools that heavily rely on what user can see and click at. > Raycasting becomes too expensive when you need to consider an area > rather than just one pixel under the mouse, plus it doesn't account > for non-raycastable things like edges, vertices, bones, etc. > The API might look like RegionView3D.query_renderbuffer(x, y, > buffer_type = enum in {'DEPTH', 'NORMAL', 'SELECTION', ...}) -- which > would return a float, Vector, some ID key or other data depending on > the nature of the buffer. > > > 4) bpy.app.handlers for Undo pushes and the Undo/Redo/History actions. > Some tools (such as macros recording or parametric modeling) require > to be aware of every single change that's happening to bpy.data, and, > as far as I know, Blender already stores the diff between the Undo > steps. > For example, bpy.app.handlers might have "undo_history_pre" and > "undo_history_post" lists; the corresponding callback might have > signature callback(diff_paths), where diff_paths is a list of property > paths that would change (or have been changed). > It's also important to have access to the list of Undo History entries > and the currently selected History entry -- e.g. > WindowManager.undo_history collection of UndoHistoryEntry objects; > UndoHistoryEntry might have attributes like "message" and > "diff(undo_history_entry)". > > > 5) UUID for each bpy_struct instance inside a .blend file (or, at > least, for PropertyGroups and objects inheriting from ID). UUIDs seems > to be a long- and much-requested feature that, unfortunately, also > seems to require a significant rewrite of Blender. Anyway, it would be > good to at least have this point explained in the documentation (e.g. > in API Overview or in Gotcha's), so that requests like this won't pop > up anymore. > > ------------------------ > dairin0d > _______________________________________________ > Bf-python mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-python >
_______________________________________________ Bf-python mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-python
