"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:

> > There are also other uses of AO like to bake it and use as a basis for dirt
> > maps, mask to mix different materials and many textures to process further.
>
> That's something else I'm working on, using the AO pass as an image_pattern mask
> to control grime and such in crevices, for an additional dirt/grime pass.

That's exactly what I did in this one:

http://news.povray.org/povray.binaries.images/thread/%3C48bfcfab@news.povray.org%3E/

Works really well I found - just a simple projection with Rune's illusion.inc of
the AO image onto a new grime/dirt pass.

Cheers,
Edouard.

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote:
> "Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
>
> > > There are also other uses of AO like to bake it and use as a basis for dirt
> > > maps, mask to mix different materials and many textures to process further.
> >
> > That's something else I'm working on, using the AO pass as an image_pattern mask
> > to control grime and such in crevices, for an additional dirt/grime pass.
>
> That's exactly what I did in this one:
>
> http://news.povray.org/povray.binaries.images/thread/%3C48bfcfab@news.povray.org%3E/
>
> Works really well I found - just a simple projection with Rune's illusion.inc of
> the AO image onto a new grime/dirt pass.
>
> Cheers,
> Edouard.

Hmm, the link isn't showing on the web news, but once I started to post this
message to mention that fact I noticed the URL shows in the flat text behind the
HTML.

That's cool, just what I was thinking of!

-------------------------------------------------
www.McGregorFineArt.com

Post a reply to this message

Am 09.03.2011 17:09, schrieb nemesis:

> But really, this is why pov-ray never quite gets much of a foothold:  only
> ingenious guys like you, Sam Benge, Jaime Vives Piqueres and a host of others to
> imagine such tricks.

Actually I think the main reason is simply that POV-Ray does things 
differently than all those mesh-and-shader renderers out there.

> it is a well known fact that the multipass approach
> is the way to go and that radiosity does not play fine with reflections,
> refractions, media and now SSS.

Well known maybe - but I doubt that it is a fact. The multipass approach 
has its limitations; for instance. AO breaks down for indoor scenes.

When it comes to CG movies, a multipass approach is no doubt a crucial 
timesaver, and the action hides the flaws rather easily; but for stills 
I'm sure it's not a cure-all.

> So, how about a multipass switch for povray, devs?  I mean, sure there's the
> quality switches going from 1 (plain constant ambient light) to 9 (full with
> radiosity), but the numbers going higher only add more effects, don't isolate
> them from one another.

This thread already spawned some background process in my brain :-) (Of 
course don't expect any such thing to appear in the very next release - 
I'm not /that/ fast :-P)

> I know it's a postprocess to combine the results and it
> is outside the scope of a raytracer,

I wouldn't really consider that postprocessing.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 09.03.2011 17:09, schrieb nemesis:
> The multipass approach
> has its limitations; for instance. AO breaks down for indoor scenes.

Only because its not true AO, just radiosity under an overcast sky. ;)

> When it comes to CG movies, a multipass approach is no doubt a crucial
> timesaver, and the action hides the flaws rather easily; but for stills
> I'm sure it's not a cure-all.

It's used in a bunch of radiosity HOF scenes to handle reflections without using
exponentially increased rendertimes and more radiosity artifacts (at least for
older radiosity)...

Also, it's not like as if povray wants to be a physically-based unbiased and
slow raytracer, is it?

> > So, how about a multipass switch for povray, devs?  I mean, sure there's the
> > quality switches going from 1 (plain constant ambient light) to 9 (full with
> > radiosity), but the numbers going higher only add more effects, don't isolate
> > them from one another.
>
> This thread already spawned some background process in my brain :-) (Of
> course don't expect any such thing to appear in the very next release -
> I'm not /that/ fast :-P)

http://t1.gstatic.com/images?q=tbn:ANd9GcQzbNX5-6wP4pyz32VitjtJt10WM47OzdGTJdqUcTiNIYpGCb83AA

>
> > I know it's a postprocess to combine the results and it
> > is outside the scope of a raytracer,
>
> I wouldn't really consider that postprocessing.

Better yet. :)

Post a reply to this message

Am 11.03.2011 11:30, schrieb nemesis:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 09.03.2011 17:09, schrieb nemesis:
>> The multipass approach
>> has its limitations; for instance. AO breaks down for indoor scenes.
>
> Only because its not true AO, just radiosity under an overcast sky. ;)

So what /is/ true AO? From the little I know it is an effect limited to 
a single object, to account for self-shadowing to some degree. Which is 
not needed in POV-Ray in the first place as it supports self-shadowing 
out of the box - not to mention that the distinction between self- and 
non-self shadowing would open up some definition problem as soon as CSG 
enters the scene).

> It's used in a bunch of radiosity HOF scenes to handle reflections without using
> exponentially increased rendertimes and more radiosity artifacts (at least for
> older radiosity)...

Yup, 3.6 radiosity was indeed prone to artifacts when reflections were 
involved, and those artifacts were virtually impossible to get rid of. 
No such problem in 3.7 anymore, and the new radiosity importance 
mechanism may be another useful tool to reduce render times in scenes 
with much reflection.

> Also, it's not like as if povray wants to be a physically-based unbiased and
> slow raytracer, is it?

