Extensible Renderingand

Pre-visualization of ArtDaniel Horowitz

NVIDIA CorporationKhronos COLLADA FX Workgroup Chairman

Efficient Next-Gen Content

More contentDone betterDone sooner

Industry Trends More sophisticated technology Higher consumer expectation More engine and art complexity Increasing dev staff Explosive growth on art staff Increasing time-to-market Increasing costs Increasing risk

Trend Sustainability More technology

more variables to control and deliver fewer milestones reached on time less predictable return-on-investment

(ROI) Publishers gamble less

More franchising Less risk taken for innovation

Fewer little-guys

I hope you are cringing!

Breaking the Trend

Be Humble Why do you buy a game?

Art, game-play, story Good developers are humble!

Enable art and game-play Who are your customers? Provide good customer services

Interact Developers must learn to interact with

artists. Artist must not be intimidated by

developers Mix it up!

Locate artist near developer counterpart

A Better Tools for the Job

Don’t be Hasty By developer for developers (no

thanks) But not used by developers? Consult the customer

DCC pitfalls Limited usage of DCC application

There are thousands of buttons/nodes/modifiers

Did you support enough? Limited quantity of art samples

Not all art is the same 101 way to do the same thing

Design Considerations Integrate with familiar tools Increase accessibility

Put common features to the toolbar+hotkey

Keep artists focused ON THE ART! Minimize data transfer costs Minimize iteration costs Detect problems early Humans are slow - automate

Design Considerations Reduce “brain to screen time”

Visualize soon Visualize often

Speed conscious Modularity updates are key to real-time Optional 1-click update for extreme cases

Beware of Tools Limitation Threading issues (Photoshop, Maya) 3D API co-existence issues

Separate owner threads

The Many Shades of Preview External viewer

Is this your game? Export & launch File-watching Pipes, tmp files, TCP/IP

Internal viewer Native DCC viewer plug-ins

Provide a playground for models

The Many Shades of Preview

Building a Better Material Integrate with familiar tools

Material assignment Material customization

Minimize time-to-preview Author-time vs. Run-time

Minimize the visual difference Enable preproduction without a run-

time

Building a Better Material Build to your schedule’s needs

Plan to upgrade

ColdWarm

WarmerHot

Strings Custom Attributes Material definition plug-ins Material object plug-ins

Building a Better Material

Strings

Messy names Parsing Prone to spelling errors Compared with options or without?

Building a Better Material

Custom attributes

Increased flexibility Provides tags and name+value pairs Still prone to spelling errors Hard to locate

Reduce errors Use scripts to add, minimize, and build UI Prefix names and tags

Building a Better Material

Material definition plug-ins

Integrated Familiar Accessible Definitions come from file Object’s values live in DCC app

Ex. DirectX Maya Preview Pipeline

Building a Better Material

Building a Better Material

Material object plug-ins

Pros of ‘material definition plug-in’ Material Objects come from file

reference material definition files Export references, not duplicates Direct use of assets

The Shader You Never Knew How can an app load an unknown

shader?

Are vertex declaration semantics enough?

What are these parameters? Are the passes operated in order? What other API calls are needed?

The Shader You Never Knew

Shader Bindings Vertex declarations are a good start Feed parameters intelligently

Standard Annotations and Semantics Scene

Identify scene values for parameters Models - World and skinning matrices, etc Cameras – view, projection, viewport, etc Lights – type, color, direction, position,

etc UI

Presenting parameters to the artists

Shader Orchestration

Scenarios Image burn-in Generating shadow buffers Generating cube maps Accumulating lighting Deferred shading Composition operations Blur, bloom, tone-map, etc… Fur

Shader Orchestration

Themes Producing and consuming textures Same geometry, different shader Different geometry, same shader Scheduling passes

Shader Orchestration

Solutions Convention

first valid technique All passes sequentially

Profiles Name = Engine procedure

Scripts DXSAS 0.8x

Execution graph

Shader Orchestration

Execution graphs

Modular operations are nodes Graph traversal orders nodes Edges carry data between nodes Nodes may utilize render when

evaluated

Shader Orchestration

Multi-Postprocessor

Tile

Canvas In Canvas Out

6

Canvas In

Canvas Out

Num Tiles

64

Glow Trails

Canvas In Canvas Out

Num Images

Shader Orchestration

HDRRender

Brightfilter

ToneMap

BlurDownsample

Downsample

Combine

Simple Bloom

Shader OrchestrationScripting Execution graphs

Pro Simple languageEffect stackingCommand-oriented

More abstract renderingStrong typed nodes & edgesUse existing languages A higher level than effectsNodes can be swapped out for engine components easily

