Real time subsurface scattering software demo.

[JavaJones]

I ran across this the other day and was fairly impressed by it. It's a real time subsurface scattering demo implemented in software (entirely CPU dependant). I got 6-8FPS on a PIII 600, and I'm guessing an Athlon XP or newer P4 could get the "minimum" 30FPS at least in the small demo, if not the large.

http://www.flipcode.com/cgi-bin/msg.cgi?showThread=11-19-2002&forum=iotd&id=-1

Perhaps of more interest to the forum, the author mentions he is contemplating porting it to DirectX 9 to take advantage of hardware acceleration. Considering how relatively slow SSS implementations have been in the past (ex. Photon Mapping), I thought a real time implimentation was fairly impressive, and a hardware accelerated version will be even more so.

Just thought some might be interested in seeing this. Back to lurkdom...

- JavaJones

 

[PC-Engine]

Cool thanks I'm going to try it 8)

 

[DemoCoder]

You might find this interesting
http://www.microsoft.com/corpevents/gdc2001/slides2002/DistributedAreaLighting.ppt

Microsoft has some others papers I can't find, but the idea is to try integrate more of the reflected rays into the HW by using precomputation pass.

 

[KimB]

Hrm, very interesting stuff in that presentation, Democoder. I find it rather strange, though, that they'd actually be using spherical harmonics. The equations for spherical harmonics are rather intense (A set of two power series of cosines). Anyway, if you want to take a look, I made a little demo for my Quantum Mechanics class that displays orbitals of the hydrogen atom (which makes use of spherical harmonics):

http://66.127.112.209/orbitals.zip

Anyway, the l,m values should coincide well with what was shown in the powerpoint presentation. I didn't bother to include the negative m values, as they have the exact same probability distribution as the positive values.

 

[Ilfirin]

Spherical harmonic based lighting is actually incredibly easy, since all the formulas (minus the spherical harmonic rotations and such) reduce to a series of dot-products.

I have been doing a lot of work with spherical harmonics and DX9 pixel/vertex shaders that I don't want to give too much away yet.. but suffice it to say that really really good lighting equations (beyond BRDF) combined with really really good shadowing are possible at very rapid rates with DX9 level hardware. (all the problems with spherical harmonics on DX8.1 hardware mostly go away.. and then some) 2003/2004 are definitally going to be interesting years for real-time 3D computer graphics.

 

[KimB]

Right, all the cosines would just be made out of dot products, but there's still significant power series involved, with lots of factorials. Do you use a sort of look up table for those?

 

[Ilfirin]

