 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Slime" <slm### [at] slimeland com>
> > AFAIK the focal blur is achieved by scattering the camera location
> > point in a rectangular area, while maintaining the focal point the
> > same. The size of this area is determined by the aperature keyword.
>
> Shouldn't it be a circular area for realism?
^^^^^^
correct ...
either that or you can start modelling complex shapes for a
probability model. Meaning, you support a greyscale bitmap
where black says "no here won't get a ray shooten from" and
white means that from here will get a ray shooten with the
highest probability.
This would allow you to form flare shapes as they sometimes
appear in photography; think of hexagonal or triangular ones.
The problem would be, that it will even slower to determine
the point.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
news: 3d6b4d0b@news.povray.org...
> Currently I am rendering a large version of a dice image. The dice points
> really get angularly. Does anyone know why?
>
See this page
http://www.kenrockwell.com/tech/bokeh.htm
There's a patch that implements this in POV-Ray that is currently being
ported to 3.5 (it's under testing and not available yet). From what I heard
it's faster that the regular focal_blur but I have not verified this myself.
G.
--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Shouldn't it be a circular area for realism?
> ^^^^^^
> correct ...
I don't think that's correct actually...
> either that or you can start modelling complex shapes for a
> probability model. Meaning, you support a greyscale bitmap
> where black says "no here won't get a ray shooten from" and
> white means that from here will get a ray shooten with the
> highest probability.
>
> This would allow you to form flare shapes as they sometimes
> appear in photography; think of hexagonal or triangular ones.
>
> The problem would be, that it will even slower to determine
> the point.
True, but I would be happy with the possibility to choose between a circular
area and an area in the shape of a regular polygon.
I was trying to do focalblur by averaging different renders earlier this day. I
came up with the following formula to scatter points inside a regular polygon:
#declare Seed=seed(whatever);
#declare angles=<insert number of angles here>;
#declare Rot=360*rand(Seed);
#declare X=pow(rand(Seed),.5);
#declare Rot2=Rot/(360/angles);
#declare fraqrot=Rot2-int(Rot2);
#declare fraqrot2=abs(fraqrot-.5);
#declare fraqrot3=pow(fraqrot2*2,.5);
#declare Location=vrotate(x*X*(.8+.2*fraqrot3),Rot*z);
This produces a random point within a regular polygon inside a circle with
radius 1 (I think, could be that it's a bit outside that circle...) (more or
less, it's not a perfect polygon, and it needs more than 3 angles to look like a
polygon)
cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x) // ZK http://www.povplace.be.tf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Zeger Knaepen" wrote:
> I was trying to do focalblur by averaging different renders earlier this day. I
> came up with the following formula to scatter points inside a regular polygon:
>
> #declare Seed=seed(whatever);
> #declare angles=<insert number of angles here>;
> #declare Rot=360*rand(Seed);
> #declare X=pow(rand(Seed),.5);
> #declare Rot2=Rot/(360/angles);
> #declare fraqrot=Rot2-int(Rot2);
> #declare fraqrot2=abs(fraqrot-.5);
> #declare fraqrot3=pow(fraqrot2*2,.5);
> #declare Location=vrotate(x*X*(.8+.2*fraqrot3),Rot*z);
probably right....
but please compare these lines to the simple way of determing a single point
in an rectangle concerning the time it takes to compute it ...
... and then take into account, that this has to been done multiple times
per pixel ... Maybe its ok to precompute ~2^10 such values and store them
in a table, so you can reuse them later ... but I'm not sure this will help
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > I was trying to do focalblur by averaging different renders earlier this
day. I
> > came up with the following formula to scatter points inside a regular
polygon:
> >
> > #declare Seed=seed(whatever);
> > #declare angles=<insert number of angles here>;
> > #declare Rot=360*rand(Seed);
> > #declare X=pow(rand(Seed),.5);
> > #declare Rot2=Rot/(360/angles);
> > #declare fraqrot=Rot2-int(Rot2);
> > #declare fraqrot2=abs(fraqrot-.5);
> > #declare fraqrot3=pow(fraqrot2*2,.5);
> > #declare Location=vrotate(x*X*(.8+.2*fraqrot3),Rot*z);
>
> probably right....
> but please compare these lines to the simple way of determing a single point
> in an rectangle concerning the time it takes to compute it ...
>
> ... and then take into account, that this has to been done multiple times
> per pixel ... Maybe its ok to precompute ~2^10 such values and store them
> in a table, so you can reuse them later ... but I'm not sure this will help
Yes, a rectangle, or a circle, will be faster, that's why you should have the
option to use a circle (or a rectangle, but I don't think that would give
realistic results actually).
cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x) // ZK http://www.povplace.be.tf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Zeger Knaepen" <zeg### [at] studentkuleuvenacbe> schrieb im Newsbeitrag
news:3d6bde5e@news.povray.org...
> > > I was trying to do focalblur by averaging different renders earlier this
> day. I
> > > came up with the following formula to scatter points inside a regular
> polygon:
> > >
> > > #declare Seed=seed(whatever);
> > > #declare angles=<insert number of angles here>;
> > > #declare Rot=360*rand(Seed);
> > > #declare X=pow(rand(Seed),.5);
> > > #declare Rot2=Rot/(360/angles);
> > > #declare fraqrot=Rot2-int(Rot2);
> > > #declare fraqrot2=abs(fraqrot-.5);
> > > #declare fraqrot3=pow(fraqrot2*2,.5);
> > > #declare Location=vrotate(x*X*(.8+.2*fraqrot3),Rot*z);
> >
> > probably right....
> > but please compare these lines to the simple way of determing a single
point
> > in an rectangle concerning the time it takes to compute it ...
> >
> > ... and then take into account, that this has to been done multiple times
> > per pixel ... Maybe its ok to precompute ~2^10 such values and store them
> > in a table, so you can reuse them later ... but I'm not sure this will
help
> Yes, a rectangle, or a circle, will be faster, that's why you should have
the
> option to use a circle (or a rectangle, but I don't think that would give
> realistic results actually).
>
Hi,
why not just make a circular pattern by generating the Points like before
in a rectangular area and then testing [x^2+y^2 > Radius] for the Point
to find out if it lies in the Circle. If the Condition is True, just generate
another Point until it's inside the Circle. This is a common and fast way to
get circular Points.
Greetings,
Thies
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hi,
>
> why not just make a circular pattern by generating the Points like before
> in a rectangular area and then testing [x^2+y^2 > Radius] for the Point
> to find out if it lies in the Circle. If the Condition is True, just generate
> another Point until it's inside the Circle. This is a common and fast way to
> get circular Points.
Because in real life, it aren't perfect circles, but regular polygons. So it
would be better if POV-Ray had an option to use regular polygons instead of
perfect circles. That in combination with non-clipped focal blur, would allow
us to create realistic focal-blurred images.
cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x) // ZK http://www.povplace.be.tf
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 27 Aug 2002 21:10:30 +0200, "Gilles Tran" <git### [at] wanadoofr> wrote:
> There's a patch that implements this in POV-Ray that is currently being
> ported to 3.5 (it's under testing and not available yet).
Who does it ? French community again ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Interesting. Please keep us updated.
Rene
"Gilles Tran" <git### [at] wanadoofr> wrote in message
news:3d6bcead@news.povray.org...
>
> There's a patch that implements this in POV-Ray that is currently being
> ported to 3.5 (it's under testing and not available yet). From what I
heard
> it's faster that the regular focal_blur but I have not verified this
myself.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
j8pomug7b9itfc8scj99fka5vko9gdfnf3@4ax.com...
> On Tue, 27 Aug 2002 21:10:30 +0200, "Gilles Tran" <git### [at] wanadoofr>
wrote:
> > There's a patch that implements this in POV-Ray that is currently being
> > ported to 3.5 (it's under testing and not available yet).
>
> Who does it ? French community again ?
Yes, it's the patch by Mael (it also contains finish maps, HDRI support and
a whole lot of goodies). Unfortunately he has removed it from its location
but when he has something clean to show he'll tell us.
G.
--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