Con Yet another languageLoosely defined conceptsNot great for artistsUsed FX annotations2nd class citizen of FX, but embedded within it

More verboseHeavier tooling for authoring software

Modular Shaders Shader Fragment Libraries

Support #include Standard Includes

Ex. #include<Sas.fxh>

Environment defines #ifdef & #ifndef Ex. SAS_PRESENT

Optimize Shared parameters Leverage pre-shading

Count Your Blessings Detect modeling problems early “Bless” the artist’s model on request

Water tight UV issues – stretch, skew, tangency Exceeding bone & poly count Naming conventions Layer checks – LOD?

Count Your Blessings Visualize the problem

No cryptic messages: “Error on vert #13” Highlight

Wire-frame Transparent polygons Depth bias

Fix model if artist desires/authorizes

Validate in automated build pipeline

Art Debugged Visualize post-export data Allow the artist to validate post-export Preview mechanism can enable this

fast Internal micro-export pre-viewer

Visualizer Normals, tangents, binormals Edges, adjacencies, creases Points, Bounds, Transforms Texture visualizer (more on this later)

DCC Your Way Customize DCC apps to fit your

production Removed/block disallowed operations Move commonly used operations

forward Preview buttons Export buttons Blessing tools

Script common multi-step setups

A Pluggable Pipeline Pipeline infrastructure

Multi-App or Mono-App plug-in model Mix and match

Multi-App model Batch, perl, etc to tie apps together Always in&out of files

Plug-in model Script to tie plug-ins together All in-process Avoid continual file read-write

A Pluggable Pipeline DXOps

C# + Managed DirectX9 Framework discovers command & registers Dictionary for sharable models Dictionary for sharable textures

dxops.exe -s "load tiger.x;" -f "script1.txt" -s "save tiger2.x"

Where script1.txt reads:AddVData type:FLOAT3 usage:NORMAL usageIdx:0; GenNormals; AddVData type:FLOAT3 usage:TANGENT usageIdx:0; AddVData type:FLOAT3 usage:BINORMAL usageIdx:0; GenTangentframes; GenAdjacency;

War-Hardened Pipelines Stage0 = source art, not the export

Automate the export Encode export options in model or

externally Stage inputs

User should not modify stage outputs Use stage specific option files and

resources Prevent loss during overwrite

Incompatible changes Develop stage to upgrade old resources

War-Hardened Pipelines Separate features into small assets

Geometry, animations, material definitions, materials objects, particle systems, etc

Better asset/source control More sharing via references Different tools for different jobs

Max (model cages) ZBrush (model high-res) FxComposer (Materials) Maya (animations)

Pipeline Evolution

Khronos Group’s COLLADA COLLAborative Design Activity XML High adoption rate Modern features Designed for lossless exchange Extended user data

Not a run-time format

Testimonial and TipsFor

Content Creation and CommunicationMarcus GhalyGas Powered Games

Realizing You Need Tools Hitting milestones can mask

inefficiencies All the assets are in for the milestone so

our process works perfectly, right? Use of brute-force instead of

automation lengthy multi-step processes introduce

errors derivative art proliferates those errors

Automation, automation, automation while still giving control to the artists

The Producer/Consumer Model

Producers Realize that you are not the consumer

command line anyone? dev-centric documentation? Error: g_texCount <= texIndex

Error: Dude, you used too many textures.

So, find out what your consumer wants? How does the consumer think?

artist friendly terminology GUI / hotkeys tool layout

The Producer/Consumer Model

Consumers Realize that:

YOU ARE THE CONSUMER You have a say in how your tools work But in order for this to work:

YOU MUST GIVE FEEDBACK Explain the impact on your schedule Fight for your right to export

Totally Awesome Tools:

No-Cast

Building Materials

Successful Export

Unsuccessful Export

Model Viewer

Bone Name & Orientation

Multi-Animation Review

Normalmaps as Textures

Albedo Maps

Normals, Spec, and Reflectivity

The Works

Custom Shader Techniques

What’s Your Game Plan?

Random Acts of Technology Do you have a plan for tool

development Is there a timeline – micro and macro Is there an official method for tools

requests, bug fixing and tracking Does this method allow a back and

forth of ideas prototype with the artist early

How else are your teams interfacing with each other

Bad Conversations Art: My file didn’t export so I redid the

whole model. It took me 3 extra days. Dev: do you have to broken file? Art: no I threw it away

Consider an error reporting mechanism

Bad Conversations Art: I exported and it crashed! Damn it devs. Don’t use cryptic error

messages. Tell the artist if they scewed up if it is their fault otherwise both peoples time will be wasted tracking it down.