Grad Thesis Update

2017-02-20 – Thesis Update

Introduction

The Open  Shader Editor (OSE) is a platform for creating shading networks and testing newly developed shaders in a responsive environment. It is built on top of abstract classes that can be inherited to extend support for new renderers easily. OSE contains classes on the backend to bring in, interact with, then export shading networks. It also contains an interface for creating and interacting with shading networks called the Canvas. On the front end, a QT interface has been built to make it easy to build and export shading networks.

 

Quick Links

Thesis Paper – Work in progress on the thesis paper. The easiest way to leave feedback is to comment on the google doc itself. 

Current Version of App – View readme in zip file for requirements and instructions. Note that this has not been tested on multiple platforms. View readme for troubleshooting if unable to run. 

Current App requirements:
I highly recommend you attempt to run this in Monty as the Renderman’s and Python’s setup ‘should’ be set up right there. (Famous last words…)
Python 2.7
PyQt4.0 or higher (Normally installed, more info here: https://sourceforge.net/projects/pyqt/)
Renderman 21 Pro Server (if Env is not set right, the settings can be updated to point to the installation of Renderman. in OSE\OSE_Modules\settings)

-Final build will have required python libs bundled in-

 

Canvas

The canvas is responsible for storing and modifying all the data in the application. With it and a python shell, a shading network can be created and tested.

Example
x = Canvas() 
x.add_node('PxrFacingRatio', 'facingRat')
x.add_node('PxrMix', 'mixer')
x.add_node('PxrDisney', 'disney')
x.edit_attribute('mixer', 'color1', datatypes.Vec3(1, 1, 0))
x.edit_attribute('mixer', 'color2', datatypes.Vec3(0, 0, 1))
x.connect_attributes("mixer", "resultRGB", "disney", "baseColor")
x.connect_attributes("facingRat", "resultF", "mixer", "mix")
x.export('disney', _preview=True)

The Canvas contains high level function for working with a network of nodes. It has several lower level classes that are used for importing, saving, modifying, and exporting various custom data types. The pipeline for working withing the canvas is: Data import from renderer (available nodes, paths, ext.) -> Build a node network with the classes -> Export using the exporter class. 

*I am currently working on documentation for all the classes listed above and will have it on this page as soon as possible.*

 

 

Importers

Importer Base Class –

The importer base class is responsible to build node objects  to serve as templates for nodes that the user can create. For each renderer implemented, the importer brings in types of nodes and stores them in the canvas. This nodes can be used later by the canvas.

 

Rman importer –

Pixar’s Renderman is the first supported renderer and the primary one used for testing. The reason for this is that it is set up in a way that is easy to interface with. The env variables make it easy to find the locations needed and the args files provide all the needed information for building a node network. To create the node templates I parsed the args files for the patterns and shades. I then used this information to build my nodes.

 

Arnold importer – 

To show extensibility, I am currently implementing support for Solid Angle’s Arnold renderer. This renderer is more complex as the arguments are not stored by default in args files. By combining information from the kick utility (command line tool for interacting with Arnold) and the Katana args files, the information for building nodes can be obtained. This is still an in progress feature and needs work.   

 

Json Exporter – 

This is a special importer that is used in conjunction with the importers listed above. Unlike the ones listed above, it creates nodes and stores them directly in the canvas. This is used to save shading networks. 

 

 

Settings

The settings class is responsible to loading paths and settings for the system. When the class encounters an environment variable it will query the users operating system to get the correct paths. It also loads in setting from json files. There are 3 categories for settings. The path and user settings are used by the canvas and the display is used by the front end described later in this write up.  

 

 

Data Types

All information is stored in custom data types. Nodes, attributes, and connections (missing from above graphic, will be added asap) are used to build networks. The Vec3 class is a utility used for interacting with colors and vectors. The node importers are used to get information from the specified renderer into these formats. 

 

Custom Node

This is a special kind of data type for a node that deals with nodes that are having their current source edited. Using a pyqt4 event listener, it can compile a node, reload the args, then update the network it is in to allow for feedback on how a node is working within a network while a shader programmer edits the source. In the current version, a Pxr OSL node can be created. Once a shader writter edits the source code, the node is complied then using the OSL info utility a new args file is generated. The node network the user is in is updated automatically. More information can be found in the current draft of the thesis paper. 

 

 

Exporters

The base class for the exporter is inherited by all the render specific exporters. They all also contain the preview options for the specific renderer. 

 

Rman Exporter

The rman exporter can write out a RIB file for the shading network or insert it into a template RIB and render a preview in IT.  To build the network, the user selects the shader they want to render. The exporter then recursively works its way through the attributes and generates a new node when it encounters a connection. If it runs into a node it has already built, it is skipped.

 

Arnold Exporter 

This class is still in development. will work the same way as the Rman exporter however it will generate an .ass file (Arnold’s Scene description file)  and then use kick (Arnold’s Render Utility) to render it. 

 

 

Qt Interface

To allow for easy use of the editor, a front end interface is being created. This give you an interface like you would see in Maya but with the ability to mix in nodes that are being complied with the custom nodes. The usability of the interface is still being worked out as well as some bugs with some nodes. Pyqt provides many tools to build user interfaces. The node network however needed to be built by scratch on to of it. Widgets for each data type were also created.

 

 

Signals and Slots

The entire front end is built using signals and slots. Pyqt objects  were created for the following items. 

All signals and slots work their way up the the main window which executes commands to the canvas. All of the canvas interface functions return a value, true, or false. These return codes are sent back to the main window. The only time the canvas sends commands to the main window is when a custom node is triggered. This signal is unbound, meaning you do not need the main window to use custom nodes.

 

Areas of Improvement/high priority bugs 

  • Node interface – Sometimes using the node interface can be chunky. This has been a low priority up to this point as it is still usable. At this point however I think it can use an overhaul to allow more responsiveness, the ability to zoom, and overall a better look. 
  • Some nodes not loading – Noticed today that some of the PRMAN noise patterns are not loading attributes in the attribute editor. Need to investigate
  • Custom BXDF Support – May need to implement this. Would be a powerful feature but also maybe a rabbit hole to link up all the libraries across platforms. 

 

Questions for Committee

  • Should I be focuses on developing support for other renders, support for more custom node types, or improving the functionality I currently have? Need to focus my efforts to finish this on time. 
  • Will this timeline work for the committeeMarch 1st – Testing by ILM of tool begins
    March 3rd – First draft of paper to committee
    March 8th – Testing completed
    March 10th – First Draft back from committee Members
    March 17th – Second Draft sent to committee Members
    March 21st – Tool Completed to thesis standards
    March 24th – Visual Completed to thesis standards, Second draft sent to committee.
    March 27th – Final Thesis Draft and components sent to committee
    March 31st – Tentative Defense if thesis is to committee’s standards (Remote or in person depending on thesis progress throughout the month) 
  • Am I missing anything in the thesis paper outline I should be covering? 

 

Visual Component

My Plan for the visual component is to use the tool in the coming days to develop pattern nodes for two projects my wife Maria and I have been working on in out spare time. Below are screen captures of current renders of progress on the two animated projects.

 

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *