Secret Level

1
The 64 Million Poly Question Massive World
Building in Maya
Paul Edmondson, Secret Level 2007 Autodesk
Animation API Conference
2
Who am I?

• Lead Programmer of the Riders Technology Group at
  Secret Level
• Former Technical Art Director, LucasArts
• Instructor at Art Institute of CA, SF in Visual
  and Game Programming Program
• Over a decade of experience in tools development

3
Who are we?

• Rapidly growing SEGA studio
• Long history of tools and technology development
• Using Maya for art and design
• Currently working on Golden Axe and Iron Man

4
Who this talk is for

• This talk is framed in terms of game development,
  so game developers will have it easy
• These principles can easily be applied to other
  applications, however

5
Agenda

• The Problem with World Building
• Why Maya?
• A Solution
• Implementation Details
• Demonstration

6
The Problem
7
We want big worlds!

• With the latest generation of hardware, larger
  game worlds are possible than ever before
• Developers are ready and waiting to take
  advantage of new engines pushing the limits of
  what has been done before
• Massive environments are important because of a
  desire to convey scale in ways that were
  previously very difficult

8
Scaling problems

• People experience scale by juxtaposing small
  objects against big objects

9
Scaling problems (contd)

• To provide an effective sense of scale, a world
  must be full at both the macro and micro level
• Full More content!
• Content creation tools have to scale up along
  with the world complexity

10
Scaling problems (contd)

• Scaling content creation tools is not as easy as
  content
• Gigabytes of raw data are possible in a single
  level!
• Most engines rely on substantial preprocessor
  steps to optimize data, but tools cannot do so as
  easily
• Engines also typically handle large datasets by
  streaming, but tools usually do not

11
Scaling problems (contd)

• Larger worlds also necessitate more people
  creating those worlds
• Previous workflows are not always applicable
• Multiple users will be editing the world at the
  same time
• Versioning systems must be integrated with
  content creation

12
Polygons make things worse!

• Most developers do not use subdivision or NURBS
  surfaces for final game models
• Standard methods of high-speed polygonal modeling
  do not scale well
• Massive worlds can contain seamless, procedural
  data sets that contain many millions of polygons

13
Not just art

• Non-artist users?
• Gameplay and design tools do not always use
  standard modeling primitives
• Various users need to share and build off of each
  others work
• Special consideration has to be made to integrate
  these all workflows

14
Terrain authoring

• Terrain authoring often has many restrictions
  that must be encoded into the toolset and data
• The resulting workflow is often more similar to
  Photoshop than Artisan despite appearances
• Look development is still important, but always
  in terms dictated by the game engine

15
Why Maya?
16
Some men see things as they are and say, 'Why'? I
dream of things that never were and say, 'Why
not'?
17
Maya is a great tool, but

• In the end, Maya has slightly different aims than
  large-scale world building
• Many extant solutions to world building in Maya
  require taking over features that users would
  traditionally use for day-to-day work

18
Maya is a great tool, but (contd)

• Reference-based workflow is difficult to extend
  without forever binding workflow to Maya
• Layer-based workflow is similarly difficult to
  extend
• Instance-based workflow is easier to work with,
  but forces restrictions on content creation

19
So, why Maya?

• Well-supported framework for traditional
  authoring
• The user base has familiarity with interface and
  feature set
• Scriptable interface
• Fantastic and well-maintained API for custom
  development!

20
World building in Maya

• The ability to edit geometry while it sits in the
  level is invaluable to artists looking to
  sidestep engine limitations
• Maya is an excellent environment for previs
  rendering and animation for cinematic sequences
• Dependency graph and DAG provide excellent hooks
  for manipulating placed objects

21
Our Solution
22
Requirements
23
World building

• Our world contains an arbitrary number of levels,
  only one of which would be worked on at once
• We needed to support levels as large as 16km x
  16km
• Levels could contain any number of data-driven
  placed objects

