SIGGRAPH 2005 Course on Interactive Ray Tracing Session IV: Using Realtime Ray Tracing - PowerPoint PPT Presentation

Loading...

PPT – SIGGRAPH 2005 Course on Interactive Ray Tracing Session IV: Using Realtime Ray Tracing PowerPoint presentation | free to view - id: fdbb1-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

SIGGRAPH 2005 Course on Interactive Ray Tracing Session IV: Using Realtime Ray Tracing

Description:

SIGGRAPH 2005 Course on Interactive Ray Tracing Session IV: Using Realtime Ray Tracing – PowerPoint PPT presentation

Number of Views:114
Avg rating:3.0/5.0
Slides: 99
Provided by: steve1637
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: SIGGRAPH 2005 Course on Interactive Ray Tracing Session IV: Using Realtime Ray Tracing


1
SIGGRAPH 2005 Course on Interactive Ray
TracingSession IVUsing Realtime Ray Tracing
  • Ingo Wald
  • SCI Institute, University of Utah
  • wald_at_openrt.de

2
Using Realtime Ray Tracing
  • First of all Important announcement

3
Using Realtime Ray Tracing
  • First of all Important announcement
  • We want YOU to play around with RTRT
  • Not only listen in abstract way, but really play
    with it !
  • Write cool applications
  • Write cool shaders
  • Build a user-base of realtime ray tracing
  • Be early adapters and pioneers of this new
    technology
  • Come up with new ideas (and new problems) !

4
Using Realtime Ray Tracing
  • First of all Important announcement
  • We want YOU to play around with RTRT
  • Therefore
  • As of this SIGGRAPH, noncommercial
  • version of OpenRT publicly available !
  • More infos www.openrt.de

5
Getting OpenRT
  • Today Public (noncommercial) release
  • Only for noncommercial use !
  • Only available for PC/Linux (for now)
  • Slightly restricted (Scene size, no cluster-mode,
    )
  • Reason Limit potential sources of
    problems/questions/
  • Actual download
  • Available shortly after SIGGRAPH (next week)
  • For infos, see http//www.openrt.de
  • DONT SEND email to noncommercial_at_openrt.de

6
Outline
  • Using OpenRT (programming guide, tutorial,)
  • What is OpenRT
  • Writing frontend applications with/for OpenRT
  • Writing OpenRT shaders
  • Practical applications of Realtime Ray Tracing
  • using OpenRT, of course...

7
What is OpenRT ?
  • What is OpenRT ?

8
What is OpenRT ?
  • What is OpenRT ?
  • Actually, three different things

9
What is OpenRT ?
  • What is OpenRT ?
  • Actually, three different things
  • A Project The Saarland Realtime Ray Tracing
    Project

10
What is OpenRT ?
  • What is OpenRT ?
  • Actually, three different things
  • A Project The Saarland Realtime Ray Tracing
    Project
  • A specific realtime ray tracing rendering engine
  • Outcome of the OpenRT project
  • RTRT core, shared library with SDK

11
What is OpenRT ?
  • What is OpenRT ?
  • Actually, three different things
  • A Project The Saarland Realtime Ray Tracing
    Project
  • A specific realtime ray tracing rendering engine
  • Outcome of the OpenRT project
  • RTRT core, shared library with SDK
  • A Realtime Ray Tracing API
  • Not necessarily restricted to current rendering
    engine
  • SaarCOR/RPU soon also driven by same API.

12
What is OpenRT ?
  • What is it NOT ?
  • A animation program
  • Rather a rendering engine (available as library)
  • A global illumination renderer
  • Rather tool to build such
  • OpenRT in itself only a ray tracer
  • Not automatically global illumination/caustics
    etc(can write shaders, but dont have to)
  • Something that solves all your problems
  • it just makes solving them much easier.

13
Using Realtime Ray TracingPart I- Programming
Applications with OpenRT -
  • Ingo Wald
  • SCI Institute, University of Utah
  • wald_at_openrt.de

14
Using Realtime Ray TracingProgramming with
OpenRT
  • The OpenRT API
  • Architecture and design guidelines
  • Brief API overview
  • Tutorial Writing OpenRT applications
  • Performance optimizations
  • Tips Tricks

15
OpenRT APIMotivation
  • Sessions I-III Have discussed technical issues
    of realtime ray tracing
  • Fast ray traversal and intersection
  • Handling dynamic scenes
  • Fast CPU Implementation
  • Hardware
  • Together Have all TECHNICAL components of a
    complete rendering engine

