|08 August 2003||#1|
Make way for the bad guy.
Join Date: Jan 2002
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?
|08 August 2003||#2|
Ritchie L Roberts
ZeroNeuro Arts Ltd.
Join Date: Jun 2002
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...
|08 August 2003||#3|
The Third Party
Join Date: Sep 2002
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).
|08 August 2003||#4|
Lord of the posts
pretty picture maker
Join Date: Jul 2002
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.
|08 August 2003||#5|
Hamburg, Milano, Tokyo, Singapore, Hong Kong
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.
|01 January 2006||#6|
Join Date: Sep 2003
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.
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
|Thread Closed share thread|