|
The Inyo Renderer |
|
A
Monte Carlo Path Tracer by David Cuny
|
Inyo is (more or less) Dead
Inyo was originally written because I couldn't find a nice Java raytracer. Since then, Sunflow
pretty much supplies all the functionality (and more) that I was hoping to get from Inyo. Additionally, approximate ambient occlusion (pdf 3.4 Meg)
has replaced my need to do path tracing.
You might want to check out
these this list
for other open source renderers.
Rendered with the Inyo path tracer.
The only light in this scene comes from the sky. Yes, I know the
sampling is buggy.
The cartoon rabbit is a free model from Eggington
Productions.
What Is Inyo?
Inyo is an
open source Monte Carlo path tracer renderer written in Java. The main
purpose for Inyo
is to supply JPatch with
a renderer that provides indirect skylight lighting along the lines of
Marcos Fajardo's Arnold
Renderer. Inyo
can be
used as a stand alone renderer, apart from JPatch.
Summary of Inyo Features
- Command line Java program
- Loads data from text file
- Outputs .png or .jpg graphics.
- Ray tracing is used to determine direct illumination from point
light sources. The ray tracer supports:
- Triangles are the only supported geometric primitives.
- POV-Ray style material attributes, including reflection and
refraction.
- Soft shadows.
- Monte Carlo Path tracing to determine indirect illumination.
- Currently, the only source of indirect lighting is the sky.
- Stratified hemisphere sampling is used to reduce sample
variances.
- Irradiance caching can be used to reduce the number of samples
needed.
Using Inyo
You can get the source code for Inyo here.
You will need to compile it with Java, which should be simple enough:
Once Inyo has been compiled, you can then execute it with the instruction:
where filename is the name of the file to render. Inyo can currently only
render files stored in the "generic" format of the JPatch animation program.
Please refer to the include readme file for documentation on the command line options
currently available (not all options in Inyo can currently be set in the command line).
What's Happening with Inyo
I've done quite a bit of development on Inyo, including:
- Fake subsurface scattering (multiple and single)
- An implementation of Matt Pharr's skin shader
- Corrected reflection and refraction
- Image-based shader
- Fake caustics
- Simulated color bleeding using ambient occlusion
- Focal blur
- Colored lights
- Oversampling of edges and shadow boundaries
I'll upload the latest version of Inyo when I get a chance, in case anyone is curious to look at the code.
However, I won't claim that it's good code, and there's no real file format for loading models into
Inyo. In the mean time, you can always send me an email if you want a copy.
Inyo's development has been tied to bleeding-edge versions of
JPatch, and hasn't been stable
enough to post. Problematically, import of .obj files is now
broken, and the Inyo now relies on being supplied with correct normals
and interpolated vertices. Until this is fixed, Inyo can't really be
used for a stand-alone renderer for anything that doesn't export normals.
When JPatch hits a stable release, I'll try to get Inyo into
a form that can be used "stand alone". It's also included with the
JPatch source code.
What's this Monte Carlo Stuff?
When rendering a scene, computers have traditionally used direct
illumination – the illumination of a point is based on the ray from
the eye to some point p, and
another ray from the point p to a light. The
illumination calculation takes into account illumination that comes
directly from the light, but not illumination which might take a
different path, such as from the light to the ground, and then to point
p, and then to the eye.
The following image was produced using traditional ray tracing. The jitter for the following scene is
set to 3, which means each pixel is an average of 9 samples. Note that
soft shadows are enabled, so the shadow becomes blurred the further it
is from the rabbit:
Since the indirect illumination
of a scene can come from (essentially) random directions, the path
tracer mimics this by sending lots and lots of rays at a given point p in
random directions. This is random sampling is referred to as a "Monte
Carlo" technique. If enough rays are sent out, the path tracer will
eventually converge on a solution that includes many different light
paths. The following image is a "pure" Monte Carlo image, with 100
samples per pixel. Note that the rendering time is much higher, and the
result has a lot of "noise" in it:
Rather than create new samples at every new point p, a technique known as irradiance caching saves sampled
points into a cache. When the path tracer needs to determine the
illumination (irradiance) at a
new point, if first checks to see if there are samples in the cache
similar enough to the point in question be used to create an estimate
of the illumination instead.
Besides reducing the number of samples that need to be taken,
irradiance caching has the happy side effect of virtually eliminating
the high level of noise created by the path tracer.
The image below shows the same scene as the prior one, but uses the
irradiance cache to estimate most of the samples. The
white dots indicate the points where Inyo actually sampled the scene
for irradiance. Samples are taken more frequently based on how far
apart
the samples are, the difference in curvature, and the average distance
of shadow casting objects from the sample point:
Inyo is able to provide a complete illumination estimate by using the
ray tracer to calculate direct illumination, and the path tracer and
irradiance cache to estimate indirect illumination. The image below
shows the result:
Unfortunately, the irradiance cache is broken in the current release.
Last Updated: Wednesday,
March 2, 2005