16
OpenRT APIMotivation
  • How to make that technology available to the
    user(s) ?
  • Need an API
  • Lack of common API one of the historical problems
    of RT !
  • Hundreds of known/published improvements (better
    algorithms, optimizations, tricks, )
  • But usually each only implemented in one
    software package
  • Not directly available to others, slow spreading
    of technology
  • Result Many, many different ray tracers out
    there
  • but most use only tiny part of known
    optimizations/technology

17
OpenRT APIMotivation
  • Lack of common API one of the historical problems
    of RT !
  • Result Many, many different ray tracers out
    there
  • but most use only tiny part of known
    optimizations/technology

18
OpenRT APIMotivation
  • Lack of common API one of the historical problems
    of RT !
  • Result Many, many different ray tracers out
    there
  • but most use only tiny part of known
    optimizations/technology
  • Test Who in this room has implemented
  • A ray tracer ?

19
OpenRT APIMotivation
  • Lack of common API one of the historical problems
    of RT !
  • Result Many, many different ray tracers out
    there
  • but most use only tiny part of known
    optimizations/technology
  • Test Who in this room has implemented
  • A ray tracer ?
  • A kd-tree ?

20
OpenRT APIMotivation
  • Lack of common API one of the historical problems
    of RT !
  • Result Many, many different ray tracers out
    there
  • but most use only tiny part of known
    optimizations/technology
  • Test Who in this room has implemented
  • A ray tracer ?
  • A kd-tree ?
  • A kd-tree packet traverser ?

21
OpenRT APIMotivation
  • Lack of common API one of the historical problems
    of RT !
  • Result Many, many different ray tracers out
    there
  • but most use only tiny part of known
    optimizations/technology
  • Test Who in this room has implemented
  • A ray tracer ?
  • A kd-tree ?
  • A kd-tree packet traverser ?
  • SSE ?

22
OpenRT APIMotivation
  • Lack of common API one of the historical problems
    of RT !
  • Result Many, many different ray tracers out
    there
  • but most use only tiny part of known
    optimizations/technology
  • Test Who in this room has implemented
  • A ray tracer ?
  • A kd-tree ?
  • A kd-tree packet traverser ?
  • SSE ?
  • A (good) kd-tree construction (SAH) ?

23
OpenRT APIMotivation
  • Lack of common API one of the historical problems
    of RT !
  • Result Many, many different ray tracers out
    there
  • but most use only tiny part of known
    optimizations/technology
  • Test Who in this room has implemented
  • A ray tracer ?
  • A kd-tree ?
  • A kd-tree packet traverser ?
  • SSE ?
  • A (good) kd-tree construction (SAH) ?
  • Got the point ?

24
OpenRT APIMotivation
  • (Standardized) APIs are crucial for new
    technologies
  • Allow to build a common user base
  • Knowledge base of how to use the technology
  • Allows users to abstract from underlying
    technology
  • Can become productive without having to
    understand all details
  • Allows technicians to continually improve the
    technology
  • If hidden behind API, user wont even see any
    changes
  • Technical improvements directly reach the users
  • If similar to exiting/known APIs, yield steep
    learning curve
  • ? Need to define a (quasi-)standard API for RTRT

25
OpenRT APIMotivation
  • Problem What is a good API for realtime ray
    tracing
  • Existing ray tracing APIs Inherently
    offline(POVRay, RenderMan,)
  • Existing realtime APIs
  • Not designed to support advantages/demands of ray
    tracing
  • Historically all designed for rasterization
  • Need to build our own

26
OpenRT APIDesign Goals
  • As powerful as RenderMan etc.
  • Offer all features of ray tracing (shaders,
    complex geometry, )
  • As similar to OpenGL as possible
  • Except where it doesnt make sense
  • Allows for easy migration of existing OpenGL
    knowledge
  • Be as low-level as possible ? Flexibility
  • Optimally support existing RTRT implementations
  • Suitable for parallelization, handling dynamic
    scenes,
  • But Hide technological aspects (distribution,
    HW) where possible
  • Users just dont (want to) care about
    distribution, different kd-trees,

27
OpenRT APIDesign Goals
  • Fundamental design decision Differentiate
    between application API and shader API
  • RenderMan-like for shader writers
  • C framework, shader classes, recursive ray
    tracing
  • OpenGL like for application programmers
  • Just load and use shaders like e.g., display
    lists
  • Describing geometry etc. like with OpenGL

