In article <393948d4@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> First I want to say that I think Megapov is really great!

You are certainly not alone!


> Secondly I want to say that I have some suggestions for improvements. (Is
> this the correct group for this?)

Yes, this is the correct group.


> 1) Make the center of the patterns appear in the center of the image. 
> Make <-0.5,-0.5,0> be the lower left corner (instead of <0,1,0>) and 
> <0.5,0.5,0> the upper right corner (instead of <1,0,0>). This will 
> make the patterns in patterned blur work in the same way as normal 
> patterns in the camera statement does.

I chose to have upper left be <0,1,0> and lower right be <1,0,0> for all 
of the filters which use pigments, so it would be easy to control the 
filter with an image_map(useful for logos, etc). If it is "centered", 
the image_map has to be translated into position.
I really didn't even think about camera normals...I think the method I 
chose is more intuitive and easier to use.


> 2) Make the amount of blur resolution-independent. Blur the image 
> based on % of width or something instead of in pixels. I really think 
> we should continiue the lovely idea that everything in a POV-Ray 
> image is completely resolution independent.

This is certainly a good suggestion, I would have done it if I had 
thought of it...


> 3) Support "non-integer blurring". Currently when you use patterned 
> blur certain bands appear because only "integer pixel blurring" is 
> supported, and not the values in between. It shouldn't be too hard to 
> support non-integer values too (said by a regular user unable to 
> program pathes himself).

I don't understand what you mean here...the color values averaged 
together are float type, not integer. Or do you mean non-integer blur 
amounts? The patch should already do that...the radius variable is a 
"DBL", or "double", and is multiplied with the red channel of the 
pigment color, which is a floating point number("COLC", or float).
Or do you mean the colors between pixels? That is not part of the 
available data, it would have to be interpolated from the surrounding 
pixels.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message