Yay! I finally have my first OptiX-version of Pete Shirley’s “Ray Tracing in a Week-end” tutorial working. Not the whole series yet (that’s still to come), but at least the “final scene”… pic below.
Background
Ever since Pete’s now-famous “Ray Tracing in a Week-end” came out (see, e.g., this link for more details), lots of people have used his mini-books to learn more about ray tracing. Those books are, in fact, absolutely amazing learning material (if you have not read them yet – you should!), but suffer from one big disadvantage: yes, they’ll teach you the fundamental basics (and in particular, the elegance and beauty!) of ray tracing – but they won’t teach you how to use modern GPUs for that. And in particular since the introduction of Turing, one really should know how to do that.
To fix that shortcoming, I recently suggested to Pete that “somebody” should actually sit down and write up how to do that same book series – step by step – in OptiX. Roger Allen has since done that same exercise for CUDA (see here for that (also excellent!) article), but that still has a shortcoming in that by using “plain” CUDA it doesn’t use Turing’s ray tracing hardware acceleration. To use the latter, one would have to either use Windows-only DXR (e.g., through Chris Wyman’s – equally excellent! 🙂 – DXR samples), or through using OptiX.
Long story short: I did eventually start on a “OptiX On a Week-End” (“OO-Awe”!) equivalent of Pete’s book series (and hope Pete will jump in – he’s such a much better writer than I am :-/)… but writing an entire mini-book, with examples and everything, turns out to be even more work than feared. So, following my motto of “better something useful early than something perfect too late” I finally sat down and skipped all the step-by-step introductions, all the detailed explanations, etc, and just wrote the final chapter example in OptiX. I’ll still write all this other stuff, but at least for now, I’ll do a much shorter version just with the final chapter.
So, what’s to come:
First, I’ll clean up the code a bit, and push that one final chapter example (with cmake build scripts etc) on github (I’ll write another post when that’s done). Once that’s public, I’ll write a series of little posts on how that sample works, relative to Pete’s CPU-only book. And only when all of that is out and written, then I will go back to doing the longer mini-book version. As such, this blog post was actually “part 0” of a series of posts that will soon be coming…. I hope you’ll find it useful!
With that – back to work…. 🙂
Ingo's Blog 
In reply to a question asked on twitter:
> Could you elaborate a bit? Would this still be valid if, for example, we had different types of primitives?
> Like you said, it does feel like magic 🙂
In the OptiX CPU program, you can create multiple geometries, each of which can have a different type of primitives (and possibly multiple prims within each geometry).
For each such geometry, you specify:
a) the number of prims (in finalChapter.cpp, look for “setPrimitiveCount(…)”)
b) a “bounding box program” that lets you, for each primitive in this geometry, return a bounding box for that prim (see programs/sphere.cu:bounding_box(…) for the sphere prim type).
and
c) a “intersectoin program” that lets you specify how a given primitive is to be intersected with a ray (see programs/sphere.cu:hit_sphere())
With that, OptiX can build a BVH over all prims in all geometries (all it needs is a bounding box per prim, see ‘b’), and can intersect a ray with that BVH (because it knows how to itersect each prim, see ‘c’).
So, no magic 🙂
LikeLike
Hi,
thanks for sample!
I got it to work on Titan V on Windows and also on MacOS (on hackintosh)
on MacOS had issue on linking step:
Linking CXX executable .
ld: can’t open output file for writing: ., errno=21 for architecture x86_64
so had to go to build/FinalChapter/CMakeFiles/finalChapter.dir
and do:
clang++ *.o /Developer/NVIDIA/OptiX/lib64/liboptix.1.dylib
then also use:
export DYLD_LIBRARY_PATH=/Developer/NVIDIA/OptiX/lib64
then similar timings to Windows with Optix 5.1.1 ..
output on MacOS: (CUDA 10.0 + Optix 5.0.1 as versions >=5.1 aren’t available on MacOS)
done rendering, which took 3.3 seconds (for 128 paths per pixel)
curious what Turing timings are vs Titan V..
also as las comment seems we have now CUDA,Optix and DXR samples..
unique raytracing supported API missing “a raytracing in a week” port is a Vulkan NV_ray_tracing port..
hope somebody does also for “completeness”
Oscar.
LikeLike
Hey, Oscar,
First, thanks for the feedback and number!
Re Mac: I don’t usually use macs, so admit I haven’t tested. There’s _probably_ a easy way to make the cmake scripts happy on mac, but I haven’t had a look yet. If anybody else does, I’d be happy to get a merge request! 🙂
Re timings: Yes, Turning will look different :-). I’ll run that as soon as I’m back to my turing machine. For clarity’s sake I’ll also factor out build time and render time, and will also create a iterative version (the recursive version will probably have quite some overhead).
Re Vulkan: Yes, that would be interesting, too…. I never used it, though.
LikeLike
Hi Ingo,
thanks for answering..
I looked at your updated demo again and fixed Cmake Mac building issue.. I found that adding at every Cmakelists.txt file below:
target_link_libraries(finalChapter_recursive
${optix_LIBRARY}
)
this line:
set_target_properties(finalChapter_recursive PROPERTIES OUTPUT_NAME “finalChapter_recursive”)
fixes the issue..
I got timings similar to yours in your latest blog..
done building optix data structures, which took 0.79 seconds
done rendering, which took 2.1 seconds (for 128 paths per pixel)
done building optix data structures, which took 0.71 seconds
done rendering, which took 2.6 seconds (for 128 paths per pixel)
just let me ask two things:
*What about Optix Prime?
I understand it’s optimized even further than general API for simple “tracing rays” apps like for baking ambient occlusion data.. I guess even the iterative version of Pete tutorial can’t be mapped to Prime API as seems limited to only triangle data.. from an Nvidia blog post:
“could also be extended to use the full OptiX SDK if you have geometry other than triangles, or need recursive ray tracing and shading.”
*Turing results: will be interesting to see vs Titan V, mainly because seems Turing RT Cores aren’t exploited by Optix <=5.2 apps.. and even then it will require a new API
for example here:
https://www.ks.uiuc.edu/Research/vmd/doxygen/OptiXRenderer_8C-source.html
we find things like:
rtGlobalSetAttribute(RT_GLOBAL_ATTRIBUTE_ENABLE_RTX,..)
LikeLike