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


Session IV:Using Realtime Ray Tracing

Ingo Wald

SCI Institute, University of Utah

[email protected]

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…) !



– We want YOU to play around with RTRT…

– Therefore:

As of this SIGGRAPH, noncommercial

version of OpenRT publicly available !

More infos: www.openrt.de

http://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 ?

• Actually, three different things


What is OpenRT ?


– A Project: The Saarland Realtime Ray Tracing Project


What is OpenRT ?



– A specific realtime ray tracing rendering engine

• Outcome of the OpenRT project

• RTRT core, shared library with SDK


What is OpenRT ?



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


Part I:- Programming Applications

with OpenRT -

Ingo Wald


[email protected]

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


• 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





• Test: Who in this room has implemented

– A ray tracer ?






– A ray tracer ?

– A kd-tree ?






– A ray tracer ?

– A kd-tree ?

– A kd-tree packet traverser ?






– A ray tracer ?

– A kd-tree ?


– SSE ?






– A ray tracer ?

– A kd-tree ?


– SSE ?

– A (good) kd-tree construction (SAH) ?






– A ray tracer ?

– A kd-tree ?


– SSE ?

– A (good) kd-tree construction (SAH) ?

• Got the point ?


(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


• 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 ?)


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();


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(&currentTransform);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


• A brief tutorial

– Initializing

– Defining geometry

– Loading and using shaders

– Rendering a frame

– Animating the scene


• Tips & Tricks


• A brief tutorial extended slides (www.openrt.de)

– Initializing

– Defining geometry

– Loading and using shaders

– Rendering a frame

– Animating the scene


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


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, …


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


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, …


• 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!


• 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


Part II:- Writing OpenRT Shaders -


Part II:- Writing OpenRT Shaders -

Ingo Wald


[email protected]

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


• 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);


• 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));

}


• 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);

};


• 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


• 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);


• 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) + …..


• 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


[email protected]

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 – 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)



The End… ?


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


• 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…


• 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…)

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

Documents

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