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. Ingo Wald SCI Institute, University of Utah [email protected]. Using Realtime Ray Tracing. First of all: Important announcement. Using Realtime Ray Tracing. First of all: Important announcement - PowerPoint PPT PresentationTRANSCRIPT
SIGGRAPH 2005 Course on Interactive Ray Tracing
Session IV:Using Realtime Ray Tracing
SIGGRAPH 2005 Course on Interactive Ray Tracing
Session IV:Using Realtime Ray Tracing
Ingo Wald
SCI Institute, University of Utah
Using Realtime Ray TracingUsing Realtime Ray Tracing
• First of all: Important announcement
Using Realtime Ray TracingUsing 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…) !
Using Realtime Ray TracingUsing 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
Getting OpenRTGetting 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 [email protected]
OutlineOutline
• 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...
What is OpenRT ?What is OpenRT ?
What is OpenRT ?
What is OpenRT ?What is OpenRT ?
What is OpenRT ?
• Actually, three different things
What is OpenRT ?What is OpenRT ?
What is OpenRT ?
• Actually, three different things
– A Project: The Saarland Realtime Ray Tracing Project
What is OpenRT ?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
What is OpenRT ?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.
What is OpenRT ?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 don’t have to…)
• Something that solves all your problems…
– … it just makes solving them much easier.
Using Realtime Ray Tracing
Part I:- Programming Applications
with OpenRT -
Using Realtime Ray Tracing
Part I:- Programming Applications
with OpenRT -
Ingo Wald
SCI Institute, University of Utah
Using Realtime Ray Tracing:Programming with OpenRTUsing Realtime Ray Tracing:Programming with OpenRT
• The OpenRT API
– Architecture and design guidelines
– Brief API overview
• Tutorial: Writing OpenRT applications
• Performance optimizations
• Tips & Tricks
OpenRT APIMotivationOpenRT 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
OpenRT APIMotivationOpenRT 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
OpenRT APIMotivationOpenRT 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
OpenRT APIMotivationOpenRT 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 ?
OpenRT APIMotivationOpenRT 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 ?
OpenRT APIMotivationOpenRT 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 ?
OpenRT APIMotivationOpenRT 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 ?
OpenRT APIMotivationOpenRT 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) ?
OpenRT APIMotivationOpenRT 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 ?
OpenRT APIMotivationOpenRT 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 won’t 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
OpenRT APIMotivationOpenRT 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
OpenRT APIDesign GoalsOpenRT 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 doesn’t 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 don’t (want to) care about distribution, different kd-trees, …
OpenRT APIDesign GoalsOpenRT 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
OpenRT Core Application API:Very much like OpenGL…OpenRT Core Application API:Very 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 ?)
OpenRT Core Application API:Very much like OpenGL…OpenRT Core Application API:Very 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
The OpenRT API:Defining GeometryThe OpenRT API:Defining Geometry
• A simple example: Trivial for any OpenGL programmerint objID;rtGenObjects(&objID,1);rtNewObject(objID,RT_COMPILE); rtPushMatrix(); rtTranslatef(1,0,0); rtBindShader(shaderID);
rtBegin(RT_TRIANGLES); rtVertex3f(….); rtNormal3f(…);
… rtEnd();
rtPopMatrix(); rtEndObject();
OpenRT Core Application API:Very much like OpenGL…OpenRT Core Application API:Very 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(…)
OpenRT Core Application API:Loading and using shadersOpenRT Core Application API:Loading and using shadersSimilar to Stanford Prog.Shading API
• Dynamically loaded from DLLs/.so’s:
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 shader’s parameter & writes it
int diffuseHandle = rtParameterHandle(“diffuseColor”);
rtParameter3fv(diffuseHandle,&red);
Writing OpenRT applicationsUsing light shadersWriting 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)”
Writing OpenRT applicationsOther kinds of shadersWriting OpenRT applicationsOther kinds of shaders
• Other kinds of shaders
– Environment shader
– Camera shader
– Rendering Object
• Handled just like light shaders
– Load, parameterize, call “rtUse<…>(ID)”
• Default implementations already available
Writing OpenRT applicationsTexturesWriting 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…
Writing OpenRT applicationsRendering a frameWriting 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
Writing OpenRT applicationsAnimating the sceneWriting OpenRT applicationsAnimating the scene
• Animating lights, shaders, camera, … trivial
– Just change it’s respective shader parametersrtBindLight(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
Writing OpenRT applicationsAnimating the sceneWriting OpenRT applicationsAnimating the scene
• More advanced way of doing that:
– Change transformation of only a single instance:rtLoadMatrixf(&newTransformation);rtSetInstanceXfm(instID);
– Much more efficient, but often harder to implement
• Keyframe animation:
– Build one object for every timestep. Then, per frame:rtDeleteInstance(instID);rtLoadMatrixf(¤tTransform);instID = rtInstantiate(objID[currentTimeStep]);
OpenRT Core Application API:Comparison to OpenGLOpenRT Core Application API:Comparison 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-)OpenGL’ers
OpenRT Core Application API:Comparison to OpenGLOpenRT Core Application API:Comparison 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/shaders/etc stay active in successive frames
– NO re-instantiation per frame necessary (unlike disp.lists)
• Framebuffer operations don’t make sense
– Stipples, masks, blending, … not supported at all.
– Rather: Use shaders
Using Realtime Ray Tracing:Programming with OpenRTUsing Realtime Ray Tracing:Programming with OpenRT
• A brief tutorial
– Initializing
– Defining geometry
– Loading and using shaders
– Rendering a frame
– Animating the scene
• Performance optimizations
• Tips & Tricks
Using Realtime Ray Tracing:Programming with OpenRTUsing Realtime Ray Tracing:Programming 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
Performance optimizationsPerformance 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 can’t help if geometry is not in same object!
• Use lightweight applications
– Don’t spend 90% of time in GUI and scene graph trav.!
Performance optimizationsPerformance optimizations
Minimizing state changes:
• Don’t delete/re-instantiate all instances per frame
– Rather: selectively update only changed instances
• Don’t 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, …
Performance optimizationsPerformance optimizations
Minimize number of objects
• Typical scene graph problem: Lots of small nodes
– Don’t 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
Tips & TricksTips & Tricks
Some typical tips&tricks when using OpenRT:
• Progressive Supersampling
• Using (pre-computed) binary scene dumps
• Subsampling during motion
Tips & TricksTips & Tricks
Some typical tips&tricks 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, …
Tips & TricksTips & 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 client’s local disks, map from there
No need to send full geometry every frame!
Tips & TricksTips & 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
OpenRT API: Lessons learnedOpenRT API: Lessons learned
• Powerful: Lots of existing applications
– Including industrial VR software
– All realized exclusively via the API
• Distribution framework completely hidden
– Application often doesn’t know at all if it’s running standalone or distributed
– Programmer doesn’t have to care
– Except: performance (see below)
– Except: file names… (might be different on clients!)
OpenRT API: Lessons learnedOpenRT 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
Using Realtime Ray Tracing
Part II:- Writing OpenRT Shaders -
Using Realtime Ray Tracing
Part II:- Writing OpenRT Shaders -
Ingo Wald
SCI Institute, University of Utah
Writing OpenRT ShadersWriting OpenRT Shaders
• Purpose of this talk:A “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…
Basics: The Shader FrameworkBasics: 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
OpenRT core:The Ray State ConceptOpenRT core:The 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)
Shader FrameworkGeneralShader FrameworkGeneral
• OpenRT core: pure “C” interfaceOpenRTS shader framework: “C++”
• Shader plugins compiled to/loaded from .so’s/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 OpenRT’s parallelization framework
Shader FrameworkRTPlugin base classShader 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
Shader FrameworkThe Rendering ObjectShader FrameworkThe Rendering Object
• Basic ingredient is the “Rendering Object”
– Main functionality: Render complete frame
• Standalone implementation “::RenderFrame(…)”
• Distributed implementation “::RenderTile(…)”
– Don’t 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), …
Shader FrameworkSurface ShadersShader FrameworkSurface Shaders
• Purpose: Given a ray (state), compute it’s 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,color);”
• Writing a new shader:
– Derive from RTShader, overwrite Shade()-function
– Compile to “lib<ShaderName>.so”, include in LD_LIBRARY_PATH
Surface ShadersShading a raySurface ShadersShading a ray
• Can use arbitrary C/C++ code
– Helper classes available (Vector, Matrix, …)
– Use “rts” functions to operate on given state
• rtsFindShadingNormal(),rtsGetHitDistance(),rtsGetShader(),…
• 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)”
Shader FrameworkLight ShadersShader 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);
};
• “RTLight::Illuminate(state,ptr)”
– Compute light sample, return in ‘state’
• Typical pre-defined light shaders available
– RTPointLight, RTSpotLight, RTDirectionalLight, …
A Simple ExampleA Simple Example
• So far: Have discussed concepts on abstract level.
• Now: Give practical examples
• Steps to perform to implement a shader
1. Derive a new shader class from RTShader
2. Declare, init, and export its shader parameters
3. Implement its Shade() function
4. Compile it to a shared library
Example 1: Simple “Headlight” shaderExample 1: Simple “Headlight” shader
• Very simple shading model:C = (I_amb + (1-I_amb)*(N.D))*Rd
Rd: diffuse surface color (three floats)I_amb: ambient intensityN: surface normal (shading normal)D: Ray direction
Example 1: Simple “Headlight” shaderExample 1: Simple “Headlight” shader
• Step 1: Declaring the shader class
// include base header files#include “OpenRTS/RTS++.hxx”#include “OpenRTS/RTShader.hxx”
struct RTSimple : public RTShader {float ambient;R3 diffuseColor;void Init() { ambient = .3; diffuseColor = .5; };…
};// declare under the shader class name “Simple”rtDeclareShader(RTSimple,Simple);
Example 1: Simple “Headlight” shaderExample 1: Simple “Headlight” shader
• Step 2: Declaring the shader’s parameters
void RTSimple::Register() {rtDeclareParameter(
“diffuseColor”, PER_SHADER,memberoffset(diffuseColor), sizeof(diffuseColor));
rtDeclareParameter(“ambient”, PER_SHADER,memberoffset(ambient), sizeof(ambient));
}
Example 1: Simple “Headlight” shaderExample 1: Simple “Headlight” shader
• Step 3: Implementing the Shade() function
void RTSimple::Shade(RTstate state) {R3 C,D,N;// query ray’s direction and hit’s normalrtsGetRayDirection(state,D);Normalize(D); // might not be necessary
rtsFindShadingNormal(state,N);
//compute ray’s colorC = (ambient + (1-ambient)*(N*D)) * diffuseColor;
// return color to calling shader (via state)rtsReturnColor(state,C);
};
Example 1: Simple “Headlight” shaderExample 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 <…>
• GCC (3.4.2 and higher)g++ Simple.cxx –o libSimple.so –shared –fPIC –O3 –I <…>
• Make sure to pass the correct include directories
– MAKE SURE THE .SO IS IN YOUR LIBRARY PATH!
• That’s it…
Example 2: A typical Phong ShaderExample 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
Example 2: A typical Phong ShaderExample 2: A typical Phong Shader
• The shade function:virtual void Shade(RTstate state) {
// initializeC = ambientColor;rtsFindHitPosition(state,hitPos);rtsFindShadingNormal(state,normal);
// create new state for light samplesRTState lightSample;rtsInitState(state,&lightSample);
// query light sources:RTvoid **light;int lights = rtsGlobalLights(&light);
Example 2: A typical Phong ShaderExample 2: A typical Phong Shader
• Now, iterate over light sources:for (int i=0;i<lights;i++) {
rtsSetRayOrigin(&lightSample,hitPos)bool ok = rtsIlluminate(&lightSample,light[i],NULL);if (!ok) // maybe light points away from hitpoint
continue;// <MARK>
// Query light sample direction and radianceR3 L,I;rtsGetColor(&lightSample,I);rtsGetRayDirection(&lightSample,L);// do the actual shadingC += diffuseColor * (N * L) + …..
Example 2: A typical Phong ShaderExample 2: A typical Phong Shader
• Adding ray traced shadows
– Extremely simple: Just replace <MARK> with…// Check for shadowif (rtsOccluded(&lightSample))
continue;…
– That’s all there is to do
• Adding reflections/refraction:
– As simple as “C += rtsTrace(secondaryRayState);”(with correctly set secondary ray)
OpenRT Shader ExampleAdvanced shadingOpenRT 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
Advanced Shading w/ OpenRT: Typical OpenRT ShadersAdvanced Shading w/ OpenRT: Typical OpenRT Shaders
Cost of Shading…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 can’t help shading cost…
Minimize shading overhead
Minimize number of rays shot
Performance ConsiderationsMinimizing #of rays shotPerformance ConsiderationsMinimizing #of rays shot
• Tracing rays is fast, but cost is linear in #rays
– CHECK before you trace a ray
• Don’t trace shadow rays to lights that won’t be used, anyway(e.g., light on wrong side, light too far away, …)
• Don’t calculate shadows on a black (or transparent) surface
• For more complex shaders (glass, transparency)
– Tracking ray’s pixel contribution can avoid explosion of ray tree (already done in “RTX” shader package)
– But: tracking itself is costly…
Performance ConsiderationsMinimizing Shading OverheadPerformance 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 shader’s 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 > .1 || diffuseColor.y > .1 ……)”
– Rather use “if (diffuseOK)” with precomputed diffuseOK value
Performance ConsiderationsMinimizing Shading OverheadPerformance 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
– Don’t multiply compute data that didn’t change
• Don’t compute shading normal and hit position in the inner loop!
• Avoid unnecessary “Normalize”s
– Each normalize: 3MUL, 2ADD, 1DIV, 1SQRT!
• Typical CPUs: at most ~40M sqrt()’s/sec ( max. 1/pixel@40fps...)
– Normal returned by rtsFindShadingNormal is normalized already
– Ray direction usually normalized as well
• depends on your shaders…
Performance ConsiderationsMinimizing Shading OverheadPerformance ConsiderationsMinimizing Shading Overhead
• Avoid all operations that don’t have to be done
– I.e., don’t use “C += max(0,N*L) * PhongShade(N,L)”
– But rather “if (N*L > 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 “inline”s and “const”s 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, …
Shading in OpenRTSummaryShading 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…
Shading in OpenRTSummaryShading in OpenRTSummary
• The best way to really understand how it works:
– Have a look at the shader tutorialshttp://www.openrt.de/
– Write your own shaders…
– PLAY with it !
Using the OpenRT System
- A Users’ (not Programmers’) Perspective -
Using the OpenRT System
- A Users’ (not Programmers’) Perspective -
Ingo Wald
SCI Institute, University of Utah
The Users’ PerspectiveThe 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
OpenRT Based GamesOpenRT 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…)
Non-polygonal ApplicationsNon-polygonal Applications
• Direct support for non-polygonal primitives
– Freeform surfaces, isosurfaces, points, volumes, …
Point based Ray Tracing:Point based Ray Tracing:
24M points, 1PC, 2fps24M points, 1PC, 2fps
Scientific visualization:Scientific visualization:
“ “Lawrence Lawrence
Livermore” isosurface (8GB)Livermore” isosurface (8GB)
Medical imaging:Medical imaging:
““Visible female”, 1PCVisible female”, 1PC
Non-polygonal ApplicationsNon-polygonal Applications
• Direct support for non-polygonal primitives
– Freeform surfaces, isosurfaces, points, volumes, …
Direct ray tracing of freeform surfacesDirect ray tracing of freeform surfaces
Mercedes C Class, 320,000 Bézier patchesMercedes C Class, 320,000 Bézier patches
Massively Complex CAD DatasetsMassively 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 trianglesBoeing 777” - 350M triangles
Outdoor RenderingOutdoor Rendering
• Outdoor scenes: Lots of (instantiated) geometry
• Plus: Costly shading
– Transparent leaves, alpha textures, lighting, …
““Sunflowers” scene Sunflowers” scene (Oliver Deussen, Uni Konstanz)(Oliver Deussen, Uni Konstanz): ~1B triangles, 1 light source (sun) : ~1B triangles, 1 light source (sun)
Outdoor RenderingOutdoor 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 Forest” scene (Oliver Deussen, Uni Konstanz): ~1.5B triangles, HDR env. lighting
Interactive Global IlluminationInteractive Global Illumination
• All examples interactive (cluster)
– Can edit scene, lights, …
• But: Shaders require source access…(packets, SSE, …)
Photorealistic VR / Industrial Design ReviewsPhotorealistic 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)
Part IV – SummaryPart 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
Part IV – SummaryPart 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
Part IV – ConclusionPart 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)
SIGGRAPH 2005 Course on Interactive Ray Tracing
The End… ?
SIGGRAPH 2005 Course on Interactive Ray Tracing
The End… ?
Entire Course – SummaryEntire 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
Entire Course – SummaryEntire 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…
Entire Course – SummaryEntire 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
Part IV – The End…Part IV – The End…
Any Questions ?
(all speakers up, please…)