Right now I am just keeping the spherical harmonics relatively low order to keep the computations manageable, which means really soft lighting environments (they have the opposite problem with all of today's shadowing methods, really soft shadows are fast and easy, really sharp shadows are incredibly slow and hard).

But I have only touched the tip of the iceberg, i'm sure there are a lot of things that can be done to improve the quality/performance.

 

[Mintmaster]

Right, all the cosines would just be made out of dot products, but there's still significant power series involved, with lots of factorials. Do you use a sort of look up table for those?

Don't you store the spherical harmonics in cube maps? Then you just use the coefficients and dot product with these precomputed harmonics.

 

[fresh]

Right now I am just keeping the spherical harmonics relatively low order to keep the computations manageable, which means really soft lighting environments (they have the opposite problem with all of today's shadowing methods, really soft shadows are fast and easy, really sharp shadows are incredibly slow and hard).

But I have only touched the tip of the iceberg, i'm sure there are a lot of things that can be done to improve the quality/performance.

How're you handling moving objects like characters? How many terms are you using in the SH? Looks great for static scenes, but anything dynamic and you're screwed.

 

[KimB]

Don't you store the spherical harmonics in cube maps? Then you just use the coefficients and dot product with these precomputed harmonics.

I don't think so. The whole point is to do the texture procedurally, as a compression scheme. Storing a cubemap for each spherical harmonic would eat up too many of the available textures per pixel.

 

[Mintmaster]

Don't you store the spherical harmonics in cube maps? Then you just use the coefficients and dot product with these precomputed harmonics.

I don't think so. The whole point is to do the texture procedurally, as a compression scheme. Storing a cubemap for each spherical harmonic would eat up too many of the available textures per pixel.

I'm quite sure this is how the Stanford guys did it. In 3 textures you can store 12 harmonics, and then use 9 other textures for the RGB coefficients. I'm pretty sure that procedural calculation of 12 harmonics would eat a lot of cycles, as you mentioned originally. You can multipass if you have to accommodate more harmonics.

You only save 25% of the texture slots doing it your way, as you need the RGB coefficients for each harmonic regardless. The harmonic itself only occupies one colour channel of one texture. It's really not worth the trouble or speed hit to procedurally calculate it.

The "whole point", from what I gather, is to effectively have a per pixel environment map for whatever purpose. Its like a "4D texture", where the first two coordinates come from the model's texture coordinates, and the next two come from the normals and lighting math. I guess you're right in saying it compresses this "4D texture" into a 2D texture, but the real power is in how you get an individual sphere of data for each point of a model.

 

[Mintmaster]

I made a little demo for my Quantum Mechanics class that displays orbitals of the hydrogen atom (which makes use of spherical harmonics):

This is a bit off topic, but I actually have my Quantum Mechanics final in a couple of days. Ever heard of Sajeev John? He's my prof, one of the two guys who developed the photonic bandstructure theory. I'm not at that level yet, though...

 

[Ilfirin]

Right now I am just keeping the spherical harmonics relatively low order to keep the computations manageable, which means really soft lighting environments (they have the opposite problem with all of today's shadowing methods, really soft shadows are fast and easy, really sharp shadows are incredibly slow and hard).

But I have only touched the tip of the iceberg, i'm sure there are a lot of things that can be done to improve the quality/performance.

How're you handling moving objects like characters? How many terms are you using in the SH? Looks great for static scenes, but anything dynamic and you're screwed.

Moving objects are easy, it's deforming objects that are the problem. I haven't tackled the problem of deforming/animating objects like characters yet, but I can think of about a dozen sollutions off the top of my head that would work, but are rather brute-forcish.

As for what order of the harmonics I am doing, that depends. Sometimes you can get away with a really low-order function (2-4), but most of the time you need atleast (and I mean at the very least) a 5-6 order function. 5-6 are pretty optimal numbers, since the shadowing is still very distinct and the computation times are still pretty low.

I will probably end up going with shadow maps w/ percentage-closest filtering for the sharp lighting environments, with spherical harmonics for the soft stuff. Unfortunately, that still leaves a rather large gap in-between.. which just happens to be where 90% of the real-world's lighting environments lay.

For those who haven't seen it yet (and I suspect most people here have seen it), there are two rather good papers on the application of spherical harmonics to real-time graphics located here - http://research.microsoft.com/~ppsloan/
Specifically, Pre-Computed Radiance and Spherical Harmonic based BRDFs. Note that the paper was written to DX8.1 hardware.

 

[KimB]

This is a bit off topic, but I actually have my Quantum Mechanics final in a couple of days. Ever heard of Sajeev John? He's my prof, one of the two guys who developed the photonic bandstructure theory. I'm not at that level yet, though...

Nope, can't say that I have. My QM final is tomorrow, though...gotta study up on that perturbation theory junk. The idea is incredibly simple, but working with it isn't...

 

[overclocked]

Tested the demo on a k6-2 @ 350mhz, the small was 3-6fps and the large was zero too one/fps.

 

[Mintmaster]

Moving objects are easy, it's deforming objects that are the problem. I haven't tackled the problem of deforming/animating objects like characters yet, but I can think of about a dozen sollutions off the top of my head that would work, but are rather brute-forcish.

Yeah, I've been thinking about the same thing. I can think of a couple of "brute-forcish" ideas, but they seem to break down if there are too many animation parameters. Maybe you can enlighten me? (Unless you want to keep this to yourself, which I can understand)

As for what order of the harmonics I am doing, that depends. Sometimes you can get away with a really low-order function (2-4), but most of the time you need atleast (and I mean at the very least) a 5-6 order function. 5-6 are pretty optimal numbers, since the shadowing is still very distinct and the computation times are still pretty low.

When you say 5-6, do you mean l=5-6? i.e. you have 25-36 coefficients? Or do you mean 5-6 harmonics total, i.e. l=2-3?

BTW, do you think we should move this to the 3D Architecture and Coding forum?

 

[horvendile]

This is a bit off topic, but I actually have my Quantum Mechanics final in a couple of days.

My QM final is tomorrow, though...gotta study up on that perturbation theory junk. The idea is incredibly simple, but working with it isn't...

Ah... 8)
(Being intensely satisfied with already having passed QM)

OK, OT. Sorry.

 

[Ilfirin]

Yeah, I've been thinking about the same thing. I can think of a couple of "brute-forcish" ideas, but they seem to break down if there are too many animation parameters. Maybe you can enlighten me? (Unless you want to keep this to yourself, which I can understand)

I haven't spent much thought at all on the subject (of deforming models) yet, so anything I say wouldn't be fully thoughtout or informed.. so I think I will remain silent for now.

When you say 5-6, do you mean l=5-6? i.e. you have 25-36 coefficients? Or do you mean 5-6 harmonics total, i.e. l=2-3?

25-36 coefficients.

 

[Entropy]

Nope, can't say that I have. My QM final is tomorrow, though...gotta study up on that perturbation theory junk. The idea is incredibly simple, but working with it isn't...

Good luck on the perturbation theory, Chalnoth.
How do I access the command line of your program? The ReadMe didn't say.

Entropy

 

[Laa-Yosh]

Could this harmonics stuff be used in the new Unreal techdemo that was shown at the GeForce FX presentation?

Also, why is this technique unused in offline rendering? I would be so happy not to mess with shadow map resolution and bias settings...