Raytracing: How would I create a matte surface?

[Daniel Pitts]

Hello everyone.
I've decided (for no reason other than experience) to create my own
ray-tracing engine in Java.

So far so good, but my modeling is completely "reflective", which means
only glossy surfaces. What approach should I take to give the
appearance of matte surfaces?

My thoughts are: When bouncing a ray, if it is a matte surface, average
the value of rays in several directions, rather than just the reflected
ray. For instance. The current reflective approach:

incoming normal outgoing
\ | /
\ t | t /
\ /-|-\ /
\ | /

where "t" is the angle between the normal and incident vectors.

The matt approach

incoming normal outgoing
\ | /
\ t | Ux /
\ /-|-\ /
\ | /

where Ux is some angle related to t, but offset somewhat. There will
also need to be Uy for scattering that isn't coplanar with the incident
and normal. For every reflection off a matte surface, the Ux and Uy
will be calculated several times, and the resulting ray-trace will be
merged (color averaged?)

Is this the right approach? If it is, how would I calculate the new
outgoing values? Am I going the completely wrong direction on this?

Thanks,
Daniel.

 

[Gianni Mariani]

Hello everyone.
I've decided (for no reason other than experience) to create my own
ray-tracing engine in Java.

So far so good, but my modeling is completely "reflective", which means
only glossy surfaces. What approach should I take to give the
appearance of matte surfaces?

Bump mapping maybe?

Perhaps you can simply use a "material" model like opengl since a matte
comes from diffused light and from a ray tracing perspective it comes
from "everywhere".

My thoughts are: When bouncing a ray, if it is a matte surface, average
the value of rays in several directions, rather than just the reflected
ray. For instance. The current reflective approach:

incoming normal outgoing
\ | /
\ t | t /
\ /-|-\ /
\ | /

where "t" is the angle between the normal and incident vectors.

The matt approach

incoming normal outgoing
\ | /
\ t | Ux /
\ /-|-\ /
\ | /

In bump mapping, it's the normal that changes which does somthing
similat to what you describe.

where Ux is some angle related to t, but offset somewhat. There will
also need to be Uy for scattering that isn't coplanar with the incident
and normal. For every reflection off a matte surface, the Ux and Uy
will be calculated several times, and the resulting ray-trace will be
merged (color averaged?)

Is this the right approach? If it is, how would I calculate the new
outgoing values? Am I going the completely wrong direction on this?

From my experience, (as for ray tracing, I have none...) experimenting
is a good way to gain insight so it can't be wrong.

 

[Miles Bader]

Is this the right approach? If it is, how would I calculate the new
outgoing values? Am I going the completely wrong direction on this?

Are you talking about, for the purposes of doing indirect ["global"]
illumination? [I.e., do you already handle direct illumination in the
manner of a class RT?]

-Miles

 

[Daniel Pitts]

Is this the right approach? If it is, how would I calculate the new
outgoing values? Am I going the completely wrong direction on this?

Are you talking about, for the purposes of doing indirect ["global"]
illumination? [I.e., do you already handle direct illumination in the
manner of a class RT?]

-Miles

My Entity classes -- so far I support Plane, Sphere, and "a portion of
an Entity that exists within a sphere" -- contain a possible light
source, and a possible pigment. So light is already being generated by
some objects within my world.

I have a very large Sphere which I surround the world with, which has a
black pigment (reflects no light), but a solid bluish-white
luminescence. So that is my "global" light at the moment.

 

[Daniel Pitts]

Bump mapping maybe?

Perhaps you can simply use a "material" model like opengl since a matte
comes from diffused light and from a ray tracing perspective it comes
from "everywhere".

Hmm, perhaps, but I'd like to avoid tricks like that if possible (if I
were going for a professional grade app, I would consider that).

In bump mapping, it's the normal that changes which does somthing
similat to what you describe.

I'm actually doing that, but using random jitter on the normal instead
of a bit-mapped normal.

From my experience, (as for ray tracing, I have none...) experimenting
is a good way to gain insight so it can't be wrong.

True, it's the main reason I love experimenting .

 

[Dave Eberly]

So far so good, but my modeling is completely "reflective", which means
only glossy surfaces. What approach should I take to give the appearance
of matte surfaces?

A very well-written and excellent book on the topic is:

"Physically Based Rendering",
Matt Pharr and Greg Humphreys,
Morgan Kaufmann Publishers, 2004

It also comes with a CD-ROM of source code written
in the "literate programming" style.

 

[Miles Bader]

My Entity classes -- so far I support Plane, Sphere, and "a portion of
an Entity that exists within a sphere" -- contain a possible light
source, and a possible pigment. So light is already being generated by
some objects within my world.

I have a very large Sphere which I surround the world with, which has a
black pigment (reflects no light), but a solid bluish-white
luminescence. So that is my "global" light at the moment.

Hmm, I'm not sure I completely understand what you're saying...
[BTW there was a typo in my original post -- I meant to say "... in the
manner of a classic RT"]

Very few practical ray-tracers work purely recursively, because it's
very slow for non-specular surfaces (though I gather there are some ways
to improve things, e.g. "metropolis light transport"), and especially
for matte surfaces.

Most real world RTs instead use a combination of forward (from the
lights) and backward (from the camera) methods. For instance, a classic
RT uses backward rays from the camera to find points on surfaces, and
when a point is on a non-specular surface, will iterate over the lights
calculating direct illumination on that point; for points on specular
surfaces (mirrors/lenses) it will recurse going backwards. That ends up
[mostly] calculating only "direct" illumination, but it's much faster
than simply always recursing backwards, and for many scenes, direct
illumination forms the bulk of the lighting.

Even for only direct illumination at a single point, often it's best to
combine forward/backward intelligently -- e.g., "multiple importance
sampling", where you calculate some rays from a surface point backwards
according to the surface's distribution, and see which lights they hit,
if any, and calculate some rays from lights, and see how they hit that
surface point.

I'd suggest googling around and reading the course notes from an intro
graphics course at a good university; there's lots of great stuff on the
net...

Also, I'll second the recommendation made by Dave Eberly
("Physically-Based Rendering", aka "the PBRT book"), it's an outstanding
book on ray-tracing, both comprehensive and practical.

[The main drawback with the PBRT book is that it's physically
enormous -- not that easy to toss in your bag... :-]

-Miles

 

[Sabine Dinis Blochberger]

Hello everyone.
I've decided (for no reason other than experience) to create my own
ray-tracing engine in Java.

POV-Ray[1] is open source, so you could peek in to see how they do
things...

The only other thing I can add for matte surfaces, is that they don't
reflect 100% of light. I think

[1] <http://www.povray.org>