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

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:155

Avg rating:3.0/5.0

Slides: 99

Provided by: steve1637

Category:

more less

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