28
OpenRT Core Application APIVery much like
OpenGL
  • Geometry Almost exactly like OpenGL
  • Vertices rtVertex3f(), rtNormal3f(),
    rtColor3f(),
  • Triangles rtBegin(RT_TRIANGLES/RT_POLYGON/)
    rtEnd()
  • Typical OpenGL transformation operations
    available
  • rtPushMatrix(), rtRotatef(), rtLoadMatrixf(),
  • But No Immediate-mode rendering
  • Rather Geometry objects
  • (Remember part II on dynamic scenes ?)

29
OpenRT Core Application APIVery much like
OpenGL
  • Geometry objects
  • Define/use like OpenGL display lists
  • rtGenObjects(), rtNewObject(), rtEndObject()
  • Each object gets its own ADS
  • ADS built once on object definition (invisible to
    user)
  • Objects lateron instantiated rtInstantiate()
  • Like calling a display list
  • Instance generated with current transformation
    stack
  • Support framework for dynamic scenes (see Part
    II)
  • Difference to OpenGL MUST use objects

30
The OpenRT APIDefining Geometry
  • A simple example Trivial for any OpenGL
    programmer int objID rtGenObjects(objID,1) r
    tNewObject(objID,RT_COMPILE)
    rtPushMatrix() rtTranslatef(1,0,0)
    rtBindShader(shaderID)
    rtBegin(RT_TRIANGLES) rtVertex3f(.)
    rtNormal3f()
    rtEnd() rtPopMatrix() rtEndObject()

31
OpenRT Core Application APIVery much like
OpenGL
  • Apart from Geometry
  • Texture objects
  • Exactly like OpenGL Shaders access via tex.ID
  • Shader objects
  • All appearance-related operations done via
    shaders!
  • Camera shaders, light shaders, surface shaders,
    environment,
  • No explicit handling of lights or materials any
    more
  • NO rtMaterialf, rtLightf, etc. ? Use shaders
    instead
  • Well-known helper functions
  • rtPerspective(), rtLookAt(), rtSwapBuffers(),
    rtFlush()

32
OpenRT Core Application APILoading and using
shaders
  • Similar to Stanford Prog.Shading API
  • Dynamically loaded from DLLs/.sos
  • rtGenShaderClasses(cID,1)
  • rtNewShaderClass(cID, simpleShader,
    libSimpleShader.so)
  • rtGenShaders(ID,1)
  • rtShader(ID)
  • App/shader communication
  • Shader classes export parameters (by name)
  • rtDeclareParameter(diffuseColor,
    PER_SHADER,offsetof(),sizeof())
  • App requests handle to shaders parameter
    writes it
  • int diffuseHandle rtParameterHandle(diffuseColo
    r)
  • rtParameter3fv(diffuseHandle,red)

33
Writing OpenRT applicationsUsing light shaders
  • Lights in OpenRT
  • No explicit light calls (like rtLight())
  • ALL realized via light shaders
  • Using light shaders
  • Generate just like surface shaders
  • Need to know light shader parameters
  • E.g., PointLight shader position,
    intensity, atten,
  • Typical light shaders (point,spot,directional)
    already included
  • Once generated, call rtUseLight(RT_GLOBAL,lightID
    )

34
Writing OpenRT applicationsOther kinds of shaders
  • Other kinds of shaders
  • Environment shader
  • Camera shader
  • Rendering Object
  • Handled just like light shaders
  • Load, parameterize, call rtUseltgt(ID)
  • Default implementations already available

35
Writing OpenRT applicationsTextures
  • Handling textures Two steps
  • Step 1 Declare the texture object
  • just like OpenGL
  • rtTexImage2D(texID,)
  • Step 2 Pass texture ID to shader (as parameter)
  • rtBindShader(shaderID)
  • int handle rtParameterHandle(textureID)
  • rtParameter1i(handle,texID)
  • Multiple textures per shader no problem

36
Writing OpenRT applicationsRendering a frame
  • Once all geometry/lights/etc are set up Render
    Frame
  • Calling rtSwapBuffers() renders currently
    specified scene
  • Into frame buffer provided by application
  • Note In the distributed variant, rtSwapBuffers()
    has one frame latency
  • In that case, always returns previous frame !
  • Once frame is rendered Display via e.g. OpenGL
  • Simple X11-based helper library (RTUT)available
    as well

