- What is Apparance?
- Game Ready?
- The Applications
- What Apparance isn't
- The Name
Apparance is a work-in-progress project, and whilst a lot has been implemented and proven so far there is still a lot of work to do. Find out more about the project here.
See below for a list of features developed so far, and what's still to come. Check out the FAQ page for a look at some common questions, or dig into the development blog if you want lots of behind the scenes details.
What is Apparance?
If asked to summarise in a single sentence I would say:
Apparance is an experimental technology built for the interactive visual authoring of procedural algorithms to create detailed and expansive 3D experiences for video games.
The key features of which are:
- Build 3D worlds - for games and interactive applications
- Procedural generation - parameterise your objects for variety
- Unified toolset - all work within one editing application
- Pipeline free - no baking, build steps, or offline processing
- Live editing - fully interactive editing environment
- Run-time content synthesis - all geometry generated on the fly
- Fully data driven - no compilation or coding (text)
- Small data storage costs - all assets are stored as their procedures
- Dynamic detail - build procedures that know how to add detail
- Scale-less scene management - from galaxies to grains of sand and everything in between
- Level-less continuous world - no loading screens
- Scalable detail control - the more power you have, the better it looks
- Procedural shaders - the flexibility of parameterised shader code
- Customisation - any external parameters you want can drive content generation
- Parallelisation - synthesis is spread across all available CPU cores.
Some of these main features expanded in a bit more detail:
All content is generated, this means:
- Very small storage requirement - only the procedure definitions are stored, not all the generated geometry. This leads on to...
- No loading during play - all procedures are read in up-front as part of the application startup, after that you have everthing you need.
- Every instance can be customised - parameterise your content as you wish, every tree can have a different name carved on the trunk, every leaf unique, every brick printed with its own serial number.
- No baking or compiling - Since generation happens live, changes you make are immediately used and the content simply re-built.
- Variety - You still need to put in creative effort to keep things rich, but the variety that procedural generation excels at brings this out to much greater effect.
- Scalability - parameterisation by detail gives you the ability to adjust your scene for load balancing, trading complexity for performance, at runtime.
- Customisation - any data source you like can be used to drive content generation, from localising textures to including peoples names to following local weather and season. Of course, any number of creative controls could be applied too, an obvious example is difficulty level.
The engine manages scene detail dynamically, meaning:
- At distance, simpler procedures build simpler models. The engine works with your procedures to re-build them at higher detail as you approach, switching in higher detail functionality you provide to build local detail as it is needed.
- Huge scales of environments are possible because the work is only done where it's needed, when it's needed.
- Full utilisation of modern hardware from multi-threaded geometry synthesis. While there is still detail to be revealed your computer will be fully dedicated to producing it.
- No-matter the scale of the environment, the engine will still manage it in the same way, from working at massive galaxy scale, right down to the fine detail.
- Real-time editing - Because any editing operations of value changes in the editor are applied directly to the procedures representation in the engine, they are immediately available to be re-synthesised and update the 3D view.
- Procedural playground - Interactive editing allows, and positively encourages, exploration of procedure constructions and the parameter space they occupy. Play is a hugely powerful tool in forming ideas into tangible and useful creations.
- Small form - Storing only the procedure definitions is a form of compression, you are crystalising the essense of your objects into their very elemental parts so that the computer can magic into existence one of its many variations as required.
- Working procedurally - This is going to be the biggest shift in mind-set, the need to consider exactly how to encode the structure and its variable aspects into procedures.
- Modularity - Making it easy to factor out and encapsulate functionality, and create procedures for any purpose encourages re-use. Parameterisation only aids this further since you can support variation in your procedures for a variety of settings.
- Horizontally - The amount of re-use allows project-wide improvements to be applied easily. Improve that wall procedure and all the walls improve. This means you can work 'horizontally', fleshing everything out project wide in tandem, then applying improvements across the board. This is rather different to the 'build each thing fully before moving on to the next' approach.
- Collaboration - Since many procedures contribute to each object in game, and a lot of them are re-used, people can work on different aspects of the same objects at the same time.
Not yet. There are a few key things needed to fully implement a game, most notably to do with interaction. Have a look at the timeline and feature list for information on how the plan is progressing and what is still to do. Here are a few of the things next on the development timeline:
3rd Party Tools
Recently the project has moved towards exploring integration with other 3D engines and game creation systems. This allows us to bring the rich and interactive procedural workflow to familiar tools such as Unreal Engine 4 and Unity 3D.
Experiments in object placement as an alternative to geometry generation are under-way. This means any engine specific object types (sush as meshes, lights, even prefabs/blueprints) can be instanced and placed using procedures. Whilst not replacing the geometry synthesis, this brings another option to developers in how they can apply Apparance procedural generation techniques to build their games.
Active objects in the world need to exist as entities. These bring together the various aspects of the object into one coherant thing that the game, and other systems can interact with. This includes its graphical appearance, movement, interaction, animation, sound, physical presence, as well as its logical presence in the game world. Apparance Entities will be scalable, in that their presence will be governed by the detail management system. The entity itself will only be brought into existance when you are near enough to its location to need it, progressively upgrading its apperance and behaviour to match the detail level expected.
So far only coloured triangles have been used to render the objects and environment in Apparance. This is because the focus has been on proving the procedural generation and detail management systems first. Texturing (and UV) support will be coming in the future, along with the image processing and generation operators and synthesis support needed to create rich procedural textures.
There is only a very basic lighting system in the Apparance renderer at the moment, with a couple of fixed light sources soft-wired into the defaul pixel shaders.
- Static Lighting - Whilst baked lighting and lightmaps don't fit the procedural generation model, there is scope for pre-calculating static lighting during synthesis. This has the potential to allow all sorts of really nice lighting effects.
- Dynamic Lighting - Since we don't have moving objects (entities) yet there isn't the need for proper dynamic light sources yet. This will come though, and interact nicely with the static lighting.
- Shadows - Currently no shadow support yet, but this is going to be crucial for a modern engine. The novel way the scene is constructed and rendered may present all sorts of opportunities for novel shadow implementations.
- Reflection - Having the surrounding world immediately available for rendering at a range of detail levels should mean that multiple reflection support shouldn't be too costly.
- Transparency - Most of the scene is implicitly ordered (by detail/distance) giving us a head-start on tackling problems you'd traditionally meet with rendering transparent objects.
Behaviour & Control System
A very important part of the project is the way that behaviours, control, and gameplay functionality are authored. Using the same visual graph-based editing approach, a system of 'virtual circuitry' will be provided to build real-time, interactive control systems to embed in the game entities and bring them to life.
- Realtime control - the control system will run live in the engine and adjustments will have instance effect
- Procedural AI - complex control hierarchies can be constructed to build rich and intricate game systems, mechanisms, and entities
- Dynamic scaling - scaling up and down of the control systems allows densely populated, continuous worlds, teaming with life
- Interactive editing - using the same UI language and editing environment means quick iteration and improvement
- User interface - the same virtual circuits can be used to run any part of the game, including the user interface and the controls the user has over their avatar.
Apparance is a set of applications you can use to edit, view, and run your procedural creations. These are:
The node-based editor where all content authoring happens. Includes procedure browser, node graph editor, 3D view, and property editing panel.
A single window application that is purely for viewing 3D content you have created. A standalone program with no editing functionality. For a game, this is what you'd ship your data with to play it.
A commandline version of the apparance engine for running non-visual procedures, such as the ones used to generate this website. It can also be used for a variety of automation and control tasks.
Eventually the Apparance run-time engine will be fully available as plug-in modules for several 3rd party game engines, including:
- Unity 3D - Used by many independent developers and small studios, especially for prototyping
- Unreal Engine 4 - Used in the creation of many AAA games and enterprise projects
- Lumberyard - Amazons own game creation tool-set (based on the CryEngine technology)
- ...and more - As the run-time is now nicely packaged for use in plugins, it can also eventually be incorporated into any C++ game engine opening up various licensing possibilities.
What Apparance isn't
Whilst Apparance is setting out to achieve a great number of ambitious things, there are a some things that are not in its list of goals. Some of these are indeed possible to do, but where they don't align to the core goals the effort involved will be spent on proving the unique (and more interesting) aspects of the project. These non-goals include:
Loading of assets
A goal of the system is to generate all content procedurally, and at runtime. There are no plans to support loading of most common asset types such as meshes, textures, materials, and animations. In the short term there may be temporary support for loading of audio/music files but the long term plan is to generate these procedurally too.
Saving of assets
Apparance isn't intended as an asset authoring tool, in part due to the unique way in which content is generated, detailed, and rendered. Whilst technically feasable, it's not currently a goal to support this.
Integration into other engines
"Is it going to be a Unity/Unreal/Uther plugin?" ..is a question I get asked all the time. For a long time this hasn't been one of the Apparance goals. Whilst there may be a number of economical reasons for going down this path, it's not until recently that I've started experimenting with this option. As you can see, there are exciting movements in this direction now.
Apparance isn't going to solve all your problems, like any engine it has it's strengths and weaknesses. It isn't going to be suitable for some game type, but there will be plenty it will be good for. Encouraging the use of new techniques to build games has the potential to bring to light new types of game that really benefit from what Apparance has to offer.
It's not likely to be useful (at least in the sort term) if you are trying to do the following:
- Specific detail - recreating exact replicas of real-world environments or overly strict designs.
- Sculpted structures - organic, hand sculpted structures that implicitly contain a large amount of data.
- Audio/music - Audio is important in games, and in the short term a more conventional solution will be needed. Longer term the procedural generation of audio and music will be investigated.
- Photos - With no texture loading there will not be a way to include photographs or externally produced imagery into Apparance.
- Creatures - realistic organic creatures and their movements, like sculpted structures, are hard to generate procedurally. This is something to investigate in the future, but unlikely to fit well for now.
- People - Even more difficult that creatures in general. Humans are very good at recognising the human form and it's hard enough to get it right in games in general without having to embody procedures with these skills. Something to experiment with in the future.
- Static Lighting - It will not be possible to use baked static lighting since generated geometry, particularly of a dynamic/parameterised nature, will present too many variations for storage to be practical. There are other solutions available that will eventually be incorporated in the engine to address this.
- Hand Placement - Placing restrictions on specific objects or locations can be done, but is messy and hard to do. It's best to spend the effort understanding the requirements and imbuing the procedures with that knowledge then leave the generation to do the work.
- Voxels - Although there's no reason not to include these in the engine, it's not in the short-term plan.
- Deformable/sculptable - Whilst Apparance will support a flexible entity system for movable elements, highly dynamic terrain and structures are hard to support and even harder to persist.
There are other considerations to bear in mind too:
- Disruptive - The workflow behind and the skill-set needed to get the best out of Apparance will require a shift of mental gear. These way you create games is far from the conventional pipeline, and require a broader mix of talents. This isn't going to fit in a large studio without some serious consideration and changes.
- CPU - The run-time generation of content is highly CPU intensive, and will benefit from as many cores as you can throw at it. That said, it is scalable and you will just see detail appearing more slowly on a lower spec system. Similarly, the rendering and model detail will also depend on the amount of system and GPU memory you have, again this is scalable.
Having said all this, I believe nothing is impossible with software and we should ultimately strive to investigate possible solutions in these problems in the future. They provide some very interesting areas of research.
Now that Apparance is moving into 3rd party engines, most of the above concerns can be addressed by leveraging the wide range of capabilities they bring to the table. Unreal or Unity can provide most of these whilst then being able to take advantage of the procedural generation power Apparance can bring on board.
"Apparance" (or often "Apparence") refers to the outward manifestation of a person or thing, the act of being visible, what others see, the process of creating this external impression. The original inspiration for this comes from "Against A Dark Background" by Iain M Banks; The Solipsists don't subscribe to the concept of the individual with no use of the word 'me', referring to, and in a way justifying, the existence of other members of their group as 'apparences'.