POV-Ray : Newsgroups : povray.unofficial.patches : MegaPov 1.1 motion_blur meany samples vs adc_bailout Server Time
14 May 2024 00:48:37 EDT (-0400)
  MegaPov 1.1 motion_blur meany samples vs adc_bailout (Message 1 to 3 of 3)  
From: Rafal 'Raf256' Maj
Subject: MegaPov 1.1 motion_blur meany samples vs adc_bailout
Date: 19 Nov 2004 12:19:54
Message: <Xns95A6BACE561F5raf256com@203.29.75.35>
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

From: Rafal 'Raf256' Maj
Subject: Re: MegaPov 1.1 motion_blur meany samples vs adc_bailout
Date: 19 Nov 2004 23:21:42
Message: <Xns95A736DCD3237raf256com@203.29.75.35>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.