ingo wrote:
> 
> how does the combination object_pattern + blurr_pattern compare to the
> proximity_pattern? Speedwise and for turning an object into pattern
> usable for an isosurface.
> 

That's one of the things i was going to check, but i did not yet have time
to do so.  Anyway right now there are only non adaptive blurring methods
implemented and therefore it is quite slow when using a lot of samples.  

I already started to write a recursive algorithm only taking additional
samples if the values differ, but i did not yet finish it.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3AA291F9.3E734EF6@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> That's one of the things i was going to check, but i did not yet have time
> to do so.  Anyway right now there are only non adaptive blurring methods
> implemented and therefore it is quite slow when using a lot of samples.  
> 
> I already started to write a recursive algorithm only taking additional
> samples if the values differ, but i did not yet finish it.

I had done a pattern blurring patch before, but got stuck trying to 
figure out a good way to get smooth blurring without a huge number of 
samples. I don't know how suitable it is for isosurfaces, there are 
still areas with infinite gradient. I think I can figure out a way to 
get smooth blurring, though...
My patch worked differently, it was a pattern modifier, like the 
waveform modifiers. I never thought of implementing it as another 
pattern...seems like a good idea, especially in the case of block 
patterns, which wouldn't be block patterns any more after being blurred. 
I would suggest a different keyword, though..."blur_pattern", for 
example.

One question: why do you still have the "grad" pattern, which should be 
possible with the "warp_pattern" pattern?

Also, I would suggest that "visibility" be a separate pattern...it 
doesn't seem to fit in with the object pattern, and would be better off 
not being a block pattern. Incorporating distance would be a useful 
feature.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> I had done a pattern blurring patch before, but got stuck trying to
> figure out a good way to get smooth blurring without a huge number of
> samples. I don't know how suitable it is for isosurfaces, there are
> still areas with infinite gradient. I think I can figure out a way to
> get smooth blurring, though...

That would be interesting, i can't imagine a method right now that would
do this without a lot of samples. Adaptive sampling would help a lot IMO,
esp. woth block patterns, but it's quite difficult to implement.  

> My patch worked differently, it was a pattern modifier, like the
> waveform modifiers. I never thought of implementing it as another
> pattern...seems like a good idea, especially in the case of block
> patterns, which wouldn't be block patterns any more after being blurred.
> I would suggest a different keyword, though..."blur_pattern", for
> example.

I don't like too much typing :-)

Seriously, i think the '_pattern' stuff started with pigment_pattern where
it's a good idea, like for warp_pattern too, but i'm not sure if that
should be continued with all patterns.  

> 
> One question: why do you still have the "grad" pattern, which should be
> possible with the "warp_pattern" pattern?

It was written before :-)
i will probably check if there is a difference in speed and take it out if
it's negligible.

> 
> Also, I would suggest that "visibility" be a separate pattern...it
> doesn't seem to fit in with the object pattern, and would be better off
> not being a block pattern. Incorporating distance would be a useful
> feature.
> 

There is already a seperate visibility pattern, but i did not yet include
it in the documentation, because it's quite preliminary.  

try:
pigment {
  visibility {
    object { test_Obj }
    direction z
  }
}

Right now the effect of the object pattern with visibility can not be
identically achieved with the seperate visibility pattern. 

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3AA2A38A.28F03C1C@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> That would be interesting, i can't imagine a method right now that would
> do this without a lot of samples. Adaptive sampling would help a lot IMO,
> esp. woth block patterns, but it's quite difficult to implement.  

I'll take a look at your source code, and see if I can make it use my 
method...and if my method will work. With luck, you will see some sample 
images from me soon (and a description of the algorithm, of course). :-)


> Seriously, i think the '_pattern' stuff started with pigment_pattern where
> it's a good idea, like for warp_pattern too, but i'm not sure if that
> should be continued with all patterns.

I think it makes sense in this case...actually, "blurred_pattern" seems 
even better. Just plain "blur" seems kind of ambiguous...it doesn't seem 
as apparent that the *pattern* is what is being blurred.


> There is already a seperate visibility pattern, but i did not yet include
> it in the documentation, because it's quite preliminary.  

Alright...I just downloaded the source code, and will probably integrate 
your stuff into MegaPOV+. (it will be the last thing added, though, in 
case you release a new version before I complete MP+)


