A reasonable solution would be to make several
stills from various points of view WITH radiosity,
and then try to reproduce that with different
amounts of spotlights, fading light, with/without
shadows, etc. A recent animation, "Runtime" used
the same approach, and several other animation
do it to, because of inconsistencies of radiosity
or global illumination with changing scenery.

Regards,
Tim

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de


> > There were workarounds for this
>
> I haven't heard of a workaround. Let us know if you find any, please. For
> most animations, I'd stay away from radiosity.
>
> Regards,
> Hugo
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 01.09.2003

Post a reply to this message

None wrote:
> I don't have that codec either.  I find it funny all of these codecs now 
> that call themselves ISO MPEG-4 compliant... what's the point if none of 
> them work together or without special software/codecs?  I mean if you need 
> special software/codecs to view/encode it, who cares if it's compliant or 
> not?

Of course there is many codecs... We have divx*, xvid, mpeg4*...

For next animations for public release i will use the old good MPEG 1 
encoding (files are little more heavy but compatibility is here).


-- 
Denis Bodor (aka Lefinnois)

Post a reply to this message

On Sun, 14 Sep 2003 20:07:44 +0200, "Hugo Asm" <hua### [at] post3teledk> wrote:
> > There were workarounds for this
>
> I haven't heard of a workaround. Let us know if you find any, please. For
> most animations, I'd stay away from radiosity.

I remember one with generating radiosity file for one frame and reusing it for
others frames. Other was to use specific radiosity settings (detailed?
simplified?) I do not remember details, sorry. Perhaps memory mistaken me, but
I still have feeling there were a few workarounds presented. I'd stay away
from radiosity, myself, too.

ABX

Post a reply to this message

Hi everybody!

Can anybody explain to me *why* this happens?

Thanks,
Florian
-- 
//=================[web: http://www.torfbold.com]==================\\
#local a=-5;#while(a<5)sphere{<sin(a*pi)*5a*10pow(a,5)*.01>sin(a*a*a*
.1)+1pigment{rgb 9*z}}#local a=a+.01;#end camera{look_at-y*10location
<8,-3,-8>*10}// [www.povray.org]     [www.imp.org]     [www.irtc.org]

Post a reply to this message

The process used to shoot the samples for radiosity
is very much defined by the scenery. It actually
influences the calculations where new samples are
computed. I'm also not sure about the drop-out
of samples when enough are present in a near
vicinity. So, when the scene changes, the samples
get spread differently, even if its just miniscule
movement of one object.

The algorithm for this relies on sort-of spherical
samples. In my oppinion, its something close
to photon mapping, but thats just the interpretation
of samples being stored somewhere in the scene.
Their computation is very different from photon
lightmapping.

Regards,
Tim

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de


> Hi everybody!
>
> Can anybody explain to me *why* this happens?
>
> Thanks,
> Florian
> -- 
> //=================[web: http://www.torfbold.com]==================\\
> #local a=-5;#while(a<5)sphere{<sin(a*pi)*5a*10pow(a,5)*.01>sin(a*a*a*
> .1)+1pigment{rgb 9*z}}#local a=a+.01;#end camera{look_at-y*10location
> <8,-3,-8>*10}// [www.povray.org]     [www.imp.org]     [www.irtc.org]
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 01.09.2003

Post a reply to this message

"None" <Non### [at] onca> wrote in message
news:Xns### [at] 204213191226...
> Denis Bodor <lef### [at] lefinnoisnet> wrote in
> news:3f649350$1@news.povray.org:
>
> > [...]
> > It is xvid (coded with transcode and tested with mplayer)
> > [...]
>
> I don't have that codec either.  I find it funny all of these codecs now
> that call themselves ISO MPEG-4 compliant... what's the point if none of
> them work together or without special software/codecs?  I mean if you need
> special software/codecs to view/encode it, who cares if it's compliant or
> not?

I agree with what you are saying but without new stuff coming through you
would never get improvement or new compression features.

I personally think Xvid is one of the best codecs currently being produced
and has a very good file size to quality ratio.

It would be nice to see this become the standard and instead of the "good
old" mpeg 1 + 2 codecs.

Dave

For those that are interested the site is http://www.xvid.org

Post a reply to this message

Hi Tim!

I understand what you are saying, but shouldn't it be possible (in 
theory) to prevent this by using very high radiosity settings?

Thanks for your answer,
Florian
-- 
//=================[web: http://www.torfbold.com]==================\\
#local a=-5;#while(a<5)sphere{<sin(a*pi)*5a*10pow(a,5)*.01>sin(a*a*a*
.1)+1pigment{rgb 9*z}}#local a=a+.01;#end camera{look_at-y*10location
<8,-3,-8>*10}// [www.povray.org]     [www.imp.org]     [www.irtc.org]

Post a reply to this message

The codec problem is partly caused by Microsofts refusal to support by
default codecs which are rivals to its own Windows Media Video format. It's
a shame the Nimo codec pack isn't available for operating systems other than
Windows - if it were, it would be so much easier to keep up to date.

-Chris

Post a reply to this message

tor### [at] torfboldcom news:3f65ade5$1@news.povray.org

> I understand what you are saying, but shouldn't it be possible (in 
> theory) to prevent this by using very high radiosity settings?

yes, I did some tests with animating radiosity with diferrent settings.

For scenes like this problems shpuld dissapear with count=300 error=0.25


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

> > I understand what you are saying, but shouldn't it be possible (in
> > theory) to prevent this by using very high radiosity settings?
>
> yes, I did some tests with animating radiosity with diferrent settings.
>
> For scenes like this problems shpuld dissapear with
> count=300 error=0.25

It may reduce the flickering in some images to the extent where it's
nolonger visible. But it's still there.

Regards,
Hugo

Post a reply to this message