Extensible Rendering and Pre-visualization of Art

2. Extensible RenderingandPre-visualization of Art Daniel Horowitz NVIDIA Corporation Khronos COLLADA FX Workgroup Chairman

3. Efficient Next-Gen Content More content Done better Done sooner

4. 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

5. 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!

6. Breaking the Trend

7. 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

8. A Better Tools for the Job

9. 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

10. 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

11. 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

12. 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

13. The Many Shades of Preview

14. 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

15. Build to your schedule’s needs Plan to upgrade Cold Warm Warmer Hot Building a Better Material • Strings • Custom Attributes • Material definition plug-ins • Material object plug-ins

16. Building a Better Material Strings • Messy names • Parsing • Prone to spelling errors • Compared with options or without?

17. 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

18. 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

19. Building a Better Material

20. 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

21. 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?

22. The Shader You Never Knew

23. 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

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

25. Shader Orchestration Themes • Producing and consuming textures • Same geometry, different shader • Different geometry, same shader • Scheduling passes

26. Shader Orchestration Solutions • Convention • first valid technique • All passes sequentially • Profiles • Name = Engine procedure • Scripts • DXSAS 0.8x • Execution graph

27. Shader Orchestration Execution graphs • Modular operations are nodes • Graph traversal orders nodes • Edges carry data between nodes • Nodes may utilize render when evaluated

28. Shader Orchestration Multi-Postprocessor Canvas Out Canvas In Glow Trails Tile Canvas In Canvas Out Canvas In Canvas Out Num Images Num Tiles 6 64

29. Shader Orchestration Brightfilter Blur Downsample Downsample HDRRender Combine ToneMap Simple Bloom

30. Shader Orchestration

31. 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

32. 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?

33. 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

34. 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)

35. 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

36. 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

37. 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;

38. 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

39. 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)

40. 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

41. Testimonial and TipsForContent Creation and Communication Marcus GhalyGas Powered Games

42. 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

43. 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

44. 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

45. Totally Awesome Tools:

46. No-Cast

47. Building Materials

48. Successful Export

49. Unsuccessful Export

50. Model Viewer