Development

From RibTools

Jump to: navigation, search

Contents

The Code

RibTools is hosted on Google Project Hosting at the URL http://ribtools.googlecode.com.

Use Mercurial (Hg) to get the code: 

hg clone https://ribtools.googlecode.com/hg/ ribtools

or, alternatively 

hg clone http://ribtools.googlecode.com/hg/ ribtools

(See the Mercurial Download page for a suitable client.)

Follow the readme (PDF and TXT) that comes along the source code for instructions on building.

Overview

The development pages are dedicated to give an overview of the project from a developer perspective, explain some implementation details and guide those that want to build the code themselves.

Other sub-sections can be accessed from the site menu on the left.

A game programmer's perspective

A sphere with displacement shader

Real-time computer graphics has grown exponentially in the last 15 years, but it has also been getting progressively closer to features that were already well defined and used in REYES renderers.

Nowadays, many real-time graphics programmers have moved into engine development and all but given up on lower level graphics processing, while other have started growing new hopes for old techniques such as the ever elusive real-time ray-tracing, or more modern approaches to voxel/point-based rendering.

The REYES approach seems instead to be getting less attention although it has been on the forefront of photorealistic rendering for many years now.

RibTools is built from the perspective of game programmers that want to take a break from the strict hardware limitation of current GPU architectures and related graphics APIs, and doing so with an eye towards production rendering.

Challenges

Debugging the multi-threaded bucket rendering

With the ultimate goal to become a RenderMan compliant renderer, it is not enough to implement the REYES architecture. It's necessary to support a series of features and interfaces that have evolved with time.

Specifically, RibTools is concerned with:

  • Parsing RIB scene files
  • Implement a state machine that reflects the RenderMan specifications
  • Compile C-like RenderMan shaders (RSL)
  • Design and implement a shader Virtual Machine
  • Support a number of geometric primitives such as quadrics, patches, etc.
  • Support shader-driven displacement mapping
  • Employ the REYES rendering architecture with an hider tailored for quality (multi-sampling, order independent translucency)
  • Exploit modern hardware's SIMD and multi-core capabilities in a scalable and generalized fashion
  • Exploit network connectivity to distribute rendering computations even for a single frame

Renderer FAQ

Q: What is the purpose of the project ?

A: RibTools is an experimental rendering environment originally meant to assess the feasibility of a Reyes-style renderer for real-time. The goal is also to learn about more intimate rendering topics that are normally not explored when developing for current graphics accelerators and APIs such as Direct3D and OpenGL.

Q: What are the differences between a Reyes (micropolygons) renderer and Direct3D/OpenGL ?

A: In brief: quality and scalability..

Current graphics accelerators are optimized to render static triangular meshes very efficiently, but triangular meshes are inherently not efficient because, depending on the camera position, they lead to either too coarse or too dense representations of the original model.

In a Reyes renderer, instead, more efficient primitives such as subdivision surfaces and NURBS, and techniques such as displacement mapping, are all first class citizens. Also, features such as motion blur, depth of field and order independent translucency are implemented elegantly, allowing for more artistic freedom, and less tedious tweaking around the ad-hoc implementations typical of the hardware accelerators counterpart.

Q: What about real-time ray-tracing instead ?

Recently, there has been a lot of development towards implementing ray-tracing in real-time.

However, those ray-tracers have several drawbacks: scenes are mostly static ans rendering is limited to unnatural sharp shadows, simplistic lighting and mirror-like perfect reflections.

Key features such as displacement mapping and support for advanced shading languages, that define REYES and even the more modern GPU-based rasterizers, are also generally absent from those ray-tracers, putting them several years behind in terms of realism and flexibility.

Q: But I saw a demo of DirectX 11,12/ OpenGL 3.0,4.0, implementing displacement mapping and motion blur !

A: Technical demos are built to showcase continuously new features and may give the impression of achieving the same results of the more heavy production renderers. The truth however is that these techniques are implemented around hardware limitations and rendering time constraints first. This leads to ad-hoc solutions with a limited lifespan and that tend to show their weaknesses when applied to more complex scenarios (e.g. in a game).

While hardware and APIs are catching on, they are still hindered by their past "polygonal" history and still struggling to achieve the flexibility and rendering quality that was instead the primary goal of the Reyes pipeline already 30 years ago.

Q: What's with the micropolygons ?

A: Given that natural looking models are better represented with smooth surfaces perturbed by displacement mapping and/or procedural shaders, such primitives and textures need ultimately to be reduced to pixels.

The Reyes pipeline suggests that smooth surfaces be split and diced until they can be represented by grids of samples (usually, color values). Grids dense enough to suppress most aliasing artifacts but no denser, thus saving computing power.

In a later stage of the rendering pipeline, for each grid of samples, adjacent samples are converted to quadrilaterals (the micropolygons). Then, in the final stage, every pixel of the image is tested against every (nearby) micropolygon. Here, if a pixel is touched by a micropolygon, the color of the micropolygon, weighted by the area of the intersection is added as a contribution to the color of the pixel.

Q: How big is a micropolygon ?

A: The estimation of shape and size of each micropolygon is only approximate. This approximation is based on the size and shape of a grid of samples projected on screen, and the final goal is to have micropolygons with an area roughly the size of one pixel.

Q: Surely, having larger polygons on screen should be a lot faster ?

A: As we demand more quality, triangular meshes become more complex, eventually to the point where a few triangles are large but most other are smaller than a pixel, even so small to produce subsampling artifacts. This is due to perspective projection, which makes geometry appear exponentially smaller on screen as the distance in depth increases.

In that light, fairly sized but dynamically generated micropolygons are potentially more efficient than the static polygonal meshes on which classical rasterization relies on.

Q: If the Reyes pipeline is so efficient, then why does it render so much more slowly ?

A: Production rendering is about quality first. Scenes are often much larger, involving several gigabytes of textures for the more defined models, and requiring constant streaming from disk. Shaders and light sources also tend to be more numerous and more complex in nature.

In a sense, production rendering aims to better deal with the worst cases. A renderer will handle scenes that wouldn't fit on a computer's RAM, let alone a 3D accelerator's VRAM.

Additionally, the techniques used in renderers tend to rely on the flexibility of CPUs and are difficult to map on GPUs, which are built more cheaply but that have limited programmability and very limited I/O access (e.g. no direct streaming from disk, no efficient access to the computers' memory)

Related material

Related articles

Reference material

Other RenderMan-compliant renderers

Retrieved from "http://ribtools.com/wiki/Development"
Personal tools