37
Writing OpenRT applicationsAnimating the scene
  • Animating lights, shaders, camera, trivial
  • Just change its respective shader
    parameters rtBindLight(lightID)
    rtParameter3f(LIGHT_POSITION,newPosition)
  • Animating geometry Re-instantiate object(s) with
    new transformation matrix
  • See previous talk on Handling Dynamic Scenes
  • Simplest (most typical) way
  • Delete all instances every frame
    (rtDeleteInstances())
  • Re-traverse Scenegraph
  • Instantiate all objects with updated
    transformation matrix

38
Writing OpenRT applicationsAnimating the scene
  • More advanced way of doing that
  • Change transformation of only a single
    instance rtLoadMatrixf(newTransformation) r
    tSetInstanceXfm(instID)
  • Much more efficient, but often harder to
    implement
  • Keyframe animation
  • Build one object for every timestep. Then, per
    frame rtDeleteInstance(instID) rtLoadMatrixf
    (currentTransform) instID
    rtInstantiate(objIDcurrentTimeStep)

39
OpenRT Core Application APIComparison to OpenGL
  • Biggest difference to OpenGL Semantics
  • Everything is explicit!
  • E.g., rtPerspective/rtLookAt DIRECTLY set the
    camera,
  • It does NOT modify the transformation stack
  • Frame semantics vs. immediate-mode
  • Any state change effective ONLY at end of frame
  • I.e., changing a shader applies ALSO to already
    specified triangles
  • Lots of side effects
  • Intentional, but sometimes confusing to
    (ex-)OpenGLers

40
OpenRT Core Application APIComparison to OpenGL
  • Everything is world space
  • NOT geometry transformed to camera space
  • RATHER camera explicitly defined in world space
  • Everything is retained mode
  • Until explicitly deleted, objects/instances/shader
    s/etc stay active in successive frames
  • NO re-instantiation per frame necessary (unlike
    disp.lists)
  • Framebuffer operations dont make sense
  • Stipples, masks, blending, not supported at
    all.
  • Rather Use shaders

41
Using Realtime Ray TracingProgramming with
OpenRT
  • A brief tutorial
  • Initializing
  • Defining geometry
  • Loading and using shaders
  • Rendering a frame
  • Animating the scene
  • Performance optimizations
  • Tips Tricks

42
Using Realtime Ray TracingProgramming with
OpenRT
  • A brief tutorial ? extended slides
    (www.openrt.de)
  • Initializing
  • Defining geometry
  • Loading and using shaders
  • Rendering a frame
  • Animating the scene
  • Performance optimizations
  • Tips Tricks ? extended slides

43
Performance optimizations
  • Key to good performance
  • Minimize state changes
  • Reason All state changes have to be transferred
    across network to clients ? VERY costly
  • Minimize number of objects/instances
  • Core performance best for few, large objects
  • Good kd-trees cant help if geometry is not in
    same object!
  • Use lightweight applications
  • Dont spend 90 of time in GUI and scene graph
    trav.!

44
Performance optimizations
  • Minimizing state changes
  • Dont delete/re-instantiate all instances per
    frame
  • Rather selectively update only changed instances
  • Dont re-issue data that has not changed
  • Shader parameters, lights positions,
  • Often need to track current state in application
  • Remember If not explcitly changed, everything is
    still available in next frame
  • Shaders, objects, shader parameters,

45
Performance optimizations
  • Minimize number of objects
  • Typical scene graph problem Lots of small nodes
  • Dont generate a new object for every 10
    triangles !
  • Generally Put all primitives in same object,
  • except if they are to to be moved differently
  • Need to combine small sub-graphs to one object
  • Often coding effort for existing scene graphs
  • but VERY important

46
Tips Tricks
  • Some typical tipstricks when using OpenRT
  • Progressive Supersampling
  • Using (pre-computed) binary scene dumps
  • Subsampling during motion

47
Tips Tricks
  • Some typical tipstricks when using OpenRT
  • Progressive Supersampling
  • OpenRT also supports accumulation buffer
    concept
  • During motion use plain rtSwapBuffers()
  • At camera standstill Use rtAccum() to
    accumulate images computed with different pixel
    samples
  • Result Fast rendering during interaction
  • But Aliasing quickly disappears after end of
    interaction
  • Can do similar for smooth shadows, glossyness,