> Right now the effect of the object pattern with visibility can not be
> identically achieved with the seperate visibility pattern. 

Now *that* has some potential for confusion...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> I think it makes sense in this case...actually, "blurred_pattern" seems
> even better. Just plain "blur" seems kind of ambiguous...it doesn't seem
> as apparent that the *pattern* is what is being blurred.
> 

All right, since English is not my native language i will not argue that.  

> Alright...I just downloaded the source code, and will probably integrate
> your stuff into MegaPOV+. (it will be the last thing added, though, in
> case you release a new version before I complete MP+)

Will that be based on Megapov 0.7 ?

Integrating your particle system patch I also saw that some other things
were not yet included in Megapov like the curvature pattern.  What's the
reason?

> 
> Now *that* has some potential for confusion...
> 

Yeah :-)

While the 'shadows' in the object pattern with visibility are infinitely
long, the value raises to 1 at the length of the distance vector in the
visibility pattern.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

in <3AA2B1D7.1530E613@gmx.de> Christoph Hormann wrote:

>> I think it makes sense in this case...actually, "blurred_pattern"
>> seems even better. Just plain "blur" seems kind of ambiguous...it
>> doesn't seem as apparent that the *pattern* is what is being
>> blurred. 
>> 
>
>All right, since English is not my native language i will not argue
>that. 

Should it be a pattern at all? Why not as a method of 'transformation' 
like turbulence, maybe even within a warp statement.

pigment{
    	wood
    	warp{ blurr .... }
}

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

In article <3AA2B1D7.1530E613@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> > I think it makes sense in this case...actually, "blurred_pattern" 
> > seems even better. Just plain "blur" seems kind of ambiguous...it 
> > doesn't seem as apparent that the *pattern* is what is being 
> > blurred.
> All right, since English is not my native language i will not argue that. 

I just added it to my code, and realized it takes a pigment, not a 
pattern...why is that? It kind of messes up my logic for the name...it 
should be "blurred_pigment_pattern". ;-)
I think my first modification will be to change it to use a 
pattern...that might speed it up slightly. I can't think of any benefit 
to using a pigment...


> > Alright...I just downloaded the source code, and will probably 
> > integrate your stuff into MegaPOV+. (it will be the last thing 
> > added, though, in case you release a new version before I complete 
> > MP+)
> Will that be based on Megapov 0.7 ?

Yes.


> Integrating your particle system patch I also saw that some other things
> were not yet included in Megapov like the curvature pattern.  What's the
> reason?

They aren't finished, some of them just don't work.


> > Now *that* has some potential for confusion...
> Yeah :-)
> 
> While the 'shadows' in the object pattern with visibility are infinitely
> long, the value raises to 1 at the length of the distance vector in the
> visibility pattern.

So the value tends toward 0 as the object gets nearer, and the effect of 
an object gets stronger with distance? That doesn't seem right...an 
object should have less influence with distance.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> I just added it to my code, and realized it takes a pigment, not a
> pattern...why is that? It kind of messes up my logic for the name...it
> should be "blurred_pigment_pattern". ;-)
> I think my first modification will be to change it to use a
> pattern...that might speed it up slightly. I can't think of any benefit
> to using a pigment...

It can be declared, furthermore: just laziness.

> So the value tends toward 0 as the object gets nearer, and the effect of
> an object gets stronger with distance? That doesn't seem right...an
> object should have less influence with distance.
> 

Probably better the other way round, in both patterns.  The idea in the
object pattern was shadow -> 0, but that's not that important.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

ingo wrote:
> 
> Should it be a pattern at all? Why not as a method of 'transformation'
> like turbulence, maybe even within a warp statement.
> 
> pigment{
>         wood
>         warp{ blurr .... }
> }
> 

Since it is no transformation in fact, i'm not sure if that's possible. 
Values get changed, in block patterns like checker even totally new values
occur.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <Xns### [at] povrayorg>, ing### [at] homenl (ingo) 
wrote:

> Should it be a pattern at all? Why not as a method of 'transformation' 
> like turbulence, maybe even within a warp statement.

This is how my patch worked...however, block patterns, which have a 
fixed number of flat areas, might not work as expected when the blurring 
returns "in-between" values.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message