wrote:

> plane{
>   -z 0
>   translate z*3
>   pigment{Proximity_Pattern(text{ttf"povlogo""P"9 0},.1,100)}
> }
> 

It crashes when Count gets bigger than 441:
pigment{Proximity_Pattern(text{ttf"povlogo""P"9 0},.1,442)}

Win2000 A1800+ 1.5GB POV 3.5-b10 intel.


Interesting pattern though.

Ingo

Post a reply to this message

On Thu, 07 Feb 2002 19:46:29 +0100, Christoph Hormann <chr### [at] gmxde>
wrote:
> Interesing,

Thanks

> but it looks more like a blur pattern to me, the proximity
> pattern uses intersection tests IIRC.

Yes, it uses intersection tests. But this intersection test returns distance.
Pattern showed averaged distance for defined number of tests. That's exactly
what my macro does. Here is example of MEGAPOV demo:
http://users.skynet.be/smellenbergh/demopictures/proxistarb.jpg. It's little
grainy but with larger number of samples it could look exactly like blur.

Things to add to my macro to support functionality of proximity pattern

1) additional select() to perform tests only inside/outside object
2) additional calculations to perform tests in direction of bounding box

Both looks easy to add.

ABX

Post a reply to this message

> 1) additional select() to perform tests only inside/outside object
> 2) additional calculations to perform tests in direction of bounding box

Ok, I've made simple form of above.
New parameter Inside with yes/no value.
- no - leave inside of object empty
- yes - leave inside of object solid
To achive proximity pattern of both - inside and outside - it requires combination
of patterns with normal and inverted object.
Here is new version of macro:

#macro Proximity_Pattern(Object,Range,Count,Inside)
  #local P=function{pattern{object{Object}}};
  #local N=function{2*f_noise_generator(x,y,z,2)-1};
  #local Range=Range+0*x;
  #local X=abs(Range.x);
  #local Y=abs(Range.y);
  #local Z=abs(Range.z);
  #local Inside=(Inside?1:0);
  #local
B=function{pattern{object{box{min_extent(Object)-<X,Y,Z>max_extent(Object)+<X,Y,Z>}}}};
  #local C=max(int(Count)0);
  #local Proximity=function{
    (1/C)*(
    #while(C)
      P(
        x+X*N(x+C,y,z),
        y+Y*N(x,y+C,z),
        z+Z*N(x,y,z+C)
      )
      #local C=C-1;
      #if(C)+#end
    #end
    )
  };
  function{select(B(x,y,z),0,0,select(P(x,y,z),0,Proximity(x,y,z),Inside))}
#end

ABX

Post a reply to this message

In article <slr### [at] fwicom>,
 Ron Parker <ron### [at] povrayorg> wrote:

> So does this, essentially.  It effectively returns an approximation of the
> fraction of the local region of space that's occupied by the object.  For
> a sufficiently small region or a sufficiently large object, that number is
> related to the distance to the surface of the object (though part of me 
> thinks there should be a cube root involved somewhere...)

It is affected by proximity, but has no direct relation to it. The 
geometry of the surface is more important than distance...a very thin 
cylinder compared to a plane for example. And objects without insides 
will be invisible to it, since they contain no volume. It's really 
nothing like the proximity pattern, more of a blurred object pattern.

Hmm, I'm going to have to try using smooth noise instead of random 
samples in the patch...I think it would eliminate a lot of granyness.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <ng576ucr2tsiu0u9cqoqlqgcgmehvoklnb@4ax.com>,
 W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:

> Yes, it uses intersection tests. But this intersection test returns distance.
> Pattern showed averaged distance for defined number of tests.

Actually, the most commonly used mode used the minimum distance, but it 
did support the average distance.


> That's exactly what my macro does.

No, your macro returns the percentage of the surrounding space occupied 
by the object, which is quite different though it gives a similar 
effect. It is just a blurred object pattern...hmm. Your macro could be 
modified to blur almost any pattern or function...just remove the 
definition of P and pass it in as a parameter, replacing "Object".

BTW, why use "(1/C)*(...)" instead of just "(...)/C"? And 
"max(int(Count)1)" should be "max(int(Count), 1)".

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> 
>...
> BTW, why use "(1/C)*(...)" instead of just "(...)/C"? And
> "max(int(Count)1)" should be "max(int(Count), 1)".

Have you tried to do that Christopher  ?

I too wondered about that. - And then I
tried it, but then I got different
results (with beta 9).

I haven't checked with any later betas,
so I have not filed a bug report yet.


Tor Olav

Post a reply to this message

On Fri, 08 Feb 2002 20:38:22 -0500, Christopher James Huff <chr### [at] maccom>
wrote:
> > That's exactly what my macro does.
>
> No, your macro returns the percentage of the surrounding space occupied 
> by the object, which is quite different though it gives a similar 
> effect. It is just a blurred object pattern...hmm. Your macro could be 
> modified to blur almost any pattern or function...just remove the 
> definition of P and pass it in as a parameter, replacing "Object".

Yes, I know, but then speed optimization with boundary will not work.

> BTW, why use "(1/C)*(...)" instead of just "(...)/C"?

Becouse C is index for loop and after loop it has value 0.
Afaik 1/C is optimized to one float at parse time so it not the problem for
parser.

> "max(int(Count)1)" should be "max(int(Count), 1)".

It's result of shortest code contest :-)

ABX

Post a reply to this message

In article <411f6ukkqp1uplrl14b1sn582vk372o0hb@4ax.com>,
 W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:

> Yes, I know, but then speed optimization with boundary will not work.

Just use separate macros...the blur pattern functionality would be very 
useful, but having specialized macros optimized for specific patterns is 
still possible.


> > BTW, why use "(1/C)*(...)" instead of just "(...)/C"?
> Becouse C is index for loop and after loop it has value 0.

"(...)/Count" will still work. I don't think that max() call is 
necessary, but you could also just save the value of C before the loop 
in another variable.


> Afaik 1/C is optimized to one float at parse time so it not the problem for
> parser.

It just makes it less obvious that you are dividing the sum by the 
number of samples.

Hmm, something that would probably slow it down too much to be useful, 
as well as being more difficult to implement, but it would be 
interesting if it was modified to take samples in a sphere instead of a 
cube...

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3C66D808.B664D528@hotmail.com>,
 Tor Olav Kristensen <tor### [at] hotmailcom> wrote:

> Christopher James Huff wrote:
> > 
> >...
> > BTW, why use "(1/C)*(...)" instead of just "(...)/C"? And
> > "max(int(Count)1)" should be "max(int(Count), 1)".
> 
> Have you tried to do that Christopher  ?

As ABX pointed out, the value of C is modified by the loop, you would 
have to save it in another variable or drop the error testing that 
rejects values for count < 1.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> 
> In article <3C66D808.B664D528@hotmail.com>,
>  Tor Olav Kristensen <tor### [at] hotmailcom> wrote:
> 
> > Christopher James Huff wrote:
> > >
> > >...
> > > BTW, why use "(1/C)*(...)" instead of just "(...)/C"? And
> > > "max(int(Count)1)" should be "max(int(Count), 1)".
> >
> > Have you tried to do that Christopher  ?
> 
> As ABX pointed out, the value of C is modified by the loop, you would
> have to save it in another variable or drop the error testing that
> rejects values for count < 1.

Yes, of course. Sorry.
I didn't notice that it also was the counting variable.


Tor Olav

Post a reply to this message