Extensible Rendering and Pre-visualization of Art Daniel Horowitz NVIDIA Corporation Khronos COLLADA...
-
Upload
emory-lamb -
Category
Documents
-
view
225 -
download
0
Transcript of Extensible Rendering and Pre-visualization of Art Daniel Horowitz NVIDIA Corporation Khronos COLLADA...
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.