SL Question: Surface curvature?

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

Thread Tools Search this Thread Display Modes
Old 08 August 2003   #1
SL Question: Surface curvature?

ZeroNero and I were talking on IRC about alternate methods to calculate a "dirtmap" shader.

It seems to me that most people use take the ambient oclussion approach which looks great, but can be very slow.

My thinking is this. How about finding a way to calculate the surface curvature of an object in order to "fill in" the concave areas of a surface with "dirt" (i.e. Ci = Brown; with a varying amount of noise based on the curvature of a surface).

Is there a way to find how concave/convex a surface is in SL? Maybe via the gather() loop?
Old 08 August 2003   #2
I know how to do this with raytracing. But a solution that works from a map generation would be darned nice.

In a raytracing solution with slim and prman, you just use a constant surface shader, connect a colorspline to the color node, and select the type as occlusion.

It takes a long time to get a good quality occlusion tho.

Don't look, don't look, the shadows breathe...
Old 08 August 2003   #3
maybe just get the point normals, then compare them to work out where the folds are. of course this method would only work for surface that are facing outwards. and it would work as a basic vertexmap (though if you were to use some bspline interpolation then you might get a good result with the shading).
The Third Party | Homepage | My Reel
"You need to know what you're doing before you start, and to start because you need what you're doing."
Old 08 August 2003   #4
The local curvature of a surface is given by its second derivative. This is (relatively) trivial for a NURBS surface (But you have to be able to reparameterize the surface by chord length first).

You might be able to get an approximation to the second derivatives by using SL functions Du() and Dv(). Try:

float ucurve = length(Du(dPdu));
float vcurve = length(Dv(dPdv));

ucurve and vcurve probably wouldn't give you anything meaningful mathematically, but you might be able to use them to get some kind of idea about local curvature.

A better method would be to calculate the local curvature directly. Again, it's relatively easy for NURBS (although I haven't actually done it), but it's a bit harder for polygons. I've implemeted a couple of methods for estimating various meaures of curvature per vertex. You could then attach these data as vertex variables and access them in your shader. If you're interested, I could dig the relevant papers up and send you links or PDF's.

As for the gather() loop method you've postulated, one way to do it would be to use gather in a seperate pass to gather the illumination from the object itself in isolation (see the colour cleeding examples in the RAT docs). The areas of your surface that receive mroe illumination back will be more concave. However, this is pretty much what ambient occlusion already does, except in a different way, and AO would probably do it faster

You can have your characters photoreal, fast or cheap. Pick two.
Old 08 August 2003   #5
Yes, I've been using the dirtmap approach + ambient occlusion (we called it a "surface exposure map" then) since about six years here.
Even two years earlier, 1994, a paper got published, that described pretty detailed what we call "ambient occlusion" today (look at figure 2.11 at page 18 of the paper). But even its author didn't realize that his approach could also be used to model an aspect of lighting, rather than just surface exposure for dirt accumulation.
Tien-Tsin Wong, the author, also published two further papers. The last one, from 1997, pretty much sums up the techniques from the first and the second regarding procedurally dirtying up objects and -- unlike the first one -- also contains color plates.

The curvature shader I additionally sometimes use for procedurally scratching or peeling off paint from metal surfaces etc., is based on this one.

Note that particularly raytracing RMan renderers may either not provide 2nd order derivatives at all (making it impossible to use the curvature shader at all) or not provide 2nd order derivatives on reflected rays (making it impossible to reflect the curvature pattern on another geomery using raytracing w/o baking the curvature as a texture beforehand).
An example of such a renderer is (was) BMRT.


Render faster, get to the party earlier — /*jupiter jazz*/

Last edited by Mauritius : 08 August 2003 at 02:52 AM.
Old 01 January 2006   #6
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
Thread Closed share thread

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump

All times are GMT. The time now is 10:52 AM.

Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.