gafferhq / gaffer Goto Github PK

To help orient users, we should draw an x,y,z gnomon in the corner of the 3d viewport.

Also, a configurable grid centred on the origin would be a welcome addition.
Configurable options:

• enable/disable
• size of grid
• frequency of divisions
• centre line colour/width

Suggested new name: 'EntityInspector' - in line with adoption of 'entity' to describe objects that exist at path in a scene.

Users may want to be able to re-arrange layouts by dragging and dropping panels/tabs.

This means we need an unsavedChanges plug on the ScriptNode(), and a way of setting it.

• implement mechanism
• enter relevant information for each existing node

Allow the user to interactively switch nodes on/off to see what their affect is.

Type name clashes can result in nodes parameters not being drawn in the NodeEditor.

# Traceback (most recent call last):
# File "/software/apps/gaffer/0.53.0/cent5.x86_64/cortex/8/maya/2012/python/GafferUI/NodeSetEditor.py", line 187, in __updateTimeout
# self._updateFromSet()
# File "/software/apps/gaffer/0.53.0/cent5.x86_64/cortex/8/maya/2012/python/GafferUI/NodeEditor.py", line 114, in _updateFromSet
# GafferUI.Label( node.typeName() )
# Boost.Python.ArgumentError: # Python argument types in
# ArnoldLight.typeName(ArnoldLight)
# did not match C++ signature:
typeName(GafferArnold::ArnoldLight {lvalue})

Add support for drawing textured models in the 3d viewer.

How would textures be specified? Based on shaders assigned? Or some extra attribute?

Support for 'UDIM' style textures would be required.

A 'Dot' is a node that performs no modifications to the scene graph, but which can be used to control the path of noodles between nodes.

Should be implemented such that one node type (or template type) can provide dots for all processing modules (image, scene, etc)

Should be more like cropping.

Currently users can only view the 3d scene through the generic perspective camera.

They should be able to pick the camera to view the scene through from any camera existing in the scene.

Implementation details:

• Should the selection of the camera be from a dropdown list in the Viewer somewhere?
• Or could users drag a camera from the SceneHierarchy into the Viewer?
• What about lights?
• Users will want to be able to modify the position of a camera interactively whilst looking through it. What impact does this have?

This is a result of legacy naming.

Also should it be called 'ObjectReader' or 'CortexReader' to distinguish it from other readers?

A viewer capable of displaying the uv layout of models would be helpful when working with textures mapped to models.

Suggested features:

• show uvs for currently selected object
• uv picking - with corresponding uvs highlighted in 3d viewer
• texture map overlay
• native support for 'UDIM' style textures, including drawing correct texture map in each tile.

Make 'current frame' a plug which drives the default context

Add ability to import saved .gfr files into the current session.

• Add ScriptNode::import() method.
• Add File->Import() menu item.

So we can connect an image to the skydome for instance...

Implement simple 3d painting system to provide an artist friendly way to set point/face attributes.

Example uses would be painting a mask to be passed via a primvar into a shader.

Requires drawing of custom design for each light type.

A majority of production renderers offer some form of raytrace hider based interactive rendering (often know by the maya name 'IPR').

This approach to setting up lighting and shading is gaining traction in production.

What features would we expect?

• interactive transformation of lights
• interactive hiding/showing/creating/deleting of lights
• interactive transformation of cameras (whilst viewing scene through camera)
• interactive transformation of objects?
• interactive changing current frame?
• tweaking of shader (surface, light) parameters (all types?)

What changes would reasonably require a re-export of the scene?

Users will want to clear output after running scripts to ease identification of new output.
Decide whether the ScriptEditor will have a toolbar for this sort of thing, or a context sensitive right-click menu, or something else.

• Replace name/driver/data with just the label, and move those fields into the collapsible section.
• Add a delete button per display.
• Replace the quantize field with a simple dropdown menu (EnumPlugValueWidget)

Need to recover and display an error, rather than silently fail.

Each type of drag should display a cursor indicating what is being dragged.

As objects approach the camera, the rate of zoom appears to increase significantly, limiting precision for the user.

When copy->pasting nodes, the newly created nodes should be pasted either:

• somewhere underneath the mouse
• or centered in the currently viewed graph area.

Review behaviour in other applications, and use that to inform choice. Then implement.

Pressing 'Tab' to raise a node creation menu is commonly used in node graph editing software.

To aid user familiarity it makes sense to emulate this.

Implementation details.