48
Tips Tricks
  • Using binary object dumps
  • OpenRT supports binary dumps of complete
    objects
  • Including kd-trees and geometry
  • Next time app starts, just load/map the binary
    objects
  • Much faster startup times, no need to build
    kd-trees
  • In particular, can mmap the binaries
  • No need to even load the data into application
  • Can copy binaries to clients local disks, map
    from there
  • No need to send full geometry every frame!

49
Tips Tricks
  • Subsampling during motion
  • If your machine/cluster is too slow
  • Let OpenRT render at reduced resolution during
    motion
  • Use OpenGL to zoom image to fullscreen
  • blurry, but faster
  • During camera standstill, switch to fullscreen
    ray tracing
  • Similar to progressive supersampling

50
OpenRT API Lessons learned
  • Powerful Lots of existing applications
  • Including industrial VR software
  • All realized exclusively via the API
  • Distribution framework completely hidden
  • Application often doesnt know at all if its
    running standalone or distributed
  • Programmer doesnt have to care
  • Except performance (see below)
  • Except file names (might be different on
    clients!)

51
OpenRT API Lessons learned
  • Experience Easily adopted by new users
  • In particular, if they already know OpenGL
  • Most particular problem Different semantics
  • Usually quickly accepted/used to
  • Easy to use and learn Very impressive results by
    students
  • Difference between shader/application API works
    well
  • Can write shaders completely independent of
    application
  • Can share shaders amond different applications
  • But App needs to be aware of shaders parameters

52
Using Realtime Ray TracingPart II- Writing
OpenRT Shaders -
  • Ingo Wald
  • SCI Institute, University of Utah
  • wald_at_openrt.de

53
Writing OpenRT Shaders
  • Purpose of this talkA tour de force of OpenRT
    shaders
  • Brief explanation on how to write OpenRT shaders
  • Only the basics
  • No fancy, cool images here, rather code bits and
    infos
  • Play around yourself

54
Basics The Shader Framework
  • Important OpenRT is NOT a monolithic system
  • Instead Most functionality in special
    modules/plugins
  • OpenRT consists of different layers
  • Ray Tracing core (define geometry, shoot indiv.
    rays)
  • The shader framework
  • Rendering Object renders frame (calls surface
    shaders)
  • Surface shaders call back to light shaders
  • and recursively to other surface shaders
  • Plus Camera shaders, environment shader,
  • Typical default shaders already available

55
OpenRT coreThe Ray State Concept
  • Ray State (RTState)
  • Keeps all ray- and hitpoint-specific data
  • Origin, direction, hit distance, hit
    object/instance, shaded color,
  • Not directly visible to user
  • Completely hides/encapsulates implementation
  • Only accessible via special OpenRTS functions
  • rtsSetRay(state,origin,direction,maxDist),
  • rtsFindShadingNormal(state,normal)
  • Also keeps internal data
  • Must be correctly initialized before use (e.g.
    from parent ray)

56
Shader FrameworkGeneral
  • OpenRT core pure C interfaceOpenRTS shader
    framework C
  • Shader plugins compiled to/loaded from .sos/DLLs
  • Automatically done by OpenRT upon
    rtShaderClass()
  • All classes in shader framework derived from
    RTPlugin
  • Encapsulates infrastructure to
  • register itself and parameters to the OpenRT
    system
  • dynamically load from shared libraries
  • work within OpenRTs parallelization framework

57
Shader FrameworkRTPlugin base class
  • The RTPlugin base class
  • class RTPlugin virtual void
    NewFrame() virtual void Init() virtual void
    Register()
  • Init() Initialize self directly upon loading
  • NewFrame() Called once per frame
  • Allows for doing per-frame precomputations
  • Register() Register shader parameters to OpenRT
  • See Part I

58
Shader FrameworkThe Rendering Object
  • Basic ingredient is the Rendering Object
  • Main functionality Render complete frame
  • Standalone implementation RenderFrame()
  • Distributed implementation RenderTile()
  • Dont need to know details on rendering object
  • Can usually use existing rendering object
  • R.Obj. can do MUCH more (virtually anything)
  • Frameless rendering, render cache, rasterization,
    adaptive sampling, frame post-processing
    (tonemapping, filtering),

59
Shader FrameworkSurface Shaders
  • Purpose Given a ray (state), compute its color
  • Realization RTShader class
  • class RTShader public RTPlugin virtual void
    Shade(RTstate state)
  • Surface shader computes color of the given ray
  • Including shooting secondary rays, calling light
    shaders, etc.
  • and returns color via rtsReturnColor(state,colo
    r)
  • Writing a new shader
  • Derive from RTShader, overwrite Shade()-function
  • Compile to libltShaderNamegt.so, include in
    LD_LIBRARY_PATH