24
Terrain data

• Regularly-sampled height field
• Material alpha masks
• Gameplay information
• Foley and FX cues
• Ease of traversal
• Procedural object (deco) masks

25
Terrain editing

• Full parity with final rendering not necessary
• Visual feedback for invalid data
• Custom render modes that assist workflow
• Specialized brushes, tool modes, and filters to
  augment content creation

26
Object placement

• We must support artists, designers, and even
  programmers all working at the same time on a
  level
• All types of objects cannot be anticipated
  typing must be data-driven
• Object organization is very important

27
Tool support

• Other applications need to access world builder
  data
• Our exporter needs a compact representation of
  levels to work with
• We need to query and maybe visually represent
  parts of the world from other tools without
  touching Maya
• We may someday want to have a standalone version
  with a different feature set

28
Technical art support

• We have a group of technical artists that can
  respond quickly to production needs and
  troubleshoot pipeline issues
• They need to have a method of scripting
  interactions with the world builder

29
The Approach
30
Use Maya as a host application

• Use Maya for its strengths
• Leverage as much of Mayas interface and
  extensibility as possible
• Create an abstraction layer that allows for
  versatile application of the world builder
  functionality outside of Maya

31
Abstraction of the toolset

• Content creation takes many forms
• We dont want to coerce all possible
  functionality into Maya
• Therefore, we separate Maya-dependent and
  Maya-independent parts of the world builder

32
Maya scene work state

• We do not save world data in Maya scene files
  instead we use Maya scene files to save users
  work states
• World data is stored separately in an extensible,
  proprietary file format that can be used by other
  tools
• By leaving layers, sets, grouping, etc. all up to
  users, we do not interrupt their favorite and
  best practices

33
Customize the loading process

• A level may get too big to load at once, so we
  stream it
• We choose only to load parts of the world that
  are relevant to the current user
• We support active paging of data that is no
  longer necessary to have close at hand

34
Customize the rendering

• The only way to handle the amount of data is to
  render with a variable level-of-detail (LOD)
• Preprocess models into efficient load-on-demand
  structures
• Prioritize for speed or visual fidelity as
  appropriate

35
Customize the representation

• Content creators usually only care about certain
  subsets of the overall content
• This isnt a problem if we only expose to Maya
  what the user actually wants to edit
• We give technical artists the ability to extend
  world builder functionality from MEL through
  custom commands

36
Integrate version control

• We group world data into versionable chunks that
  can be saved and edited independently of each
  other
• Embedded interfaces to version control simplify
  the users workflow
• We can extend version control systems as
  necessary (e.g., a custom merge tool)

37
Demonstration
38
The World Builder Architecture
39
Overview
40
Data Component

• Saving / loading
• Streaming
• Paging
• Version control integration

41
Renderer Component

• OpenGL, without knowing anything about Maya
• Handles LOD
• Supports visualization plugins

42
Base Editor Component

• Allocates Data and Renderer components
• No dependency on Maya, to maintain standalone
  capability
• Supports modification plugins

43
Editor Application Component

• The only Maya-specific component
• Provides all user interface support
• View management / LOD control
• User interactions
• Scriptable interactions
• Error/info display

44
Component coupling

• To maintain application insensitivity, the base
  editor cannot know about the editor application
• We declare an interface that the Maya-aware
  application component implements to enforce this
  decoupling
• The data component should be kept decoupled from
  all other components as well in order to support
  command line applications

45
Maya Implementation
46
Interface

• Use a custom menu as a portal
• Users choose to load levels into their scene
• Upon load, spawn custom node(s) into scene that
  represent the level

47
Editor control

• We have a handful of Maya objects that will need
  to access the back-end components
• There are a few ways to access the underlying
  architecture
• Use a singleton or static connection that can act
  as the gateway to all back-end data and
  functionality
• Manage the connection from within a node in the
  DG or DAG and use Maya to associate world builder
  nodes with the level

