Thanks for the link.
I am doing multiple rendermaps with the camera in different positions, and
recombining them - this gives me a fairly good result.
It's just a lot of work - mostly because of the very slow rendering times
and instability of rendermap.
A 2k rendermap is 1.5 hours on average on the stuff I'm working on - regular
2k renders are less than 15 minutes. I'm scripting overnight renders of
several rendermaps which helps out a lot - but one night out of two
rendermap either crashes, freezes or simply disappears.
...
----- Original Message -----
From: "Halfdan Ingvarsson" <hingvars(at)Softimage.COM>
To: <XSI(at)Softimage.COM>
Sent: Tuesday, May 27, 2008 5:06 PM
Subject: RE: rendermap / lightmap SSS shader
It's not complicated what it does. It's basically a trick they used on
Finding Nemo, described in some Siggraph notes, but using the camera's pov,
rather than the light's pov. (see:
http://graphics.stanford.edu/facecourse/facecloning05/Presentations/scat.pdf
)
The lightmap contains the interleaved illumination of the front and back
surfaces (+depth of back) as seen from the camera, then the fast_sss shader
simply blurs the image samples based on distance, for each sample lookup.
This is why this trick won't work in a wraparound mode. If you froze the
lightmap and then orbited, the SSS effect would look quite funky where you
were viewing perpendicular to what the original camera's sampling position
was.
The only decent way to do it would be something along the lines of what Alan
describes.
- ½
-----Original Message-----
From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On Behalf Of
Alan Jones
Sent: 27-May-2008 10:55
To: XSI(at)Softimage.COM
Subject: Re: rendermap / lightmap SSS shader
On Tue, May 27, 2008 at 3:20 PM, peter boeykens <peter_b(at)skynet.be> wrote:
For "unsupporting" SSS - this seems lame - as it wouldn't take all
that much to get it to work.
The downfall is with the lightmap being camera dependent.
I dont think that's a limitation of lightmaps - as color sampler
lightmap is working with UV space.
The fast SSS shaders don't do anything akin to an ordinary lightmap in UV
space.
They use lots of strange trickery behind the scenes to do their work and Zap
is very tight lipped on their secret sauce used. Don't forget that Halfy is
an exceptionally intelligent guy, if there was something on his end he could
do to resolve this it would already be done.
There's nothing stopping you from writing/employing someone to write your
own SSS shader which could achieve similar speed using lightmaps by doing
some nice trickery to store to a kdtree/bih instead of a UV space texutre
and then looking that up within the main shader. It'd be nice and fast and
you'd avoid the camera dependency that makes fast SSS so unhappy.
Though if you use SSS a lot grab a copy of 3Delight - their SSS is
absolutely gorgeous, though I've not look at whether they support
rendermapping in XSI, though I'm sure Aghiles would be more than happy to
provide customers with something that does this within XSI in order to get
3Delight into a new facility.
Cheers,
Alan.
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
