we cant ensure that a requested buffer can be allocated so report opengl errors when failing to allocate the buffer (rather then printing to console).
this is common enough and generic error isn't too helpful to users.
Sketching Sessions.
Fix for secondary issue noted in this bug report. Some of the code for
the fancy 3d view sketching options needed to be moved around so that
there is a clearer "paint/sketch session" and "stroke" separation
between various stages. There's still some more stuff that needs to be
done here before I think it's totally cleaned up.
Since 2.5x blender has been using CD_MASK_BAREMESH for updating objects since object_handle_update() no longer has access to G.curscreen to calculate the mask from viewports.
The problem with this is after an initial calculation, CD_MASK_MTFACE may be required on draw, so it would recalculate the modifier stack multiple times per frame.
One case which caused this is armature animated mesh with texface in a dupligroup.
Fix this by having customdata_mask member in the scene, this isn't great design but at least fixes the bug and only changes a few files.
- glReadPixels() was running to get the depth on each pixel, this works fine one some cards but was locking up on OSX.
- Replace glReadPixels() call with a single call to view3d_update_depths() right after view3d_validate_backbuf(), so the depths are only read once.
- Unrelated to the changes above, but should improve performance: view3d_validate_backbuf() was being called on every redraw while combing, now only call once when combing starts.
- Home or Numpad Period with smoothview disabled were not syncing up the other views.
- Disabling clip only disabled clip syncing but left clip enabled for all views.
- Clip was being calculated for every update even when not enabled.
- The perspective view was being used to copy settings from when changing box & clip settings, resetting the distance each time. Now use one of the aligned views instead.
The problem is the opensource nvidia nouveau drivers are slow running glReadPixels(), was hanging on memcpy().
However for autodepth its not needed to update the entire 3D view depths, so added view3d_update_depths_rect() to get the depths for a smaller area.
also made drawing in camera view stick to the camera border (belated durian request),
useful for animation review without worrying about screensize moving the overlay about.
Setting the 3d cursor in perspective mode would keep the cursor behind the viewport,
now check if the cursor is begind the viewport and use the orbit location to set the cursor depth rather then the existing plane.
unrelated changes that ended up being more trouble to commit separate...
- removed BLI_split_dirfile(), was nasty, occasionaly modifying the source string, it could create directories and used the $CWD in some cases. was only used in 2 places in filesel.c, if this gives problems can address without bringing back this function.
renamed BLI_split_dirfile_basic --> BLI_split_dirfile
- view3d_operator_needs_opengl was being called for offscreen render when it wasnt needed.
- new mode for projecting an image with the view matrix saved in the image id-properties rather then using the camera matrix.
- operator to screenshot the view and create a new image with the view matrix stored in the image.
these will be used for better re-project integration and are not immediately very useful.
Blender too now! :)
** Drag works as follows:
- drag-able items are defined by the standard interface ui toolkit
- each button can get this feature, via uiButSetDragXXX(but, ...).
There are calls to define drag-able images, ID blocks, RNA paths,
file paths, and so on. By default you drag an icon, exceptionally
an ImBuf
- Drag items are registered centrally in the WM, it allows more drag
items simultaneous too, but not implemented
** Drop works as follows:
- On mouse release, and if drag items exist in the WM, it converts
the mouse event to an EVT_DROP type. This event then gets the full
drag info as customdata
- drop regions are defined with WM_dropbox_add(), similar to keymaps
you can make a "drop map" this way, which become 'drop map handlers'
in the queues.
- next to that the UI kit handles some common button types (like
accepting ID or names) to be catching a drop event too.
- Every "drop box" has two callbacks:
- poll() = check if the event drag data is relevant for this box
- copy() = fill in custom properties in the dropbox to initialize
an operator
- The dropbox handler then calls its standard Operator with its
dropbox properties.
** Currently implemented
Drag items:
- ID icons in browse buttons
- ID icons in context menu of properties region
- ID icons in outliner and rna viewer
- FileBrowser icons
- FileBrowser preview images
Drag-able icons are subtly visualized by making them brighter a bit
on mouse-over. In case the icon is a button or UI element too (most
cases), the drag-able feature will make the item react to
mouse-release instead of mouse-press.
Drop options:
- UI buttons: ID and text buttons (paste name)
- View3d: Object ID drop copies object
- View3d: Material ID drop assigns to object under cursor
- View3d: Image ID drop assigns to object UV texture under cursor
- Sequencer: Path drop will add either Image or Movie strip
- Image window: Path drop will open image
** Drag and drop Notes:
- Dropping into another Blender window (from same application) works
too. I've added code that passes on mousemoves and clicks to other
windows, without activating them though. This does make using multi-window
Blender a bit friendler.
- Dropping a file path to an image, is not the same as dropping an
Image ID... keep this in mind. Sequencer for example wants paths to
be dropped, textures in 3d window wants an Image ID.
- Although drop boxes could be defined via Python, I suggest they're
part of the UI and editor design (= how we want an editor to work), and
not default offered configurable like keymaps.
- At the moment only one item can be dragged at a time. This is for
several reasons.... For one, Blender doesn't have a well defined
uniform way to define "what is selected" (files, outliner items, etc).
Secondly there's potential conflicts on what todo when you drop mixed
drag sets on spots. All undefined stuff... nice for later.
- Example to bypass the above: a collection of images that form a strip,
should be represented in filewindow as a single sequence anyway.
This then will fit well and gets handled neatly by design.
- Another option to check is to allow multiple options per drop... it
could show the operator as a sort of menu, allowing arrow or scrollwheel
to choose. For time being I'd prefer to try to design a singular drop
though, just offer only one drop action per data type on given spots.
- What does work already, but a tad slow, is to use a function that
detects an object (type) under cursor, so a drag item's option can be
further refined (like drop object on object = parent). (disabled)
** More notes
- Added saving for Region layouts (like split points for toolbar)
- Label buttons now handle mouse over
- File list: added full path entry for drop feature.
- Filesel bugfix: wm_operator_exec() got called there and fully handled,
while WM event code tried same. Added new OPERATOR_HANDLED flag for this.
Maybe python needs it too?
- Cocoa: added window move event, so multi-win setups work OK (didnt save).
- Interface_handlers.c: removed win->active
- Severe area copy bug: area handlers were not set to NULL
- Filesel bugfix: next/prev folder list was not copied on area copies
** Leftover todos
- Cocoa windows seem to hang on cases still... needs check
- Cocoa 'draw overlap' swap doesn't work
- Cocoa window loses focus permanently on using Spotlight
(for these reasons, makefile building has Carbon as default atm)
- ListView templates in UI cannot become dragged yet, needs review...
it consists of two overlapping UI elements, preventing handling icon clicks.
- There's already Ghost library code to handle dropping from OS
into Blender window. I've noticed this code is unfinished for Macs, but
seems to be complete for Windows. Needs test... currently, an external
drop event will print in console when succesfully delivered to Blender's WM.
- account for parts of the line going off into infinity by making the stroke stretch between the last valid depth values (like an elastic band), if the endpoints are not over any geometry then use the closest valid depth.
- retopo operator to convert grease pencil drawn topology into geometry, not in the convert menu yet since its not quite finished, use the operator search menu for retopo. will test this week and see what needs fixing.
- the clipping test function was using the rv3d->viewmatob where it needed to use the object matrix.
- added a local clipping member to rv3d, the clipping planes in object-space, avoids many matrix multiplications when testing verts or clipping pixels when projection painting.
I tried to make it integrate more with regular render but couldn't
do it well, it still needs a 3D view to take the settings from, and
can't run in a separate thread due to OpenGL.
However, it is now rendering to an offscreen buffer which then gets
displayed in the image window. This requires FBO's to be available, so
a fallback creating a new window is still needed. Currently available
from the Render menu in the top header.
This is similar to the old retopo all option but uses the snapping code and not the openGL depth buffer (it's thus more precise).
Not sure if making it available as a snap option is sensible, this is up for discussion.
NOTE: it will get slow fast on large meshes, we need to plug in an acceleration structure into snapping.
This will need an icon too.
Deal with this by adding ED_view3d_init_mats_rv3d(ob, r3d) which initialized the region mat's and is used in mesh_foreachScreenVert, mesh_foreachScreenEdge etc.
* Some initial work on a new paint abstraction, PaintStroke. For now, most of the code just pulls out stroke-related stuff from sculpt mode, next step is to integrate the other paint modes to use this. It'll enable stuff like smooth stroke for all the paint modes with less code duplication.
* Fixed one of the items from Brecht's TODO mail. Exiting edit mode now restores any paint mode you might have been in, rather than going to object mode.
Part one (of probably many :) of Operator review/validation.
Nothing final nor defined, it's reseach :)
- Added tool buttons in "Toolbar" (Tkey). Just four examples
for objectmode, and six for mesh editmode.
(Review in progress is operator internal state vs context, what
do redo exactly, undo vs redo syncing, when op->invoke or not,
etc. This has to be pinned down exactly and frozen asap)
- On undo, clear redo-operator-stack for now (won't work)
- Added call to better detect active/current view3d region.
ED_view3d_context_rv3d(C)
- Fixed some operators that missed correct redo (add-prim etc).
Later more fun!