48
Editor control (contd)

• Singleton-style access to architecture
• Easiest manner of access
• Requires that only one level be loaded ever at
  once
• Does not place constraints on DAG and DG
  implementations
• Cleanup can be performed on deleteAll or
  NewSceneOpened events

49
Editor control (contd)

• Node-style access to architecture
• Allows multiple levels to coexist in a scene
• Requires parenting or attribute connection for
  nodes to access underlying architecture
• Cleanup is automatic triggered by node
  destruction

50
The level

• We choose to use an MPxSurfaceShape to represent
  the level hub
• The level node is responsible for
• Rendering terrain
• Rendering non-live components
• Optionally choosing which level to edit
• Saving can be tied to Maya scene save, or managed
  through a menu option

51
The level (contd)

• Level choice can be as simple as setting a string
  attribute on the level node
• Create an internal attribute of type kString to
  specify the level path
• Override setInternalValueInContext to trigger a
  level load/unload
• or through a MEL command
• Forego the attribute and spawn the level node
  pre-bound to a level

52
Terrain representation

• We chose not to represent terrain components in
  Maya for performance and simplicity
• A custom MPxCommand can be written to allow
  query-based data access and snapping to the
  terrain via expressions

53
Terrain representation (contd)

• The bottleneck with massive height fields is not
  manipulating data, but rendering it
• Rendering is handled with a custom LOD-based
  renderer
• Special consideration given to allow modification
  at full detail even when portions of the terrain
  are being rendered at low LOD

54
Terrain modification

• Handled through a custom MPxContext
• The context is a portal to a back-end
  modification system in the base editor
• Modifications are at simplest handled like
  contexts, but with extensions to support level
  interactions
• The system is plugin-based so that we can add new
  brushes and tools later

55
Terrain modification (contd)

• MPxContext is missing a doMove function, but we
  can subclass the M3dView window and catch
  WM_MOUSEMOVE messages
• Use overlays instead of trying to trigger a
  refresh from doMove the view wont be able to
  keep up with your mouse movements otherwise
• The base editor component uses the Maya-unaware
  editor interface to trigger a refresh when
  necessary

56
Terrain undo / redo

• Potentially a whole lot of data to change!!!
• Handled internally within the base editor
  component, so that undo/redo actions can be paged
• To simplify brush authoring, all terrain
  modifications are channeled through the undo/redo
  manager
• The undo/redo manager is actually what modifies
  the terrain data

57
Terrain undo / redo (contd)

• We integrate our undo/redo actions with Mayas by
  executing a dummy MPxCommand with every
  modification
• The dummy command only serves to cue our back-end
  system to do the internal undo/redo application
  when called for
• The base editor component uses the Maya-unaware
  editor interface to trigger the dummy command
  execution

58
Placed objects - theory

• Lots of placed objects can potentially slow the
  system to a crawl!
• Users usually only care about certain subsets of
  the placed objects
• This is also where multi-user concurrent editing
  becomes very important
• Solution create a layer-based workflow

59
Placed object layers

• User-defined subsets of placed objects
• Not tied to Maya layers (so we can let the users
  do what they want with those)
• Stored as separate data files on back end
• Integrated with version control

60
Placed object representation

• Use a custom MPxSurfaceShape to represent placed
  objects
• Custom properties of placed objects can be
  represented as dynamic attributes on the nodes,
  or edited through auxiliary scripted panels
• Since were using a custom MPxSurfaceShapeUI,
  object selection is configurable

61
Placed object versioning

• When a placement layer is checked out from
  version control, we make it live by spawning
  the placed object nodes in the Maya scene
• This way we can avoid cluttering the DAG or Maya
  UI with non-editable nodes if a placement layer
  is read-only, we just dont spawn its nodes into
  the scene

62
Placed meshes

• We use an asset-based system meshes are edited
  in their own standalone Maya scenes
