Project Progress Report

Sorry for the lull, it's been a bit of a mixed-up month and this will be a similarly mixed up blog post.  Having reached the deadline for demo, web site, and release preparations at the end January things have changed pace and direction a little.  I've rolled an Alpha build to a few people, the web-site has gone live, and I've been out job hunting too!

Goals

The end of January was my deadline for a number of aspects of the project, and this has meant February has been a bit of a flurry of activity releasing things and talking to lots of people about the project (and work prospects).

Demo

As with most things, you never get as much done as you'd like to.  No exception with Future City, but I am mostly happy with how it looks.  It demonstrates the core premises of the project; large environments, varied content, wide-scale parameterisation, high detail, smooth blending, and powerful modelling system.

I'm pleased with how the demo "Future City" has developed

I will continue to develop the city as there are many things I'd like to do with it, but it is also going to be the basis for the first Apparance game.  It will be taking a back seat to other development for now though.

Web Site

The Apparance website, bringing together information about all aspects of the project, is now live at www.apparance.uk.

The new Apparance web-site (procedurally generated too!)

I'm pleased with how it's come out, and the procedural generation aspect is proving very powerful.  A good test of this sort of thing is how easy you find maintenance on returning to it after a while away.  I've extended the site a bit, added new templates and image features with ease.  Updating content is just a question of editing the markdown documents and running the Apparance Processor.  I'm enjoying working with it this way, and looking forward to adding new pages and features as needed.

Release

The 1st of February saw the start of the Alpha release of the project.  The first time anyone has got their hands on Apparance for a couple of years.  It's really been too long coming, but I wanted to get to a particular point and combine it with the website and the city demo.

Apparance editor, currently in (closed) Alpha

It's not a huge audience, and only some of my more technical friends, but I've been getting some solid feedback.  Plenty to go on and lots to talk about.  I've been working a bit of it back into the editor, and site, ready for the closed beta due to start in a few days.  The beta is a larger group, and taken from a wider circle of acquaintances (mostly via Twitter).  This group contains a higher concentration of people who are specifically interested in procedural generation, and should provide a deeper level of feedback.  I can't wait to hear how you folks get on.

Project

So, where does this find us now?

Status

The current set of goals, largely based around proving the more unique aspects of the project, has been proven (in my eyes at least).  Now I have people starting to experiment with, and explore the tools I have a source of objective information to use to potentially steer and drive the project.  I'd like to see a variety of outcomes from the project, but now is time to discuss these and investigate the options.

Support

As an authoring tool, and one with some pretty unusual concepts to learn, support for Apparance users is going to be important at this stage.  This is especially true if I want to nurture a community and have people join me in this adventure.  Documentation, tutorials, and two-way communication are all important parts of this, and typically under provided so I need to be careful to keep feeding this.  I've been asked for a variety of support, from examples, tutorials, videos, features, and improved documentation.

Games

Apparance is a realisation of my vision for building games, and as such needs to continue to move towards an actual game.  I need to show that this is viable, and with the ambitious technical goals too.  I have some exciting game ideas brewing at the moment (several sleepless nights spent designing game-play and story).  Unfortunately, the next step with regard to games (entities, behaviours, and interaction) is quite a hefty piece of work.  This is going to need to be spread out.

Product

I have also begun thinking about the more practical aspects of the project, and other ways the technology could be used.  By creating additional types of product out of the engine and tools it might provide a way to broaden the potential audience (and hence market) and provide a model to generate revenue that isn't game based.  Yes, I am actually considering how Apparance could be modularised so that elements of the technology could be plugged or integrated into other engines, including Unity and Unreal.  I know I haven't been supportive of this approach, but economic pressures do make you think about your options, and there might be ways to do this without compromising the vision of the project.  Again though, this isn't an insignificant amount of work, and requiring a lot of research and ongoing development and then support.

Next

I've really enjoyed the luxury of working full-time on Apparance for (nearly) the past year, but financial pressures are starting to rear their head.  I don't believe I am in a position to pitch what I have technology-wise, and certainly not game-wise, to a third party for funding.  There is too much still to do and I don't have the resources to continue full-time.  As a result I am in the process of negotiating a more traditional source of income so I can continue to support my family properly.

Apparance is most definitely up and running and I'm pleased with what I have achieved so far.  I will continue to support the alpha/beta, blog about the project, work on updates, and start on some of the bigger features over the coming months, but in my spare time (again).

Thank-you for sailing with me through this exciting year of Apparance development.  I look forward to seeing where the wind blows us over the next year.

Sam

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.

Next

Next time I will talk about procedure creation, editing, and viewing.