|
Hmm, no idea if I just missed the point, sorry in case I did... :)
Tim Leydecker wrote:
Ok, this takes us absolutely nowhere, either you don't want to
understand that both of us talk about the very same thing or my
english simply is too bad to make people understand what I'm talking
about. Anyhow, I'm off this thread now, there's everything said and
repeated at least once.
Butting into this thread for being an expert at misreading the
intended tonality of a post and also being gifted with a most
natural talent to stir things up in a somewhat disturbing way:
"...Mitchell filtering, which in most setups needs higher radii to
create nice-looking imagary, many more samples are taken into
consideration for a single pixel's colour value...."
indeed you did...
I´d say Steve just wanted to admit he had missed that bit in your
previous post and even had the balls to do it in public. One could
find a trace of sarcasm in it if it where written in german but I think
it isn´t meant to be taken that way - as it´s not written in german...
"Ja, und?"
"Oder was?"
Cheers
tim
----- Original Message ----- From: "André Adam" <a_adam(at)49games.de>
To: <XSI(at)Softimage.COM>
Sent: Tuesday, June 06, 2006 10:18 AM
Subject: Re: Mental Ray render settings was "Re: shadow flicker"
Ok, this takes us absolutely nowhere, either you don't want to
understand that both of us talk about the very same thing or my
english simply is too bad to make people understand what I'm talking
about. Anyhow, I'm off this thread now, there's everything said and
repeated at least once.
Steven Caron wrote:
"...Mitchell filtering, which in most setups needs higher radii to
create nice-looking imagary, many more samples are taken into
consideration for a single pixel's colour value...."
indeed you did...
On 6/5/06, *André Adam* <a_adam(at)49games.de
<mailto:a_adam(at)49games.de>> wrote:
"filtering doesn't decide how many samples are taken..."
Hey Steven, that's exactly what I've said, reread my mails.
However, the
filter size *does* decide on how many samples will be combined
for a
single pixel *after* all rays are shot by creating an ellipse
around the
center of that pixel and collecting all the samples within the
given x/y
radii.
Your observations regarding the eye-rays are interesting,
though. We
seem to have a few extra rays in there, but I see the basic idea of
samples = pixels with a sampling value of 0 still being valid,
don't you
think? At least I can live with a variance of less than ten
percent... ;)
Steven Caron wrote:
> /deep breath!
>
> /filtering doesn't decide how many samples are taken...
>
>
file:///C:/Softimage/XSI_5.0/Doc/mental_ray/manual/node76.html#INDEX188
>
> "...The *filter* statement specifies how multiple samples are
to be
> combined into a single pixel value..."
>
> and if you just take look at jitter thats only two definitions
down
> from filter...
>
> "...Without *jittering*, samples are taken at the corners of
pixels or
> subpixels..."
>
> and if you turn jitter on. with AA min 0 and max 0... mental ray
> kindly turns jitter off :) why? Because it will introduce
artifacts
> with that low of a sampling rate...
>
> //INFO : RC 0.2 warn 082008: jittering disabled because max
> samples < 1
>
> So according to you a 100 x 100 render would produce 10000
samples? (
> eye rays ) Lets test this!
>
> I setup a format of... 100 x 100. AA min of 0 and max of 0.
Jitter
> OFF. Threshold rgba to 1.0 and filter type box 1 1, but threshold
> doesn't matter because of min and max samples being the same and
> filter doesn't matter because it only averages samples already
taken.
>
> turn progress on...
> //INFO : RC 0.2 info : rendering statistics
> //INFO : RC 0.2 info : type
number per
> eye ray
> //INFO : RC 0.2 info : eye rays
> 10816 1.00
>
> hmmm interesting!
>
> I am going to throw another variable in here... task size or tile
> size. this option will really increase or decrease your
samples...
> smaller task size is going to give you more samples.. larger is
going
> to give you less. Here is a quick formula for predicting
samples. I
> say predicting, because there is no way to know everything
they are
> doing internally, short of being a mental images developer.
>
> task size + 1 * task size + 1 = samples per tile...
>
> To test this make a 32 x 32 resolution AA min 0 max 0 and turn
your
> "tile size" to 32x32. You can leave automatic in cause most
likely
> mental ray will choose this, but just in case force it. you
know so
> you feel like your in control. You will get...
>
> 32 + 1 * 32 + 1 = 1089
>
> have fun.. do some more tests...
>
> André Adam wrote:
>
>> To add to this, the position sampled is only important for the
>> filtering algorithm that collects samples using a specific
radius
>> around the center of the pixel. With an aa setting of 0 and a
box
>> filter with a size of 1, indeed four samples will be
considered to
>> retrieve the final colour value for this pixel. However, hardly
>> anyone uses a box 1/1 filter. When switching to the more popular
>> Mitchell filtering, which in most setups needs higher radii to
create
>> nice-looking imagary, many more samples are taken into
consideration
>> for a single pixel's colour value. However, the sample
density shot
>> by the renderer *does not* increase in this scenario, with aa
0 it
>> stays one sample shot per pixel.
>>
>>
>> André Adam wrote:
>>
>>> Nope, with aa 0 you get exactly as many samples as you have
pixels
>>> for the whole image. It definately is one sample per pixel. Not
>>> centered, but that doesn't make much of a difference, the
spacing
>>> between the samples stays one pixel regardless of the position
>>> sampled. It's just about offsetting the sampling raster.
Which btw
>>> gets randomised anyways when enabling the sample jitter option.
>>>
>>> Cheers!
>>>
>>> -André
>>>
>>>
>>> Steven Caron wrote:
>>>
>>>> "...and one sample per pixel (aa setting 0)..."
>>>>
>>>> just like bernard and kim said about threshold being
misunderstood
>>>> this too is misunderstood.
>>>>
>>>> mental ray samples at the corners of a pixel. meaning 4 per
pixel
>>>> not 1. but not always 4 new samples because mental ray can
share
>>>> samples with bordering pixels.
>>>>
>>>> *bracing myself now*
>>>>
>>>> steven
>>>>
>>>> On 6/2/06, *André Adam* <a_adam(at)49games.de
<mailto:a_adam(at)49games.de>
>>>> <mailto:a_adam(at)49games.de <mailto:a_adam(at)49games.de>>> wrote:
>>>>
>>>> A really nice example covering this problem is a
hemisphere mapped
>>>> with
>>>> a clear night sky showing lots of small stars. If the
min aa
>>>> setting is
>>>> too broad (and one sample per pixel (aa setting 0)
might very
>>>> well be
>>>> too broad), the rays will likely completely miss out
certain
>>>> stars on
>>>> certain frames which leads to the stars wildly
flickering in
>>>> animation...
>>>>
>>>>
>>>> kim aldis wrote:
>>>>
>>>> >I'm not trying to put you down here Bernard but there are
>>>> situations where
>>>> >settings like this aren't good and you should have some
idea of
>>>> what sort of
>>>> >image you're rendering before making decisions about aa
settings.
>>>> In some
>>>> >shots, messing with threshold won't make any difference
at all,
>>>> raising max
>>>> >settings will make little difference unless you bring up
the min
>>>> settings.
>>>> >You're right, threshold is largely misunderstood. Let's
try and
>>>> shed some
>>>> >light:-
>>>> >
>>>> >here's something you can try. Get a cube, unit 1. scale
it so
>>>> it's really
>>>> >long and really thin - 0.02, 0.02, 35.
>>>> >now duplicate it 20 or 30 times and space each cube
one unit
>>>> apart in x. Now
>>>> >shift them all back away from the camera so you get a
good
>>>> convergance. Lots
>>>> >of thin, parallel lines in the distance, all converging
to the
>>>> vanishing
>>>> >point is what you're looking for.
>>>> >
>>>> >Now mess with the aa settings and pay close attention
to the
>>>> quality where
>>>> >the cubes are nearly converging. Try 0,3 and mess with
the
>>>> threshold. Not a
>>>> >lot of difference, is there, even if you set the
threshold really
>>>> as low as
>>>> >you can get it. In fact, changing the threshold varies
not a lot
>>>> at all.
>>>> >
>>>> >now compare 0,2 with 0,3. Not much better. And I'll bet
if you
>>>> try 1,2 it'll
>>>> >be way better than 0,3. Again, regardless of the
threshold.
>>>> >
>>>> >The point here is that there's a real danger of getting
it wrong
>>>> if you
>>>> >start generalising aa settings and don't take into
account the
>>>> kind of image
>>>> >you're rendering, as Helen is finding out, since
sampling grain
>>>> is fine
>>>> >detail. I just tried something here. Pushing aliaising
to 1,2
>>>> with default
>>>> >threshold gave me better improvement than doubling the
>>>> sampling size.
>>>> >lowering the threshold improved things a bit but nothing
worked
>>>> better - nor
>>>> >was faster - than raising the min setting, bringing it
closer to
>>>> the max.
>>>> >
>>>> >If you really want to see how well - or otherwise - aa is
>>>> working, turn on
>>>> >'view sampling' in the region diagnostic tab. It's most
>>>> revealing.
>>>> >
>>>> >-----Original Message-----
>>>> >From: owner-xsi(at)Softimage.COM
<mailto:owner-xsi(at)Softimage.COM> <mailto:owner-xsi(at)Softimage.COM
<mailto:owner-xsi(at)Softimage.COM>>
>>>> [mailto: owner-xsi(at)Softimage.COM
<mailto:owner-xsi(at)Softimage.COM> <mailto:owner-xsi(at)Softimage.COM
<mailto:owner-xsi(at)Softimage.COM>>]
>>>> On Behalf Of
>>>> >Bernard Lebel
>>>> >Sent: 01 June 2006 16:23
>>>> >To: XSI(at)Softimage.COM <mailto:XSI(at)Softimage.COM>
<mailto:XSI(at)Softimage.COM <mailto:XSI(at)Softimage.COM>>
>>>> >Subject: Re: shadow flicker
>>>> >
>>>> >I would definitely use a min of 0 and a max of 3.
>>>> >
>>>> >Also, what is generally ignored or misunderstood is the
treshold.
>>>> The
>>>> >treshold color is a control for how sampling is done.
Lower
>>>> values means
>>>> >that sampling occurs with lower contrasts, in other
words, the
>>>> level of
>>>> >sampling have more chances of getting closer to the max
value.
>>>> Higher
>>>> >treshold means a higher contrasts is tolerated before
requiring
>>>> another
>>>> >level of sampling, so less samples may be takne.
>>>> >
>>>> >I never work with treshold higher than 0.05, and had to
go as
>>>> low as
>>>> >0.005 on few occasions. Note that at that point, if the
image is
>>>> detailed,
>>>> >you should consider ignoring adaptive sampling
altogether and use
>>>> same min
>>>> >and max values. If the image has significant amounts of
constant
>>>> colors
>>>> >(like shadow passes, black backgrounds in the likes),
then
>>>> adapative
>>>> >sampling is still a viable solution.
>>>> >
>>>> >
>>>> >Lastly, my rule of thumb for the filtering is Gaussian
3/3 for TV
>>>> output and
>>>> >Mitchell 4/4 for film output. Gaussian gives a blurrier
sample
>>>> >interpolation, which may "conceal" minor imperfections.
>>>> >
>>>> >
>>>> >
>>>> >Cheers
>>>> >Bernard
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >On 6/1/06, Helen Bucknall <helen(at)helenbucknall.com
<mailto:helen(at)helenbucknall.com>
>>>> <mailto: helen(at)helenbucknall.com
<mailto:helen(at)helenbucknall.com>>> wrote:
>>>> >
>>>> >
>>>> >>Mostly I just use min -1 and max 2. and box filtering
1 or
>>>> sometimes I
>>>> >>use triangle 2 for a softer effect.
>>>> >>
>>>> >>I output a string of 852 x 480 bmps to my clients and
then
>>>> they mpeg
>>>> >>it somehow and wack it up on big plasma screens. They
never
>>>> complain.
>>>> >>When they want stills for print I just render a frame
out huge
>>>> >>(3000+)but leave the antialiasing the same.
>>>> >>If it's for telly I do HD res. If it's to be comped
with live
>>>> action I
>>>> >>ask what anti aliasing they want.
>>>> >>
>>>> >>
>>>> >>
>>>> >>Bernard Lebel wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >>>Samples 20 is a bit low. I generally put 64 as soon as
I set
>>>> up the
>>>> >>>shadow map.
>>>> >>>
>>>> >>>What do you mean with "standard antialiasing"?
>>>> >>>
>>>> >>>
>>>> >>>Bernard
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>On 5/31/06, Helen Bucknall <helen(at)helenbucknall.com
<mailto:helen(at)helenbucknall.com>
>>>> <mailto:helen(at)helenbucknall.com
<mailto:helen(at)helenbucknall.com>>> wrote:
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>>>OK. I dragged the spotlight in closer to the scene
elements
>>>> and it
>>>> >>>>seems to have stopped all the flickering! It wasn't
that far
>>>> away,
>>>> >>>>but now it is almost close enough to make my character
>>>> sweaty. I
>>>> >>>>also scaled down my ground plane a tad.
>>>> >>>>
>>>> >>>>Just using 1024 res and sample 20. And bog standard
>>>> antialiasing.
>>>> >>>>
>>>> >>>>So very BIG THANKS to all who replied!
>>>> >>>>
>>>> >>>>Joe Laffey wrote:
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>>On Wed, 31 May 2006, Helen Bucknall wrote:
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>>Is there a way to get shadow map shadows to stop
>>>> flickering even
>>>> >>>>>>when nothing is moving?
>>>> >>>>>>
>>>> >>>>>>This is what I have tried to no avail.
>>>> >>>>>>
>>>> >>>>>>On the spot light (cone angle less than 90):
>>>> >>>>>>Resolution up ( and down).
>>>> >>>>>>Softness up and down.
>>>> >>>>>>Samples up.
>>>> >>>>>>
>>>> >>>>>>None of these make any diference to the flickering.
>>>> >>>>>>
>>>> >>>>>>On the render panel:
>>>> >>>>>>I've played around with the antialiasing and jitter.
>>>> >>>>>>On the shadows page I've clicked off rebuild.
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>>If you view your scene from the light is there an
>>>> extremely large
>>>> >>>>>depth to the objects? In other words, are the closest
>>>> object to
>>>> >>>>>the light and the farthest object from the light
extremely
>>>> far
>>>> >>>>>apart? This can lead to ZDepth (used for shadowmaps)
>>>> presision
>>>> >>>>>issues in some renderers.
>>>> >>>>>
>>>> >>>>>This is often the case if you have a huge ground
plane.
>>>> >>>>>
>>>> >>>>>You may be able to exclude some objects, to help, or
make
>>>> smaller
>>>> >>>>>versions that catch shadows.
>>>> >>>>>
>>>> >>>>>--
>>>> >>>>>Joe Laffey | Visual Effects for
Film and
>>>> Video
>>>> >>>>>LAFFEY Computer Imaging |
>>>> -------------------------------------
>>>> >>>>>St. Louis, MO | Show Reel
>>>> http://LAFFEY.tv/?e01274
>>>> >>>>>USA
>>>> >>>>>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
|
