Hi Folks,

Gilles' post on p.a-u a few days ago got me thinking about variable
scale patterns. His implementation was elegant but doesn't work away
from the origin of the texture. So I decided to create one which would
be consistent anywhere.

Here is my (somewhat overengineered, I fear) attempt. The catch is that
it uses about 45 calls to crackle pigment functions for each point! It's
not quite as bad as it could be because each call is to almost the same
point, so the speed optimisations work quite well.

The two images use the same code, the difference is caused by changing
one variable's value.

I'll clean up the code a bit and if there is any interest I'll post it.

Bye for now,
	Mike Andrews.

Post a reply to this message

Attachments:
Download 'lizard2a.jpg' (59 KB) Download 'lizard2b.jpg' (59 KB)

Preview of image 'lizard2a.jpg'

Preview of image 'lizard2b.jpg'

In article <39C0B1E0.46D13BBB@reading.ac.uk>, Michael Andrews 
<M.C### [at] readingacuk> wrote:

> Hi Folks,
> 
> Gilles' post on p.a-u a few days ago got me thinking about variable
> scale patterns. His implementation was elegant but doesn't work away
> from the origin of the texture. So I decided to create one which would
> be consistent anywhere.

The displacement warp might be useful for this...my most recent version 
includes the ability to push the texture toward/away from the brightest 
parts of the control pigment. It only needs one call to the pigment 
being displaced, and 6 calls to the control pigment(to figure out the 
direction and distance to push the point.

-- 
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

Hi Chris

Chris Huff wrote:
> The displacement warp might be useful for this...my most recent version
> includes the ability to push the texture toward/away from the brightest
> parts of the control pigment. It only needs one call to the pigment
> being displaced, and 6 calls to the control pigment(to figure out the
> direction and distance to push the point.
> 

Is this in v0.3.1? The documentation for the displace warp indicates
that it takes a pattern rather than a pigment statement. 

If I implemented the method I use in software, rather than using
functions, it would only take eight calls to the crackle function.
Unfortunately, you can't save the return value of a function to use
later, you have to repeat the call and this causes a large processing
overhead.

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

Bye for now,
	Mike Andrews.

Post a reply to this message

Hell yes, post em, i have been trying to do something like this for ages
(and then gave up as a work deadline staered looming)

Rick

Post a reply to this message

In article <39C0D2CC.182F44AE@reading.ac.uk>, Michael Andrews 
<M.C### [at] readingacuk> wrote:

> Is this in v0.3.1? The documentation for the displace warp indicates
> that it takes a pattern rather than a pigment statement. 

It appears to the user to take a pattern and a color map, it really 
parses a pigment without the "pigment" keyword and the enclosing {} 
braces. It wouldn't work with only a pattern, because it uses the rgb 
vector of the *color* as the displacement amount in the type 0 version.
However, I did forget to document the new version(and I don't consider 
type 1 quite finished yet). Just use "type 0" or nothing at all after 
the color_map to get the existing kind, and "type 1" to get the 
density-controlled version.
And yes, it is in MP+ mod 0.3.1, and also in 0.3. And maybe in 0.2.5, I 
don't quite remember.


> If I implemented the method I use in software, rather than using
> functions, it would only take eight calls to the crackle function.
> Unfortunately, you can't save the return value of a function to use
> later, you have to repeat the call and this causes a large processing
> overhead.

What is the method you used?
One of the enhancements I would really like to see are in-function 
variables...they would be even higher priority than control statements 
like if(), while(), etc.(I don't count the current if() function)
It would make some functions a *lot* more efficient, since you could 
calculate, say "sqr(x)" once and use the result multiple times. Next 
after that are functions with variable numbers of parameters.
Once 3.5 is released, if it doesn't include these things, I am going to 
take a look at the source to see if I can add them.

-- 
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