The scaling of normals has been modified in megapov so that the orientation
of the normals follows the scaling (and thus simulates a "heightfied" applied
to the surface of the object).
  This is ok in most cases. However, sometimes one wants to scale the
_pattern_, not the normals. For example if I want a kind of wood pattern
but with concentric ellipses instead of circles, I could just scale the
wood pattern unevenly so that it becomes an elliptical pattern. However
this scaling affects the normals, which is not the behaviour I wanted. I
just wanted to scale the pattern, not the normals.
  A recent case that happened to me is this: I wanted a spiral pattern that
doesn't twist itself along the z axis but it's rather constant. What I did
was to scale the pattern very long in the z direction, thus getting the effect
I wanted. Although I did this in the official povray (where it didn't affect
the normals), I think that this trick wouldn't work in megapov since the
normals would be scaled too.
  I think that there should be a way to scale the pattern itself, independently
of the normals.
  Does this make any sense?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:
>   I think that there should be a way to scale the pattern itself, 
> independently of the normals.  Does this make any sense?

Sure it makes perfect senese. But isn't that what the new 
"no_bump_scale" keyword already does? I figured Nathan added
it because of the controversy over the new normal behaviour
so you could retain the ability to do a "pattern only"
transformation if you wanted.

Charles

Post a reply to this message

Charles Fusner <cfu### [at] enternet> wrote:
: Sure it makes perfect senese. But isn't that what the new 
: "no_bump_scale" keyword already does? I figured Nathan added
: it because of the controversy over the new normal behaviour
: so you could retain the ability to do a "pattern only"
: transformation if you wanted.

  1) I didn't know of the existance of such keyword.

  2) What a strange name. Wouldn't "no_normal_scale" be better and more
     descriptive?

  3) I really didn't mean this. What I meant was that there should be a
     way to scale the pattern independently of the normal. This means that
     after scaling the pattern it should be possible to scale the whole
     normal statement (which would scale both the pattern and the normal).
     I don't like the "scale pattern or normal, but not both" type of
     scaling.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha <war### [at] punarastascstutfi> wrote...
>   2) What a strange name. Wouldn't "no_normal_scale" be better and more
>      descriptive?

A good point.  How many people would get mad if I changed the syntax?

>   3) I really didn't mean this. What I meant was that there should be a
>      way to scale the pattern independently of the normal. This means that
>      after scaling the pattern it should be possible to scale the whole
>      normal statement (which would scale both the pattern and the normal).
>      I don't like the "scale pattern or normal, but not both" type of
>      scaling.

You can enclose your pattern as a pigment within a 'function' pattern.  This
way, you could do whatever you want to with the pattern before it starts
getting used as a normal.

Instead of using this:

    normal{
      crackle 0.5
      scale 10
    }

use this:

    normal{
      function{pigment{
        crackle
        color_map{[0 rgb 0][1 rgb 1]}  // might be optional
        scale 10  // scale goes here
      }} 0.5
    }

I think adding a 'pattern' pattern would be useful.  That would look like
this:

    normal{
      pattern{
        crackle
        scale 10  // scale goes here
      } 0.5
    }

Comments?

-Nathan

Post a reply to this message

> Nieminen Juha <war### [at] punarastascstutfi> wrote...
> >   3) I really didn't mean this. What I meant was that there should be a
> >      way to scale the pattern independently of the normal. This means that
> >      after scaling the pattern it should be possible to scale the whole
> >      normal statement (which would scale both the pattern and the normal).
> >      I don't like the "scale pattern or normal, but not both" type of
> >      scaling.

Ah, now I see. Yes, being able to do either as needed would be better
than one or the other.
 

And Nathan Kopp responded:
> I think adding a 'pattern' pattern would be useful.  That would look like
> this:
> 
>     normal{
>       pattern{
>         crackle
>         scale 10  // scale goes here
>       } 0.5
>     }

Well, I'll comment that I think this could be a more logical general
syntax. If "pattern" could be used anywhere a function { pigment {...} }
is now used, so it is consistant in its usage (or even if were more 
like "function { pattern { ... } }" ) Calling it a pigment function 
implies it affects the pigmentation somehow, when in fact it was
just meant to imply it uses the texture patterns, so changing 
the syntax to use "pattern" in place of "pigment" would be more
self explanatory.


Charles

Post a reply to this message

On Fri, 28 Jan 2000 09:54:45 -0500 "Nathan Kopp" <Nat### [at] Koppcom>
wrote:

>A good point.  How many people would get mad if I changed the syntax?

  Grrr! Okay, I'm over it <s>.

-- 
Alan - ako### [at] povrayorg - a k o n g <at> p o v r a y <dot> o r g
http://www.povray.org - Home of the Persistence of Vision Ray Tracer

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
: I think adding a 'pattern' pattern would be useful.  That would look like
: this:

:     normal{
:       pattern{
:         crackle
:         scale 10  // scale goes here
:       } 0.5
:     }

: Comments?

  I think it's a good idea. This would allow to define custom patterns (which
are modified from the default patterns) like this:

#declare OvalRings = pattern { wood scale <1,.5,1> }

etc...

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <38945bc8@news.povray.org>, Nieminen Juha 
<war### [at] punarastascstutfi> wrote:

>   I think it's a good idea. This would allow to define custom patterns 
>   (which
> are modified from the default patterns) like this:
> 
> #declare OvalRings = pattern { wood scale <1,.5,1> }

I agree, this would definitely be a useful feature. The current patch 
that uses "pattern" might be changed to use something like 
"pattern_image", which would be more descriptive anyway.(or maybe both 
patches could use the same keyword, but this would be confusing)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

On Sun, 30 Jan 2000 11:05:53 -0500, Chris Huff wrote:
>In article <38945bc8@news.povray.org>, Nieminen Juha 
><war### [at] punarastascstutfi> wrote:
>
>>   I think it's a good idea. This would allow to define custom patterns 
>>   (which
>> are modified from the default patterns) like this:
>> 
>> #declare OvalRings = pattern { wood scale <1,.5,1> }
>
>I agree, this would definitely be a useful feature. The current patch 
>that uses "pattern" might be changed to use something like 
>"pattern_image", which would be more descriptive anyway.(or maybe both 
>patches could use the same keyword, but this would be confusing)

Before anyone goes and does too much on this, I have a suggestion.
I would like to use a _pigment_ as a pattern, rather than just a 
pattern.  That is, I'd like to take the result of a bunch of nested
pigment_maps and warps and other pigment-cruelty and turn it into a 
pattern that can be used to produce a texture_map or a pigment_map
or whatever, so I could take my hexagonal tiles or other pigment tricks
and make something resembling list textures from them.  This, IMHO, 
would be far more useful, while subsuming the functionality you'd get 
from the pattern patch.  

I wouldn't have any problem with renaming the existing patch, but it
should probably be renamed to something using the word "pigment," 
since that's what it actually uses as input.  Just using the word
"pigment" might even be good enough, if slightly confusing.

Post a reply to this message

Sorry for spamming again this group with nothing relevant to say, but
again, I think that your idea is very good :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message