 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Using radiosity in animation is realy a CPU-killer, because animation needs
about x2 to x4 _better_ quality then still image, to get rid of annoying
flickering.
Would it be a good idea maybe to interpolate radiosity colors between
frames?
For example - low quality calculation informed that in frame #0 apple is
lighten by rgb .5 from radiosity, and in frame #1 by .55 - it looks like a
flickering bug, so we close-interpolate(*) thoes value and have result of
about 0.51 with is simmilar to 0.50 and gives no distraction why watching
animation.
In other situation - colors 0.5, then 0.9 - difference is too big to be
just a bug probably, more likely - object moved out of shadow, or there is
new light source, etc etc. Then we far-interpolate(**) values and have
result of 0.85 for example - so that fast lighting changes that are NOT
bugs are preserved (not motion-blurred).
(*) "close-interpolation(A,B)" as I called it will return value more
simmilar to A. interpolated = A*m + B*(1-m), where m=~0.1;
(**) same, but m=~0.9;
Implementation - currently POV stores location of radiosity point and it's
color (in some way, AFAIK). We add also frame-number to it, so we will
store information frome current and 1 or 2 pastframes.
If current value is near to old value (it probably describes same object,
or same place in scene space) it will be blended with old one, and too old
values (mmore then 3 frames old) will be deleted to save memory.
In addition - if while calculating radiosti sample it looks like it is very
simmilar to previous value, we can skip it's calculations and just assume
that this point didn't change (and perhaps - calculare nearby points with
lower radiosity settings). This should increase several times(!) render
speed of almost-constant areas (in frames in with they do not change).
It should allow to render animations with even _lower_ radiosity settings
and givind higher quality, especialy if scene is not too dynamic.
Any comments are welcomed.
--
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj wrote:
> Using radiosity in animation is realy a CPU-killer, because animation needs
> about x2 to x4 _better_ quality then still image, to get rid of annoying
> flickering.
Actually, since MPEG compression removes certain kinds of detail, a
still generally requires more quality than a equal frame from an
animation.
When working on the IRTC, I try to keep the rendering times above
20 pixels per second. If for some reason this objective is not
met, I look for ways to make the scene render faster.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj wrote:
> Using radiosity in animation is realy a CPU-killer, because animation needs
> about x2 to x4 _better_ quality then still image, to get rid of annoying
> flickering.
>
> Would it be a good idea maybe to interpolate radiosity colors between
> frames?
Could you post a totally _minimal_ and as small as possible scene
(including the radiosity settings, of course) which shows the effect.
I have the feeling that you are just using wrong kind of radiosity
settings and the flickering might be the result of that. By altering the
settings you might reduce flickering and even speed up the render times.
I don't think your proposed method is a good way to solve it as it is
based on assumption that povray's radiosity values are false and allways
need to be interpolated. I think the only solution is to get correct
(not 100% accurate, but satisfactory) values in the first place.
Regards,
Severi Salminen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
sev### [at] NOT_THISsiba fi news:410d4a39$1@news.povray.org
> Could you post a totally _minimal_ and as small as possible scene
> (including the radiosity settings, of course) which shows the effect.
Every scene probably,
> I have the feeling that you are just using wrong kind of radiosity
> settings and the flickering might be the result of that. By altering the
> settings you might reduce flickering and even speed up the render times.
ok, simple scene with a box-room, with several windows in it walls and
celing, with sun (arealight) shining from above + sky_sphere light.
Everything, even plain walls (just simple rgb .7) are flickering, when
camera is moving. Room is about 100x100x100 units, and only moving
elemenent in scene are two small spheres (1 unit radius) and they are not
near light source etc etc, so realy oit should NOT flicker.
> I don't think your proposed method is a good way to solve it as it is
> based on assumption that povray's radiosity values are false and allways
> need to be interpolated. I think the only solution is to get correct
> (not 100% accurate, but satisfactory) values in the first place.
If adjusting radiosity settings in 3.6 will do it - I will be very glad :)
Currently I'm using:
global_settings {
adc_bailout 1/64 max_trace_level 20
#if (QQ_RAD) radiosity { brightness 1 gray_threshold 0 max_sample 2
normal on
#if (QQ_RAD=1)
adc_bailout 1/64 recursion_limit 3 count 35 error_bound 1.8
minimum_reuse 0.015 nearest_count 5 pretrace_start 0.08
pretrace_end 0.04
#end
#if (QQ_RAD=2)
adc_bailout 1/64 recursion_limit 3 count 80 error_bound 1.2
minimum_reuse 0.014 nearest_count 7 pretrace_start 0.08
pretrace_end 0.04
#end
}#end
#if (QQ_PHOT)
photons {
#if (QQ_PHOT=1) count 100*1000 adc_bailout 1/40 #end
}
#end
}
Flicker is visible both QQ_RAD = 1 or 2, and QQ_PHOT on and off.
--
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj wrote:
>>Could you post a totally _minimal_ and as small as possible scene
>>(including the radiosity settings, of course) which shows the effect.
>
>
> Every scene probably,
Nope, I just made a small (windowless) room with a single sphere and
camera moving and saw no flickering at 320x240@30fps resolution so it
must be something else.
> ok, simple scene with a box-room, with several windows in it walls and
> celing, with sun (arealight) shining from above + sky_sphere light.
>
> Everything, even plain walls (just simple rgb .7) are flickering, when
> camera is moving. Room is about 100x100x100 units, and only moving
> elemenent in scene are two small spheres (1 unit radius) and they are not
> near light source etc etc, so realy oit should NOT flicker.
Could you prepare a minimal scene for me (and others too, of course)
that shows clearly this flickering - also a short animation would be
nice. Try to make it as simple and as fast to render as possible. Also
state all the output and render settings (resolution etc.) and how you
compile the actual movie (which format, bitrate, program...).
Regards,
Severi Salminen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
sev### [at] NOT_THISsibafi news:410d5b8d$1@news.povray.org
> Could you prepare a minimal scene for me (and others too, of course)
> that shows clearly this flickering - also a short animation would be
> nice. Try to make it as simple and as fast to render as possible.
Oki, it might tak a wile but I will do it (currently both my PCs are
rendering ~5 days animation).
> Also
> state all the output and render settings (resolution etc.) and how you
> compile the actual movie (which format, bitrate, program...).
I watch raw pov output (or - convert .png's into uncompressed RGB avi or
losseless MPNG, or losseless YUV codec).
Perhaps flickering _is_ there, but codec get rigs of it for YOu (decreasing
output quality)? The flickering is quite delicate (but still notacible in
hi-quality movie) - can You check also .png's before compression?
under linux You ca ndo it easyly by:
http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-enc-images.html
mencoder mf:// -mf fps=25:type=png -ovc raw -oac copy -o output.avi
(or lower FPS rate).
Btw, is there a good, easy to use image viewing program for Linux that can
use one key (like space-bar) to go to next image in directory (something
like irfanview or ACDsee)?
PS Can You please present source of YOur's test scene?
--
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
sev### [at] NOT_THISsibafi news:410d5b8d$1@news.povray.org
> Nope, I just made a small (windowless) room with a single sphere and
> camera moving and saw no flickering at 320x240@30fps resolution so it
> must be something else.
Oh, and important detail (next to watching uncompressed and not post-
processed animation) - flickering is visible in shadows / area's not
lighted directly by light source, but only by light diffused from other
objects (because in that places radiosity calculations are much harder).
--
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj wrote:
> I watch raw pov output (or - convert .png's into uncompressed RGB avi or
> losseless MPNG, or losseless YUV codec).
>
> Perhaps flickering _is_ there, but codec get rigs of it for YOu (decreasing
> output quality)? The flickering is quite delicate (but still notacible in
> hi-quality movie) - can You check also .png's before compression?
True, I made a mpeg so it might reduce the flickering. I have to find a
way to make uncompressed movies.
> Btw, is there a good, easy to use image viewing program for Linux that can
> use one key (like space-bar) to go to next image in directory (something
> like irfanview or ACDsee)?
Sorry, I know nothing about Linux :(
> PS Can You please present source of YOur's test scene?
Here is a very simple scene. Check if you can see the flickering and
tell the output settings. And if there is no flickering could you alter
the scene (or compose a new one) to show it clearly. Even better if you
can remove the camera movement and still show it (easier for others to
see it then).
#default{finish {ambient 0}}
camera {
location <80-clock*160,50,-80>
look_at <0,50,0>
direction z*0.7
}
light_source {<-80,80,-50> rgb 1}
box{<-100,0,-100>,<100,100,100>
pigment {rgb 1}
}
sphere {<-70+clock*140,60,0>,25
pigment{rgb <1,0,0>}
}
global_settings {
radiosity {
count 35
error_bound 1.8
}
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
sev### [at] NOT_THISsibafi news:410d6696$1@news.povray.org
> Here is a very simple scene.
Maybe try to put big part of a room in shadow, for example like:
light_source {<-80, 80 +100 ,-50> rgb 1}
difference {
box { <-105,0,-105>, <105,105,105> }
box { <-100,0,-100>, <100,100,100> }
cylinder { y*99, y*106, 70 }
pigment { rgb 1 }
}
--
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 01 Aug 2004 17:28:20 -0400, Rafal 'Raf256' Maj wrote:
>
> Btw, is there a good, easy to use image viewing program for Linux that can
> use one key (like space-bar) to go to next image in directory (something
> like irfanview or ACDsee)?
>
I really like gqview http://gqview.sourceforge.net/
It does what you want in forward and reverse plus many other cool features.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
