I've long thought that more can be achieved through greater cross-pollenation between discipline domains, that people should specialise in a little more than one area, that we should explore the possibilities of mixing techniques together in creative and interesting ways, and do it through the play that using highly interactive tools and flexible, modular architecture allows.

Monday, 11 July 2016

A Look Around The Editor

For this post I'll
show you round the different parts of the editor application's user
interface. Next time I'll dig into the
editing functionality and how to use Apparance to actually build procedures.

An
Editor?

Why do we need an
editor? Well, we are trying something
very different here, by way of workflow, modelling paradigm, and output. As essential parts of the Apparance concept,
building a custom editing application was the only way to achieve this level of
bespoke requirements. Some of the
important features it needs are:

Creation and management of
procedures

Data-flow based visual graph
editing

Preview of resulting
procedure output

Real-time, interactive
authoring and tweaking

Looking through the
image gallery you can see how the user interface developed. Initially as I was proving the procedure data
representation and the synthesis process it was just driven as raw XML data. This was fine for testing, but as you can
imagine it was incredibly unwieldy for anything but very simple
procedures. As the project progressed I
worked on each of the main interface elements in turn, improving them again and
again. Let's look at them in more
detail.

The Apparance Editor

Browser

Good design means
factoring out functionality into smaller, re-usable, chunks, and consequently
we will need to be able to work with many procedures. At the moment, procedures are organised in a
simple two level hierarchy with a Category and a Name. This will probably need expanding in the future, for larger projects, but provides a way of grouping procedures together for now.

Procedure/Operator browser and properties of selected procedure

A
browsing panel lists all the procedures and as a navigation aid there is a
filter box to narrow down those displayed. As well as
procedures, the fundamental operators they are built from are also listed, in
their own browsing panel and can be filtered in the same way.

Procedure
Editing

Once you create a
procedure you need to start specifying the functionality within it and the
connections in and out. This is
performed within the main area of the editor in a scrollable, zoom-able window.

Zoomed-out overview of a large procedure in the editing window

Often your operator
graph will fit within the window, but for more complicated creations you will
need to zoom out or pan around.
Operators are boxes with the name of the operation at the top, inputs on
the left, and outputs on the right. The
procedure itself has its inputs on the left and outputs on the right too. Consequently, the natural visual 'flow of
data' is from left to right, most connections and chains of functionality
propagating information to the right.
This doesn't mean you can't make connections in any direction and create
all manner of spaghetti. Careful factoring out of messy bits into
sub-procedures helps here.

The inputs and
outputs of the procedure that you specify and name here are what you will see
and be able to connect to when you place your procedure down within another
procedure.

Procedure IO editing

3D
View

There is a rendering
window in the corner of the editor where you can view a procedures output. At the moment all output is 3D model
geometry, and as we are targeting 3D worlds this is all you need to see a model
in place.

The 3D preview window

By electing to view
a procedure, you are specifying the starting point of the geometry synthesis
process.In order to do this with
procedures that have inputs, you need to be able to specify their values.This can be done where you edit the input
connections to your procedure (see above) and are effectively the default values your
procedure comes with.This means you can
preview any procedure as each come with some starting values.These are also the values your procedure
starts with at its inputs when you place it down.

The 3D view-port has
pretty standard camera navigation controls, with orbit, and FPS style movement
as well as an auto-rotate mode for showing off a model.

To help with
construction and spatial orientation, a ground-plane grid is drawn for
you. This is implemented as another
procedure that can be edited just like any other if it needs customising (e.g.
turn off, adjust colour/intensity, spacing, scale, etc).

To get a better look
at your scene you can expand the 3D view to occupy the whole editing and
browser area. This leaves the property
editing panel (which expands to occupy the space where the 3D view was). This mode is ideal for tweaking values,
simply select the operators who's inputs you want to change and switch to
expanded mode.

Toggling the large 3D preview window

Property
Panel

Most editing
environments include some form of properly panel where a list of the individual
adjustable elements of an object are shown.
The Apparance editor uses this for editing (and viewing) a number of
things, such as: Operator input constant values, procedure IO name and
description, new procedure name and description, renderer settings and
statistics, view-port visualisation modes (see below) and diagnostics, and grid settings.

Property viewing and editing panel

Most data types are
fully editable, some with specific enhancements such as sliders for floating
point values and toggle buttons for enumerations. Sliders have editable min/max values too so
you can set them to a sensible range for the value the slider controls.

Development

In line with the
live/interactive editing model adopted here, most of the user interface can be
updated at run-time. This has made
development of the UI much, much faster and allowed much in the way of polish
that would have otherwise been left. The editor UI is
implemented in WPF which supports dynamic loading/parsing of the backing XAML
design data. Custom text editing panels
can be expanded to allow live editing of most of the editor interface.

Live editing of the editor UI

The synthesis
process can be monitored in a custom panel showing each of the synthesisers,
with a timeline of the jobs each works on.
For each job a breakdown of memory use and any issues encountered is
displayed. This is needed to diagnose
any technical modelling problems.

Synthesis statistics and diagnostics

Another panel allows
exploring of the internal engine structure and any properties exposed by each
part.

Engine exploration; here showing view-port modes and settings

There are a few ways
to analyse the operation of the engine, the synthesiser, the procedures, and
the tools, including: GraphViz dumps of each synthesis run, the scenehierarchy, and procedure capture analysis process, as well as in-editor
visualisations of the detail refinement hierarchy, the editor tool stack, and
the UI stack. All helpful in working out
why things aren't going as expected and important to understand how best to
build procedures that work well with the engine.

Coming from a technical and practical upbringing I've always been passionate about computers and electronics; writing programs and building contraptions from primary school age upwards. Studied electronics at university, and working in games development since 1995.