Well, if /I/ am asked, I'd want POV-Ray to become a physically-based 
unbiased and /fast/ raytracer :-P

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 11.03.2011 11:30, schrieb nemesis:
> > clipka<ano### [at] anonymousorg>  wrote:
> >> Am 09.03.2011 17:09, schrieb nemesis:
> >> The multipass approach
> >> has its limitations; for instance. AO breaks down for indoor scenes.
> >
> > Only because its not true AO, just radiosity under an overcast sky. ;)
>
> So what /is/ true AO? From the little I know it is an effect limited to
> a single object, to account for self-shadowing

I think you got that wrong.  It's not about self-shadowing, but about accounting
for geometry occluding light from close geometry, like a sphere on the floor
generating shadows on the floor and the floor generating shadows on the sphere.
It also doesn't take light setups into account at all, just how close geometry
is to each other.  That is, it's perfectly possible to have AO in-doors in a
closed room, under a ceiling which is not emitting light (as would be needed in
radiosity).  AFAIK, the calculations needed involve purely the normals between
surfaces, like the shadowing in the corners of rooms where 2 walls join and even
more when floor or ceiling join in as well...

> > It's used in a bunch of radiosity HOF scenes to handle reflections without using
> > exponentially increased rendertimes and more radiosity artifacts (at least for
> > older radiosity)...
>
> Yup, 3.6 radiosity was indeed prone to artifacts when reflections were
> involved, and those artifacts were virtually impossible to get rid of.
> No such problem in 3.7 anymore, and the new radiosity importance
> mechanism may be another useful tool to reduce render times in scenes
> with much reflection.

That's awesome, no doubt!

> > Also, it's not like as if povray wants to be a physically-based unbiased and
> > slow raytracer, is it?
>
> Well, if /I/ am asked, I'd want POV-Ray to become a physically-based
> unbiased and /fast/ raytracer :-P

That would be great.

Post a reply to this message

> I think you got that wrong.  It's not about self-shadowing, but
> about accounting for geometry occluding light from close geometry,
> like a sphere on the floor generating shadows on the floor and the
> floor generating shadows on the sphere. It also doesn't take light
> setups into account at all, just how close geometry is to each other.
> That is, it's perfectly possible to have AO in-doors in a closed
> room, under a ceiling which is not emitting light (as would be needed
> in radiosity).  AFAIK, the calculations needed involve purely the
> normals between surfaces, like the shadowing in the corners of rooms
> where 2 walls join and even more when floor or ceiling join in as
> well...
>

   You're right here... I've researched AO a bit some months ago, and it
is all based on a "distance" parameter. In packages supporting AO, for
indoors, usually you have to set that distance to something less that
the distance between the floor and ceiling.

   BTW, I usually don't like the effect of indoor AO... perhaps because
most people usually abuse it.

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 11.03.2011 11:30, schrieb nemesis:
> > clipka<ano### [at] anonymousorg>  wrote:
> >> Am 09.03.2011 17:09, schrieb nemesis:
> >> The multipass approach
> >> has its limitations; for instance. AO breaks down for indoor scenes.
> >
> > Only because its not true AO, just radiosity under an overcast sky. ;)
>
> So what /is/ true AO? From the little I know it is an effect limited to
> a single object, to account for self-shadowing to some degree. Which is
> not needed in POV-Ray in the first place as it supports self-shadowing
> out of the box - not to mention that the distinction between self- and
> non-self shadowing would open up some definition problem as soon as CSG
> enters the scene).

Check out this SIGGRAPH 2008 presentation "Image-Space Horizon-Based Ambient
Occlusion" from nvidia that explains some variations of the process:

http://developer.nvidia.com/object/siggraph-2008-HBAO.html


-------------------------------------------------
www.McGregorFineArt.com

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> > So, how about a multipass switch for povray, devs?

> This thread already spawned some background process in my brain :-) (Of
> course don't expect any such thing to appear in the very next release -
> I'm not /that/ fast :-P)

That would be an awesome addition Christoph!

-------------------------------------------------
www.McGregorFineArt.com

Post a reply to this message

I've just uploaded to p.b.s.f. a code sample that demonstrates my technique for
multipass rendering and compositing directly in POV-SDL.  It's a standard zip
file containing an example multipass scene and an associated compositing scene,
along with my multipass and compositing include files, so please try it for
yourselves. Any suggestions for improvement are certainly welcome.

Also, I made a screen capture video that shows the entire multipass/compositing
process from start to finish. Usually ray tracing is about as fun to watch as
paint drying but I recorded the six render passes at ~11x normal speed. So, it's
actually sort of fun to watch (and it makes me drool for when, a few years from
now, our computers will actually /be/ that fast). Actual render time for all 6
passes was just under 22 min.; the video is just under 3 min.

The compositing part at the end is recorded at normal speed, so you can see the
compositing in real time, which is only a few seconds each. Well, except for the
depth pass; that takes a bit longer because it uses my auto-contrast macro to
loop through all the pixels of the depth pass image to find the darkest &
lightest pixels, and then makes those values 0 and 1 respectively, stretching
the mid tones to fit via linear interpolation. It took 35 seconds for the entire
compositing process.

The video is here: http://vimeo.com/20987441

And here's the result of using the AutoContrast_Grayscale() macro on the depth
pass for my example.

Cheers,
Rob

-------------------------------------------------
www.McGregorFineArt.com

Post a reply to this message

Attachments:
Download 'autocontrast_grayscale.png' (769 KB)

Preview of image 'autocontrast_grayscale.png'