• When placed in the world builder, asset proxies
  are used to represent meshes
• Proxies can come from pre-exported or in
  situ-exported assets
• Proxies can be loaded in a separate thread

63
Other placed objects

• Use a set of custom visualizers for other types
  of placed objects
• Visualizers are implemented as plug-ins to the
  renderer component to allow easy extensibility
• Placed meshes arent really a special case in
  this system theyre rendered with a visualizer
  like anything else

64
Placed object rendering

• We use the same rendering subsystem for live and
  non-live nodes
• Live nodes trigger their own rendering
• Non-live nodes are rendered by the level node
  along with the terrain

65
Placed object rendering (contd)

• To increase load-time performance, meshes do not
  have to be loaded immediately they can be
  represented by placeholders until they stream in
  from another thread
• LOD is handled by the renderer much easier when
  using proxies
• There is much more control than when using Mayas
  reference proxies this way

66
Placed object properties

• By representing placed object properties as
  dynamic attributes, we can leverage Mayas UI and
  input tools
• The DG can be used to feed complex data types
  like curves and even animation data into
  properties

67
Placed object properties (contd)

• Several special cases have to be handled
  differently with specialized code and message
  handlers
• Transforms
• Object Name
• Bounding Box
• We can extend editing further with custom
  manipulators

68
Placed object modification

• Trickiest part we have to catch updates to the
  nodes in order to properly save and render the
  objects
• Updates can be handled through DG connections or
  through back-end messages
• But

69
Placed object pitfalls

• Remember the pull-based architecture of the
  Maya DG!
• Using the DG where inappropriate or without
  understanding the data flow can cause a lot of
  trouble
• Users will expect undo/redo to always work, so
  plan accordingly
• Keep performance up by batching DG operations
  with MDGModifier

70
User interface

• Of course, youll want panels and dialogs as
  well
• These can be handled through MEL or through
  custom solutions as discussed yesterday
• Most window interactions can be blissfully
  Maya-unaware, allowing reuse in standalone
  applications so only couple them to Maya when
  necessary

71
Performance considerations

• Maya spends a lot of time doing nothing!
• Use that time to do expensive operations
• LOD update
• Data paging / introspection
• Version control queries
• We use MTimerMessage to trigger low-priority
  updates because it doesnt fire during context or
  view actions

72
Recap
73
Architecture

• Most of the architecture is focused not on Maya
  coding, but rather on generic back-end code
• We can use standalone applications as desired to
  interface with world / level data
• Back-end can be implemented in other languages
  like C, if an API interface exists

74
The Level

• MEL-based menus can be used as the primary
  interface to the world builder
• At simplest, this takes only one custom
  MPxSurfaceShape and MPxSurfaceShapeUI
• You will probably need one or more MPxCommands to
  interface and control level interactions for the
  MEL-based menus to operate

75
Terrain

• No additional nodes required to render the
  terrain
• Only one MPxContext is necessary to interface
  with back-end modification code
• You will probably want one or more MPxCommands to
  interface with terrain data

76
Placed Objects

• At simplest, we can use one custom
  MPxSurfaceShape and MPxSurfaceShapeUI to handle
  all placed objects
• You can use a visualizer plug-in system to create
  extensible representations of objects
• Representing properties with Maya attributes
  allows one to leverage Mayas strengths and
  implement custom MPxManipContainers

77
Pitfalls

• The less you couple your implementation to Maya,
  the more you keep your options open for future
  tool development
• Remember the DG data flow, or else updating,
  rendering, and saving becomes a major hassle!
• Always keep undo/redo in mind!

78
Demonstration
79
Appendix
80
Good luck!

• Paul Edmondson, Secret Level
• Lead Programmer Riders Technology Group
• paule_at_secretlevel.com
• Special Thanks To

Jeremy Gordon Art Yerkes Buzzy Spain Chaney
Tsai Dave George Joshua Lee Lilli Thompson Owen
Brand