|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Small problem that I come across, perhaps it's worth mentioning in docs?
// by Rafal Maj 'Raf256', Copyrighted (C) 2003 http://www.raf256.com/pov/
// from p00282 "arom gamma logo" atom_logo_gamma
// shows a possible problem of MegaPov 1.1 in MotionBlur
// http://megapov.inetart.net/manual-1.1/megapov011.html#enable
#version unofficial megapov 1.1;
global_settings {
adc_bailout 1/600 // <-- needed !
// adc_bailout 1/256 // leaving this deffault will lead to a problem.
motion_blur 400, 1/24
}
background { rgb z*.4 }
camera { location -z*10 }
motion_blur { type 1
sphere { z, 1 rotate y*clock*4000
pigment { rgb 1 } finish { ambient 1 }
}
}
I would add to docs:
2.5.2. Motion blur
[...]
SAMPLES is the number of time-frames that will be sampled. More samples
will give smoother results, but will take longer to render.
+++ Reasonable values for most purposes are usually 20..100. When using
very high quality, especially with samples > 256 please remember to adjust
adc_bailout as well (set it to 1/300 or lower). In other case each copy of
blurred object will be too transparent to be noticed, and will be rendered
as a black spot.
--
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: MegaPov 1.1 motion_blur meany samples vs adc_bailout
Date: 19 Nov 2004 15:38:55
Message: <419e59df@news.povray.org>
|
|
|
| |
| |
|
|
In article <Xns95A6BACE561F5raf256com@203.29.75.35>, "Rafal 'Raf256' Maj"
<spa### [at] raf256com> wrote:
> Small problem that I come across, perhaps it's worth mentioning in docs?
If it really is a problem (I don't know), then a warning and auto-adjusting
adc_bailout when not explicitly set might be a more "practical" solution for
all those who do not read the documentation :-)
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
tho### [at] trfde news:419e59df@news.povray.org
> If it really is a problem (I don't know), then a warning and
> auto-adjusting adc_bailout when not explicitly set might be a more
> "practical" solution for all those who do not read the documentation
> :-)
I also have a better (probably) idea, and I hope not hard to implement,
1. ray that exceeded max_trace_level should return it current color (stop
calculations) instead of returning black rgb 0,0,0 (by the way, not
connected directly to this problem).
2. ray that hits motion_blur object that is too "small" i.e. rgb 0.001 to
be noticed - just returns it current color (calculated so far). _but_ if
the rgb 0.001 object is the _first_ object to be hit, then current color
can not be returned, because no object had been hit yet. In that case -
0.001 object is taken intoo account, and ray continues to go along, until
hit solid surface or exceed max_trace_level, or until stoped by "to small"
reflection (lower then adc_bailout)
3. they might be several types of adc_bailout
reflection_adc
refraction_adc
transparent_adc
motionblur_adc (with defaults to transparent_adc)
and perhaps
general_adc to quickly set all above.
Would it be hard to implement? If someone will implement it please inform
me so I might assist.
--
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|