About


XRT is a raytracing based programmable rendering system for photo-realistic image synthesis built around a plug-in architecture design.


Blog

XRT 2.4.1 released

Posted: 08 Dec 2014 14:03
Tags: downloads

microbe.jpg

There are no new features in this release but a lot of bug fixes (see ChangeLog for a complete list). I have been rechecking the RenderMan Companion, Advanced RenderMan, Esssential Renderman Fast, Rendering for Beginners and Texturing & Modeling examples. 676 different scenes is a lot of work but the remaining part is even bigger! There will be certainly a few other point releases before I can consider the job done.

The Advanced RenderMan, RenderMan Companion, Texturing & Modeling galleries have been updated.

The picture of this post is from the Aqsis distribution and is now part of the XRT examples bundle.

Comments: 0, Rating: 0


XRT 2.4.0 released

Posted: 05 Oct 2014 22:17
Tags: downloads osl

osl.jpg

The main feature in this release is the integration of the Open Shading Language. There have been a lot of pondering and a few false starts (hence the 6 months hiatus with the previous post) but here it is. Well, sort of …

Some time ago, while trying to establish a road map for next XRT features, I discussed the pros and cons of OSL here: great features but really tailored to a path tracer (no light shaders, hard-coded lighting models (aka closures)). Losing the flexibility brought by the RenderMan Shading Language was really making me uneasy.

Therefore, I first considered implementing RSL on top of OSL machinery: RSL 1.0 and OSL are quite similar, there were only a few global variables and shade-ops missing from OSL to bring back the needed functionalities. Confidently, I started an implementation: I wrote a parser that compiled RSL into .oso intermediate representation and … I gave up because I realized it was a dead end even if it was progressing nicely.

There are several technical reasons for this:

  • the latest RSL 2.0 is really different from OSL and would have required a much extensive effort.
  • most of RSL derivative shade-ops work in the surface parametric space whereas OSL shade-ops work on the surface tangent plane. Some shaders would have required a rewrite to perform properly.

But the main reason is that Pixar is going to drop RSL in favor of OSL (see this discussion on OSL Google group or this announcement from Pixar). Of course, RSL is not going to disappear tomorrow but will surely get deprecated in the future.

Therefore, I have settled for an easier path: tailor OSL. XRT shaders follow strictly OSL syntax but there are significant differences:

  • light shaders are back. A specific statement emit is used to define how light is emitted. Only light shaders write to global variables Cl (light color) and L (light direction).
  • closures are gone. Surface and volume shaders write to global variables C (surface color) and opacity (surface opacity) and gather light with a lights loop statement which has access to all lights in the scene. Only a lights loop can read current light Cl and L.
  • a number of ray-tracing shade-ops have been added to trace rays, compute shadows, occlusion and indirect illumination.

More details can be found in XRT Technical Reference manual.1

Although much more work is needed to finalize this porting effort, there are already a few benefits to notice:

  • because the LLVM infrastructure is bundled into XRT distribution, there is no need anymore to install Microsoft Visual C++ compiler (which was a rather heavy requirement for people eager to try out XRT).
  • XRT is faster. The speedup is not huge but noticeable.

All XRT examples have been checked against this release and run OK (although some renders differ a bit more than expected from their RenderMan based counterpart) and a number of shaders have been ported to OSL. Over the next months, I intend to re-render, recheck (and extend) the whole gallery.

Comments: 0, Rating: 0


XRT 2.3.2 released

Posted: 01 May 2014 10:26
Tags: downloads

Yet another bug fix for XRT 2.3.0. This prevents a crash when rendering with bilinear patch mesh primitives.

Comments: 0, Rating: 0


XRT 2.3.1 released

Posted: 07 Mar 2014 21:21
Tags: downloads

This release is a hot fix for XRT 2.3.0. Sorry about that but I left a few nasty bugs in subdivision surfaces rendering code. As a bonus, XRT now computes tighter bounding boxes for cubic curves which decreases rendering times by 10% on "hairy" scenes.

Comments: 0, Rating: 0


XRT 2.3.0 released

Posted: 02 Mar 2014 11:01
Tags: downloads subdivision surface

I can't get no satisfaction

I have never been satisfied with XRT implementation of subdivision surfaces. It was missing important features and was very slow. This new version solves both issues.

Still the same