• 'Tab' should only be bound in the context of the NodeGraph editor
• 'Tab' followed by typing the first characters in the name of a node should be provided as an option for quickly selecting that node for creation
  • Should that action perform the selection as if the user was clicking on the NodeMenu?
  • How would conflicting names be resolved? 'r' 'e' 'a' would match both Read and ReallyAwesomeNode.
  • Possibly Tab + type would show a list of matching nodes rather than showing the menu?

Users should be able to middle-mouse click-drag to pan in the NodeGraph.
This should only occur when they click in empty space (to avoid conflict with actions related to middle-mouse clicking on nodes and noodles).

Because you can't use wildcards when a single path is needed.

Filters will always be used when multiple paths can be matched.

So that one entity can be constrained to follow the transform of another entity.
Allow for offsets to constraint.

Users should be able to filter the displayed contents of the SceneHierarchy editor by

• type ('show just cameras')
• name ('show droidArm')
• other?

We don't need the last two lines :

__children["Displays"]["__uiPosition"].setValue( IECore.V2f( 5.65656, 11.4747 ) )
__children["Displays"]["__uiPosition"]["x"].setValue( 5.6565647125244141 )
__children["Displays"]["__uiPosition"]["y"].setValue( 11.474745750427246 )

Add a user preference whether to restore layout from .gfr file when loading or not.
Users may not (for example) want to get the window layout when opening someone else's work.

Users are likely to want to modify what objects are visible in the 3d viewer whilst interacting with the application, without constructing and maintaining graph branches to achieve this.

suggested functionality:

• to be able to isolate the currently selected objects.
• to globally invert the display state of all objects.
• to be able to set the display state of objects in the SceneHierarchy editor (possibly with hotkeys or with toggle buttons drawn in the editor)
• to be able to see hidden items 'greyed out' in the SceneHierarchy editor.
• to optionally have the display status of entities to affect the render output (possibly only in preview renders, or both preview and batch renders)

Should build from source as part of the general gaffer build.

• Setup hierarchy for text source files.
• Enter sample content.
• Target to build both HTML and PDF documentation.
• Somehow take screenshots as part of the build process, so they don't fall behind.

Right/left arrow keys should increment/decrement current frame when focus is not in text/numerical entry field.

NodeGraph should scroll automatically when dragging nodes or noodles outside the visible area.

To help with display of more complex attributes attached to entities.

Some minor UI improvements to come along with that:

• two tone row striping should stretch width of view
• given the importance of 'type' it should be listed immediately after 'Node','Path','Bound'. Type should be cheated for entities that have a transform but no object to say 'type: Group' (?)
• horizontal anchor for left edge of second column should be quite a bit further right. This is to avoid the columns jumping around when the longest label in the first column changes (due to selection change).

Investigate OSL metadata standard, and if it seems sensible, adopt that.

Being limited to picking and framing the view to object level items can be restrictive.
Complex models made up of small numbers of objects (for example organic shapes with no edges where joins could be hidden) can be very unwieldy.

Most 3d packages allow the current selection to be composed of components such as points and faces.

How can we enable that functionality in gaffer?

Currently users can place networks of nodes inside boxes.
What else do we need to enable a 'gizmo' or 'houdiniDigitalAsset' type workflow?

• parameter promotion from nodes-inside-box -> box itself
• renaming/labeling of parameters?
• tabbed layouts in NodeEditor?
• exporting of 'gizmos' to some file format
• referencing/importing of 'gizmos'
• versioning?

Users can save custom layouts, but currently by default the 'Default' layout is loaded on startup.

Users should be able to specify one of the other available layouts to be loaded on startup.

Using the scroll wheel to track the camera in a viewer will 'zoom in' at a greater rate than when 'zooming out'.

The same occurs in the NodeGraph.

Layouts should restore

• window size
• position
• current tab

Users will want to be able to 'tear-off' or 'float' the contents of a tab/panel.

See if we can add ability to echo all commands in the ScriptEditor output, no matter where they originate. This involves:

• Adding a method to the Action class which returns a string which is the python code needed to perform the action.
• Attaching to ScriptNode::actionSignal() in the ScriptEditor and using the new method to echo into the output window.

To help users to create tidy node graphs, we should implement snapping of nodes.

It would be good to move nodes and have them snap to positions that align horizontally and vertically with their input and/or output nodes.

Use PopupWindow so we get to test that a bit.

• Tab auto-complete
• Browser

Both these things mean having custom editor widgets on the qt view.

Ben and Edmond are both busy men with important things to do.