60
Surface ShadersShading a ray
  • Can use arbitrary C/C code
  • Helper classes available (Vector, Matrix, )
  • Use rts functions to operate on given state
  • rtsFindShadingNormal(),rtsGetHitDistance(),rtsGetS
    hader(),
  • Lighting Query incident light onto the hitpoint
  • By calling rtsIlluminate(lightID,state,ptr)
  • Surface shader can pass additional data to light
    shader (ptr)
  • rtsIlluminate() returns light samples for given
    hitpoint
  • Consisting of direction, distance, and incident
    radianceCan check shadow/visibility of light via
    rtsOccluded(state)

61
Shader FrameworkLight Shaders
  • Purpose Deliver light samples to surface shaders
  • On rtsIlluminate, OpenRT calls respective light
    shader
  • Light shader Derived from RTLightShader
  • class RTLight public RTPlugin virtual void
    Illuminate(RTstate state, void ptr)
  • RTLightIlluminate(state,ptr)
  • Compute light sample, return in state
  • Typical pre-defined light shaders available
  • RTPointLight, RTSpotLight, RTDirectionalLight,

62
A Simple Example
  • So far Have discussed concepts on abstract
    level.
  • Now Give practical examples
  • Steps to perform to implement a shader
  • Derive a new shader class from RTShader
  • Declare, init, and export its shader parameters
  • Implement its Shade() function
  • Compile it to a shared library

63
Example 1 Simple Headlight shader
  • Very simple shading modelC (I_amb
    (1-I_amb)(N.D))Rd Rd diffuse surface color
    (three floats) I_amb ambient intensity N
    surface normal (shading normal) D Ray direction

64
Example 1 Simple Headlight shader
  • Step 1 Declaring the shader class
  • // include base header filesinclude
    OpenRTS/RTS.hxxinclude OpenRTS/RTShader.hxx
    struct RTSimple public RTShader float
    ambient R3 diffuseColor void Init() ambient
    .3 diffuseColor .5 // declare
    under the shader class name SimplertDeclareShad
    er(RTSimple,Simple)

65
Example 1 Simple Headlight shader
  • Step 2 Declaring the shaders parameters
  • void RTSimpleRegister() rtDeclareParameter(
    diffuseColor, PER_SHADER, memberoffset(di
    ffuseColor), sizeof(diffuseColor)) rtDeclarePara
    meter( ambient, PER_SHADER, memberoffset(
    ambient), sizeof(ambient))

66
Example 1 Simple Headlight shader
  • Step 3 Implementing the Shade() function
  • void RTSimpleShade(RTstate state) R3
    C,D,N // query rays direction and hits
    normal rtsGetRayDirection(state,D) Normalize(D)
    // might not be necessary rtsFindShadingNormal
    (state,N) //compute rays color C (ambient
    (1-ambient)(ND)) diffuseColor // return
    color to calling shader (via state) rtsReturnColo
    r(state,C)

67
Example 1 Simple Headlight shader
  • Step 4 Compile to a shared library
  • Save to Simple.cxx
  • Compile as shared library
  • Intel ICC8.1icc Simple.cxx o libSimple.so
    shared rdynamic O3 I ltgt
  • GCC (3.4.2 and higher)g Simple.cxx o
    libSimple.so shared fPIC O3 I ltgt
  • Make sure to pass the correct include directories
  • MAKE SURE THE .SO IS IN YOUR LIBRARY PATH!
  • Thats it

68
Example 2 A typical Phong Shader
  • Previous example was very simple
  • Now Add lights and shadows
  • First Declare SimplePhong class as before
  • Declare diffuseColor, specularColor,
    exponent, etc
  • Will only consider the Shade() function

69
Example 2 A typical Phong Shader
  • The shade function virtual void Shade(RTstate
    state) // initialize C ambientColor rts
    FindHitPosition(state,hitPos) rtsFindShadingNor
    mal(state,normal) // create new state for
    light samples RTState lightSample rtsInitStat
    e(state,lightSample) // query light
    sources RTvoid light int lights
    rtsGlobalLights(light)