The general outline of the rendering algorithm (described in this post) has not changed much in this new implementation: a topological structure is built from the subdivision surface description and is refined to isolate extraordinary features and to obtain a control mesh made of quads only. Then, the mesh is split into individual faces and their 1-neighborhood (the minimal data needed to apply subdivision rules and compute the limit surface). During the intersection phase, the face is subdivided on the fly until the resulting patches look flat or small enough. They can then be safely approximated as a bilinear patch which is checked for intersection.

With a little help from my friends

opensubdiv_logo_header.png

Until Pixar came with the OpenSubdiv project, a developer was really on its own with subdivision surfaces. Quoting the project overview, "OpenSubdiv is a set of open source libraries that implement high performance subdivision surface (subdiv) evaluation on massively parallel CPU and GPU architectures. This codepath is optimized for drawing deforming subdivs with static topology at interactive framerates. The resulting limit surface matches Pixar's Renderman to numerical precision." At first sight, this looks only suitable for people doing real-time graphics or interactive editors but, actually, OpenSubdiv architecture makes it reusable for many purposes.

OpenSubdiv is built from three layers:

  • hbr (hierarchical boundary rep) is a topological structure designed to store edges, faces, and vertices of a subdivision surface. It also stores attributes of the surface such as corners and creases, facevarying data and various hints affecting the subdivision process such as hierarchical edits. Actually, it supports almost all features of SubdivisionMesh and HierarchicalSubdivisionMesh as defined by the RenderMan Interface specification.
  • far (feature-adaptive rep) uses hbr to create and cache fast run time data structures for table driven subdivision of vertices and cubic patches for limit surface evaluation. Feature-adaptive refinement logic is used to adaptively refine coarse topology near features like extraordinary vertices and creases in order to make the topology amenable to cubic patch evaluation. It supports these subdivision schemes:
    • Catmull-Clark
    • Loop
    • Bilinear
  • osd (Open Subdiv) contains client-level code that uses far to create concrete instances of meshes. These meshes use precomputed tables from hbr to perform table-driven subdivision steps with a variety of massively parallel computational backend technologies. Osd supports both uniform subdivision and adaptive refinement with cubic patches. With uniform subdivision the computational backend code performs Catmull-Clark splitting and averaging on each face. With adaptive subdivision the Catmull/Clark steps are used to compute the control vertices of cubic patches, then the cubic patches are tessellated on with GLSL or DirectX. This top-level layer is really dedicated to real-time performance.

As you probably already guessed, XRT now uses hbr to store all subdivision surface data and far to selectively refine the control mesh, solving the missing features problem.

The need for speed

As usual in algorithms, there is a trade-off between speed and memory. The rendering algorithm XRT is using has been designed for GPUs which are so fast for simple and parallel computations that they can afford not to cache anything in memory and still be very efficient. Of course, it turns out to be not that suitable for CPUs.

Therefore, I have tried to use hbr to cache control mesh refinement. It failed because hbr structures are not multithreaded and because manipulating lots of pointers in a topological structure is slow (even slower that refining again and again with a linearized data structure).

The key observation is that, except around extraordinary features, the limit surface of a Catmull-Clark subdivision surface is a b-spline surface. In other words, once a subdivision surface has been refined up to a point that a patch is regular (ie does not contain extraordinary features: points with valence other than 4, crease or corner), that patch can be replaced by a bicubic b-spline patch whose 16 control points are the control points of the patch. Furthermore, when subdividing a patch containing one extraordinary feature (the case where it contains more than one has been dealt with in the refinement phase), only one (sometimes two) of the four resulting patches is extraordinary, the three others being regular. Actually, once features have been isolated, at each refinement level, the number of extraordinary patches stay almost the same. They just get smaller.

The consequence is that subdivision on the fly is almost never needed and that raytracing a Catmull-Clark subdivision surface can be nearly as fast as raytracing a mesh of bicubic patches. Implementing this optimization brought a 10 times speed increase to this algorithm.

Here is the result. First, the raw subdivision surface.

Sloppy Sam
Image Unavailable
raw subdivision surface

On the next picture, facevarying data (s,t) coordinates have been correctly interpolated across the surface to bring even more worries to this poor Sloppy Sam.

Sloppy Sam
Image Unavailable
with additional bump mapping effect

Comments: 0, Rating: 0