vicrucann / cherish Goto Github PK

It is especially visible when performing operators such as pick, sketch, erase.

Some of the actions do not have corresponding icons, e.g., view modes. Also, it would be nice if the icon style is coherent, i.e., they are not taken from different sources, but rather from a single source; or they are designed specifically for the application.

It should be set to Qt::ArrowCursor when it is not on top of ViewWidget, and should be set to current action cursor back when it returns to the ViewWidget.

It happens when the closest photo does not belong to current canvas.

To resolve: have to use

iv.setTraversalMask(~0x1);

canvas->setNodeMask(0x1);

In this case, canvas will not be tracked. We have to only track current canvas.

The initial implementation of the stylus sketching is a simple line strip. Each stroke is represented by a set up points, and then it is rendered by using osg::PrimitiveSet::LINE_STRIP.

Under different style of the stroke it is meant:

• varying line width (brush size)
• varying brush type (e.g., pencil, charcoal, brush, etc.)
• varying color and transparency

Same as issue #1

Need to figure out what is the best way to deal with overlapping photos. There need to be a tool (or photo should posses a property) that would allow to send it to the back or to the front.

function _rootScene->loadPhotoFromFile() sometimes causes the program quit unexpectedly.

Stroke opacity decreases with increase of distance from current camera view.

Include this options:

• directional falloff threshold
• checkbox for vertical opacity

This could be done using photo-offset mode, but we indicate that we move strokes by pressing

Numerous glitches when running on Mac:

• The widget border is always set to the minimal size, even when the whole window is maximized; check the viewport set up of viewwidget.h
• Ray casting is offset; probably, due to the problems with the viewport

One of the probable causes and solutions: redesign of the ViewWidget so that:

• No composite viewer is used, but a single osgViewer::Viewer.
• Re-define initializeGL function and set up the OpenGL state there.
• Re-design onResize() method; it is a probable cause of the glitches. Transfer the viewport set up to the resizeGL() method.

Doxygen manual

1. It would be nice to be able to see the old location of the canvas vs. the new location of the canvas.
2. The normal should rather be displayed as an infinite (?) line so that the user could understand along what they drag the canvas
3. Indicate the direction of the normal, e.g., using arrow, or fill vs. dashed line

Current canvas:

• Frame line: color, width, opacity
• Inside quad: color, opacity

Previous canvas:

• Frame line: color, width, opacity
• Inside quad: color, opacity

For example, when clicked on photo that is within canvas, should that canvas get selected?

It would avoid adding almost dot-like strokes, or strokes that are too small to be visible.

The osg::StateSet options for smoothing don't seem to work on Linux, OpenGL 3.0. Probably, due to the OpenGL version. So, need to check.

Correct the default settings when doing _root->loadPhotoFromFile():

• Does not allow it to scale, or if it is inevitable, pad it so that it does not scale
• Set the photo normal same as canvas normal (3D local)

The current stroke cannot be complete in case when the current canvas is viewed under sharp angle and then at some point the next point to append cannot be projected onto current canvas.

Possible resolution:

• check if there is intersection between mouse ray and _canvasCurrent
• if not intersection with plane, then call for stroke completion function and set _strokeCurrent to NULL

Each mouse action should accompanied by a change of how mouse looks, otherwise it is difficult to define what mouse mode is currently on without trying to use the mouse.

When editing 3D spacial location of the current canvas, it is challenging to see its relation towards other canvases, and toward the "previous" canvas in particular. Lines that would show where current and previous canvases intersect would be useful for better visual clues.

As an example, look at the original software implementation; the intersection lines are dashes and there is also a rectangular shape defining the canvas center location:

E.g., float pie menu appears when strokes are selected

Need to figure out a way how to add "fillet" to each stroke. The original software used glBegin(GL_LINE_STRIP_ADJACENCY_ARB) to draw the stroke that was represented by a set of points.

Re-design the canvas type so that the rotation is performed along Canvas's local axis.

The widget should be able to display two-level entities like so:

Canvas1
|-- Photo1
|-- Photo2
Canvas2
Canvas3
|-- Photo3

The user should be able to select the canvas from this list, and the selected canvas becomes current on the scene as well.

The user should be able to select a photo from the list, and in this case the canvas which contains the selected photo becomes current, and the selected photo becomes current as well.

It causes some visual bugs, e.g.:

• Adding some strokes to the canvas causes the bounding box to offset
• When applying an offset operator, the canvas normal is not located at the canvas' centroid but at the (0,0)

The older version accounted for the bounding box update of canvas, however after the center was changed, it introduced an offset in ray tracing and plane intersection calculation part of sketching procedure.

Initial implementation excludes the usage of stylus buttons (eraser is not counted as a button).

It would be useful to have those buttons assigned to some actions, for example, camera navigation: the lower button could do PAN and the upper button could do ORBIT, while the tablet wheel is already responsible for ZOOM.

Enforce usage of OpenGL 3.3+, for example, from cmake

1. Track the angle based on a mouse position, e.g., a mouse point defines new direction of the canvas normal
2. Offer to chose along which axis to rotate, e.g., it does not make sense to rotate canvas located at XY plane along Z-axis.