70
Example 2 A typical Phong Shader
  • Now, iterate over light sources for (int
    i0iltlightsi) rtsSetRayOrigin(lightSampl
    e,hitPos) bool ok rtsIlluminate(lightSample,l
    ighti,NULL) if (!ok) // maybe light points
    away from hitpoint continue // ltMARKgt //
    Query light sample direction and radiance R3
    L,I rtsGetColor(lightSample,I) rtsGetRayDir
    ection(lightSample,L) // do the actual
    shading C diffuseColor (N L) ..

71
Example 2 A typical Phong Shader
  • Adding ray traced shadows
  • Extremely simple Just replace ltMARKgt
    with // Check for shadow if
    (rtsOccluded(lightSample)) continue
  • Thats all there is to do
  • Adding reflections/refraction
  • As simple as C rtsTrace(secondaryRayState)(
    with correctly set secondary ray)

72
OpenRT Shader ExampleAdvanced shading
  • Once basic framework exists, shadows etc trivial
  • See online tutorials for full implementation
  • www.openrt.de
  • Extension to advanced shading very simple
  • Transparent shadows, secondary rays,
  • Texturing (multiple textures, float-textures,
    alpha-textures,)
  • Area light shaders, procedural shaders,
  • are all supported

73
Advanced Shading w/ OpenRT Typical OpenRT Shaders
74
Cost of Shading
  • First of all Shading is COSTLY
  • Often more costly than tracing the rays
  • Take care to write optimized shader code !!!
  • The fastest ray tracing core cant help shading
    cost
  • Minimize shading overhead
  • Minimize number of rays shot

75
Performance ConsiderationsMinimizing of rays
shot
  • Tracing rays is fast, but cost is linear in rays
  • CHECK before you trace a ray
  • Dont trace shadow rays to lights that wont be
    used, anyway(e.g., light on wrong side, light
    too far away, )
  • Dont calculate shadows on a black (or
    transparent) surface
  • For more complex shaders (glass, transparency)
  • Tracking rays pixel contribution can avoid
    explosion of ray tree (already done in RTX
    shader package)
  • But tracking itself is costly

76
Performance ConsiderationsMinimizing Shading
Overhead
  • Even w/o sec. rays, shading overhead can be
    excessive
  • IMPORTANT TO TAKE HOME FOR MOST SHADERS, SHADING
    MORE COSTLY THAN OPENRT TRACING THE RAY !!!!
  • ? Spend some time on optimizing your shaders
    implementation
  • Absolutely avoid system calls in the Shade() fct
  • I/O, logging, thread locks, new/delete,
    free/malloc,
  • Precompute data in NewFrame() wherever possible
  • Avoid code like if (diffuseColor.x gt .1
    diffuseColor.y gt .1 )
  • Rather use if (diffuseOK) with precomputed
    diffuseOK value

77
Performance ConsiderationsMinimizing Shading
Overhead
  • Minimize calls to rtsFind(), rtsGet() etc.
  • Results of these calls are NOT cached internally
  • In particular, all rtsFind calls usually involve
    expensive computations
  • Dont multiply compute data that didnt change
  • Dont compute shading normal and hit position in
    the inner loop!
  • Avoid unnecessary Normalizes
  • Each normalize 3MUL, 2ADD, 1DIV, 1SQRT!
  • Typical CPUs at most 40M sqrt()s/sec (? max.
    1/pixel_at_40fps...)
  • Normal returned by rtsFindShadingNormal is
    normalized already
  • Ray direction usually normalized as well
  • depends on your shaders

78
Performance ConsiderationsMinimizing Shading
Overhead
  • Avoid all operations that dont have to be done
  • I.e., dont use C max(0,NL)
    PhongShade(N,L)
  • But rather if (NL gt 0.f) C
  • Take care of small optimizations as well
  • Float vs. double, use cosf/sqrtf, not cos/sqrt
  • Always write float constants as 1.0f (not just
    1) etc
  • Use inlines and consts for helper functions
  • Compile with optimization (-O3 at least) and
    without debug options
  • For VERY compute intensive shaders Use SIMD
  • Finally Profile, optimize, test, profile,
    optimize, test,

79
Shading in OpenRTSummary
  • Have described overall OpenRT architecture
  • Shader framework
  • Interoperation of different shader types
  • Have described complete workflow for writing
    OpenRT shaders (based on simple example)
  • Have briefly discussed performance issues
  • Entirely sufficient for writing your own shaders

80
Shading in OpenRTSummary
  • The best way to really understand how it works
  • Have a look at the shader tutorialshttp//www.ope
    nrt.de/
  • Write your own shaders
  • PLAY with it !

81
Using the OpenRT System - A Users (not
Programmers) Perspective -
  • Ingo Wald
  • SCI Institute, University of Utah
  • wald_at_openrt.de

82
The Users Perspective
  • 6 Examples
  • OpenRT based games
  • Non-polygonal applications
  • Massively complex CAD datasets
  • Outdoor rendering/Landscape visualization
  • Interactive Global Illumination
  • Photorealistic VR in industrial design reviews

83
OpenRT Based Games
  • Quake/RT project Daniel Pohl, Jörg Schmittler
  • Oasen Tim Dahmen et al.
  • All use OpenRT system (only API, no source)
  • Both interactive (need cluster, though)

84
Non-polygonal Applications
  • Direct support for non-polygonal primitives
  • Freeform surfaces, isosurfaces, points, volumes,

Medical imaging Visible female, 1PC
Point based Ray Tracing 24M points, 1PC, 2fps
Scientific visualization Lawrence Livermore
isosurface (8GB)
85
Non-polygonal Applications
  • Direct support for non-polygonal primitives
  • Freeform surfaces, isosurfaces, points, volumes,

Direct ray tracing of freeform surfaces Mercedes
C Class, 320,000 Bézier patches
86
Massively Complex CAD Datasets
  • Rendering directly out of CAD database
  • No simplification etc necessary
  • Including advanced shading
  • Project with Boeing and SGI (see the booth!)
  • Using PCs or SGI Altix/Prism

Boeing 777 - 350M triangles
87
Outdoor Rendering
  • Outdoor scenes Lots of (instantiated) geometry
  • Plus Costly shading
  • Transparent leaves, alpha textures, lighting,

Sunflowers scene (Oliver Deussen, Uni
Konstanz) 1B triangles, 1 light source (sun)
88
Outdoor Rendering
  • Outdoor scenes Lots of (instantiated) geometry
  • Plus Costly shading
  • Transparent leaves, alpha textures, lighting,

Forest scene (Oliver Deussen, Uni Konstanz)
1.5B triangles, HDR env. lighting
89
Interactive Global Illumination
  • All examples interactive (cluster)
  • Can edit scene, lights,
  • But Shaders require source access(packets,
    SSE, )

90
Photorealistic VR / Industrial Design Reviews
  • In industrial/productive use already today
  • VW, BMW, Audi, DaimlerChrysler,
  • Exact simulation of glass, shadows,
  • All driven using inView software
  • Of course, built on OpenRT (API only)

91
Part IV Summary
  • Discussed OpenRT API
  • What is OpenRT, how does it work
  • Writing OpenRT applications
  • Writing OpenRT shaders
  • Using the OpenRT system
  • Several practical applications

92
Part IV Summary
  • Discussed OpenRT API
  • What is OpenRT, how does it work
  • Writing OpenRT applications
  • Writing OpenRT shaders
  • Using the OpenRT system
  • Several practical applications

93
Part IV Conclusion
  • What you should take home with you
  • OpenRT is
  • immensely powerful (remember the applications)
  • easy to learn (games written by students)
  • You can do incredible things with it (YOU can)
  • Shading is (most often) main cost factor
  • There are practical applications of it today
    also for end users
  • Once again Check out what it can do for you !
  • Try it out (www.openrt.de)

94
SIGGRAPH 2005 Course on Interactive Ray
TracingThe End ?
95
Entire Course Summary
  • Part I Motivated RTRT, explained basics of RT
  • Part II
  • Have described SW aspects of fast RT
  • Use KD-Trees !
  • and use GOOD kd-trees !
  • Use SIMD
  • Use Packets
  • Parallelization works very well (both SHM and
    clusters)
  • Some kinds of dynamics can be done well even
    today!
  • But general HUGE problem

96
Entire Course Summary
  • Part III
  • Visualization applications using RTRT
  • Handling massive models
  • RTRT ideally suited for massive models (also
    volumes)
  • Hardware approaches under way
  • Both systems-level, GPUs, RPUs,
  • Part IV
  • Discussed OpenRT API
  • Can use RTRT for REAL apps even today
  • Still lots to do on the transition front

97
Entire Course Summary
  • RT is a fundamental operation for future graphics
  • You can do a LOT with it today
  • There is still a lot to do

98
Part IV The End
  • Any Questions ?
  • (all speakers up, please)
About PowerShow.com