I am wondering why it is not possible to declare a pattern. Patterns are
used so many placed, and they could easily be made completely consistent
with the way other things are declared and called in POV-Ray:

#declare MyPattern =
pattern {crackle sine_wave frequency 2 turbulence 0.5 translate 3*y}

#declare MyPigment = pigment {MyPattern color_map {[0,rgb 0.2][1,rgb 1]}}

I think it would be an obvious feature to add, and it would make many things
more simple.

For example you could declare a pattern once and then call this pattern in
both the pigment and the normal.

I have also tried to make pigment_maps where the color_maps for each entry
are different, but the patterns are identical. In such cases it would be
*very* convenient to be able to declare patterns.

Currently if you want to add turbulence or similar to a pattern without it
affecting child patterns you must either use reset_children (which will not
be in 3.5) or use the pattern in a pigment, add turbulence to this pigment,
and then convert the pigment back to a pattern again using pigment_pattern.
It seems to me like an awkward way of doing it. The two conversions could be
avoided if my pattern suggestion was implemented. It would then simply work
like this:

pigment {
   pattern {spotted turbulence 0.8}
   pigment_map {...}
}

In MegaPov there's a pigment function feature which converts a pigment to a
function. However, functions return floats, not vectors, so it really would
be more logic if it took a pattern as input. I suspect that the only reason
it takes a pigment as input is that patterns - for some reason - can't
currently be declared.

So, there a lots of reasons to make it possible to declare patterns.
Is there any specific reason that patterns can't be declared?
It would be *so* useful!

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a9fd51c@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> In MegaPov there's a pigment function feature which converts a 
> pigment to a function. However, functions return floats, not vectors, 
> so it really would be more logic if it took a pattern as input. I 
> suspect that the only reason it takes a pigment as input is that 
> patterns - for some reason - can't currently be declared.

That isn't the reason...before the spline_wave patch, the advantage of 
pigments was that you could modify the pattern with a different 
color_map. Now that is irrelevant, though, since you can use a 
spline_wave as a float_map.


> So, there a lots of reasons to make it possible to declare patterns.
> Is there any specific reason that patterns can't be declared?

Not really...I've often thought that the syntax you describe would be 
better. And this issue has been discussed before...another area that 
would benefit is normals: MegaPOV now transforms the "bumps" along with 
the pattern, which is often desired but sometimes not what you wanted, a 
pattern{} block could be used to specify pattern-specific transforms.
I've recently figured out how to declare things, so I'll probably make 
an attempt at this feature, it shouldn't be too difficult. The only 
problem is that the "pattern" keyword is already used, but it's current 
use is pretty unintuitive. (The "pattern" image type, which creates an 
image from a pigment..."pigment_image" would be a better choice, in my 
opinion. I don't think changing it would cause a lot of trouble...)

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

On Fri, 02 Mar 2001 15:49:24 -0500, Chris Huff wrote:
>I've recently figured out how to declare things, so I'll probably make 
>an attempt at this feature, it shouldn't be too difficult. The only 

Be careful.  There are some gotchas with identifiers that I just found 
whilst gallivanting through the code.

>problem is that the "pattern" keyword is already used, but it's current 

This doesn't preclude your reusing it in a different context.

>use is pretty unintuitive. (The "pattern" image type, which creates an 
>image from a pigment..."pigment_image" would be a better choice, in my 
>opinion. I don't think changing it would cause a lot of trouble...)

Originally it was to have taken a pattern as argument.  I don't remember
now why it wasn't written to do so, but I suspect it had something to do
with transforms and other warps not being usable at that level, or with
things like pigment_map and average that aren't strictly patterns.  Maybe
I should keep a diary of these things.

Better might be to just get rid of it altogether, since there are now 
lots of better ways of doing most of what it can do.  Not likely to
happen now, though, for hysterical raisins.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Can you declare a "pigment_pattern"? I haven't tried that myself. By the
way, I don't like "pigment_pattern". I feel the keyword is wrong. It should
just be "pattern" because it can be used in textures, and normals. (I rarely
use materials, so I don't know if it works there too.)

Post a reply to this message

On Fri, 2 Mar 2001 16:13:51 -0600, Tony[B] wrote:
>Can you declare a "pigment_pattern"? I haven't tried that myself. By the
>way, I don't like "pigment_pattern". I feel the keyword is wrong. It should
>just be "pattern" because it can be used in textures, and normals. (I rarely
>use materials, so I don't know if it works there too.)

it's a pigment_pattern because it's a pattern made from a pigment, not because
it's used in pigments.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

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

> Be careful.  There are some gotchas with identifiers that I just found 
> whilst gallivanting through the code.

Anything in particular? I've been following the code for the spline {} 
patch, and my interpolated transformations seem to be declaring fine...I 
haven't tested them with macros or arrays, though. And I've noticed that 
my #set patch doesn't work for arrays.


> >problem is that the "pattern" keyword is already used, but it's current 
> This doesn't preclude your reusing it in a different context.

I know, it just bothers me that the same keyword, with a very specific 
meaning, is used for widely different things. And the "pattern" keyword 
just doesn't seem to fit in this case.


> Originally it was to have taken a pattern as argument.  I don't remember
> now why it wasn't written to do so, but I suspect it had something to do
> with transforms and other warps not being usable at that level, or with
> things like pigment_map and average that aren't strictly patterns.  Maybe
> I should keep a diary of these things.

Well, pigments have colors...but I don't recall if this "image" type can 
be used outside height fields (and I can't think of any reason you 
*would* use it directly...). With pigments, you can drastically modify 
the shape of the surface by using different color_maps, and while you 
can do the same now with ordinary patterns using the spline_wave patch, 
it wasn't around then. Similar to the reason pigments are useable as 
isosurface functions, but patterns aren't.
Well, there is also the fact that patterns can't be declared... ;-)


> Better might be to just get rid of it altogether, since there are now 
> lots of better ways of doing most of what it can do. 

There are? The only way I can think of would be to write a macro that 
uses eval_pigment() to create a mesh...and that's only for height fields.


> Not likely to happen now, though, for hysterical raisins.

If it *is* modified or removed, it should be now, before there are 
enough "hysterical raisins". I doubt there is anyone who has used it who 
wasn't aware that it is an experimental feature of an unofficial version.

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

In article <3aa00ee0@news.povray.org>, "Tony[B]" <ben### [at] catholicorg> 
wrote:

> Can you declare a "pigment_pattern"? I haven't tried that myself.

I highly doubt that it works differently from the other patterns.


> By the way, I don't like "pigment_pattern". I feel the keyword is 
> wrong. It should just be "pattern" because it can be used in 
> textures, and normals. (I rarely use materials, so I don't know if it 
> works there too.)

It's called "pigment_pattern" because it takes a pigment and turns it 
into a pattern. Makes perfect sense to me..."pattern" wouldn't, though. 
(What kind of pattern? What's this pigment doing here?)

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

On Fri, 02 Mar 2001 16:51:41 -0500, Chris Huff wrote:
>In article <slr### [at] fwicom>, ron### [at] povrayorg 
>wrote:
>
>> Be careful.  There are some gotchas with identifiers that I just found 
>> whilst gallivanting through the code.
>
>Anything in particular? I've been following the code for the spline {} 
>patch, and my interpolated transformations seem to be declaring fine...I 
>haven't tested them with macros or arrays, though. And I've noticed that 
>my #set patch doesn't work for arrays.

Macros is the biggie.  Identifiers as arguments to macros are passed by
reference, and the code to do that is... interesting.

>> Originally it was to have taken a pattern as argument.  I don't remember
>> now why it wasn't written to do so, but I suspect it had something to do
>> with transforms and other warps not being usable at that level, or with
>> things like pigment_map and average that aren't strictly patterns.  Maybe
>> I should keep a diary of these things.
>
>Well, pigments have colors...but I don't recall if this "image" type can 
>be used outside height fields (and I can't think of any reason you 
>*would* use it directly...). 

Ah, that one I can answer (one would hope so, since I wrote the patch.)  It 
can be used outside height fields, and such a thing was used to create the 
images you'll find at

http://www2.fwi.com/~parkerr/hfstones.jpg
http://www2.fwi.com/~parkerr/hfstone2.jpg

because I hadn't told MCB that we needed a planar warp yet. :)

>it wasn't around then. Similar to the reason pigments are useable as 
>isosurface functions, but patterns aren't.
>[...]
>There are? The only way I can think of would be to write a macro that 
>uses eval_pigment() to create a mesh...and that's only for height fields.

You answered your own question, there, sorta.

>> Not likely to happen now, though, for hysterical raisins.
>
>If it *is* modified or removed, it should be now, before there are 
>enough "hysterical raisins". I doubt there is anyone who has used it who 
>wasn't aware that it is an experimental feature of an unofficial version.

Ah, what I meant was a different sort of hysterical raisins.  I can't really
elaborate here; ask me in a different place.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <chrishuff-C6F2EA.15492402032001@news.povray.org> , Chris 
Huff <chr### [at] maccom>  wrote:

> I've recently figured out how to declare things, so I'll probably make
> an attempt at this feature, it shouldn't be too difficult.

Be aware, you end up fixing half of POV-Ray texture code along with it.
The problem is that textures and pigments are close to the same thing in
the internal representation.  Once you start fixing the Parse_Pattern
you will end up fixing the data structures for textures, media (take a
look at the "next" pointer in _patterns_).  I have code going fairly far
(based on the current source code) but as said, you end up fixing so
many things (if you want to implement it well the first time) that you
would end up having to test every texture, media, pigment, normal and
pattern feature in combinations to make sure you didn't break anything.

Possible, but do you really want to do so if it is all going to be
trashed in case of a rewrite?  The texture code side effects are really
one of the biggest messes you can find in the current code base :-(


       Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3aa0280c$1@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Possible, but do you really want to do so if it is all going to be
> trashed in case of a rewrite?  The texture code side effects are really
> one of the biggest messes you can find in the current code base :-(

I think it could be done without too much trouble or code, just parse 
the pattern into a variable and implement a case in Parse_Pattern to 
handle pattern identifiers that would just copy the needed data. I don't 
see anything in the code that will prevent this being tacked on...but if 
this is going to be in 3.5, or even if the relevant code will be cleaned 
up, there isn't much of a reason to mess with it now. Especially when 
the only version it would ever be included in is MegaPOVPlus, wouldn't 
be used by anyone, and there are workarounds in the current version...

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

In article <chrishuff-5CABFF.20002302032001@news.povray.org> , Chris 
Huff <chr### [at] maccom>  wrote:

> I think it could be done without too much trouble or code, just parse
> the pattern into a variable and implement a case in Parse_Pattern to
> handle pattern identifiers that would just copy the needed data. I don't
> see anything in the code that will prevent this being tacked on...but if
> this is going to be in 3.5, or even if the relevant code will be cleaned
> up, there isn't much of a reason to mess with it now.

Well, the problem is the way POV-Ray currently creates "classes" and
"objects".  You inherit properties by placing all contents in a big
define and then the appear everywhere and explicit casting is used to
access the fields.  Now, because when writing the code you can check
which pattern is valid in which context, you can of course cast a
pattern structure back to a texture, media or a pigment.  But what
happens if it is just a plain pattern?  Bad luck, you just accessed
unallocated memory!

As I said, one can go ahead and clean all this up and as said I have a
fairly far amount of work done on that (if you want, I can e-mail it to
you), but once all the nice cleanup is done, you still have to test it
because the changes you have to make to implement this in a clean way
are massive, reaching from lighting.cpp to media.cpp.  The real problem
is the testing because you have to clean up the media, pigment and
texture parsing code at the same time - just take a look into
Parse_Pattern...

The good thing about this is that all the ugly casting goes away.  You
even gain some memory by moving data to its appropriate place.  However,
more remains to be done:  The complex question of what constitutes a
"pattern" and what a "pigment".  As you know, for some patterns like
checker you declare two colors along with the patterns while for others
you have to use a color map (referred to as Blend_Map inside the source
code).  Unfortunately, access to it is not unambiguous inside the source
code.  I was a bit surprised about this myself when seeing it the first
time, but in essence the whole pattern structure contains fields that
are misused all over the place For example the "next" pointer is
actually used by media only, and has nothing to do with patterns.  I
have that cleaned up already, but then it just gets worse because this
is what actually brings the media code into the game.

Oh, and of course the patterns that aren't really patterns (like the
"average" pattern, see the docs) had to be fixed.  Take a look at the
function pattern parse code in the current code base and you will know
what I mean.  It works around the problem by simply copying a subset of
the pattern parsing code and for all practical purposes creates a
pattern only object.

Don't get me wrong:  I do not say it is an impossible task, not even a
hard task, but it is an awful lot of work in a lot of parts of the code
if it isn't just supposed to be a quick hack (like so many things we had
to fix in MegaPOV code already).

And it is simply too easy to make some mistake, and such a mistake may
cause crashes only in a strange combination of texture, pigment, media
and normal.  It would be a testing nightmare.  So the premise is to
"never change a running system", especially if it is as essential as
this one!  Nevertheless, for 4.0 this will all be fixed properly
anyway...


    Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

This is approximately (because it isn't complete or perfect) how it 
should look like.  Compare it with the current code and take a guess how
much work it is...

struct Pattern_Struct
{
 unsigned short Type, Wave_Type, Flags;
 int References;
 SNGL Frequency, Phase;
 SNGL Exponent;
 WARP *Warps;
 union
 {
  DENSITY_FILE *Density_File;
  IMAGE *Pattern_Image;
  VECTOR Gradient;
  SNGL Agate_Turb_Scale;
  short Num_of_Waves;
  short Iterations;
  short Arms;
  struct
  {
   SNGL Mortar;
   VECTOR Size;
  } Brick;
  struct
  {
   SNGL Control0, Control1;
  } Quilted;
  struct
  {
   DBL Size, UseCoords;
   VECTOR Metric;
  } Facets;
  struct
  {
   VECTOR Form;
   VECTOR Metric;
   DBL Offset;
   DBL Dim;
   short IsSolid;
   VECTOR *cv;
   long lastseed;
   VECTOR lastcenter;
  }  Crackle;
  struct
  {
   VECTOR Slope_Vector, Altit_Vector;
   short Slope_Base, Altit_Base;
   SNGL Slope_Len, Altit_Len;
   UV_VECT Slope_Mod, Altit_Mod;
  } Slope;
  struct
  {
   unsigned short Fn;
   void *Data;
  } Function;
  PIGMENT *Pattern_Pigment;
 } Vals;
};

enum PIGMENT_TYPE
{
 NO_PIGMENT = 0,
 COLOR_PIGMENT,        // uses Colour
 AVERAGE_PIGMENT,      // uses Average_Map
 UV_PIGMENT,           // uses Blend_Map and Pigment
 IMAGE_PIGMENT,        // uses Image
 PATTERN_PIGMENT       // uses Blend_Map and TPat
};      

struct Pigment_Struct
{
 PIGMENT_TYPE Pigment_Type;
 union
 {
  COLOUR Colour;
  BLEND_MAP *Average_Map;
  struct
  {
   BLEND_MAP *Blend_Map;
   union
   {
    PIGMENT *Pigment;
    TPATTERN *TPat;
   };
  };
  IMAGE *Image;
 };
};

enum NORMAL_TYPE
{
 NO_NORMAL = 0,
 IMAGE_NORMAL,         // uses Image
 PATTERN_NORMAL        // uses TPat
};

struct Tnormal_Struct
{
 NORMAL_TYPE Normal_Type;
 SNGL Amount;
 SNGL Delta;
 union
 {
  IMAGE *Image;
  TPATTERN *TPat;
 };
};

struct Texture_Struct
{
 TEXTURE *Next;
 TEXTURE *Next_Material;
 PIGMENT *Pigment;
 TNORMAL *Tnormal;
 FINISH *Finish;
 TEXTURE *Materials;
 int Num_Of_Mats;
};

struct Finish_Struct
{
 SNGL Diffuse, Brilliance;
 SNGL Specular, Roughness;
 SNGL Phong, Phong_Size;
 SNGL Irid, Irid_Film_Thickness, Irid_Turb;
 SNGL Temp_Caustics, Temp_IOR, Temp_Dispersion,
      Temp_Refract, Reflect_Exp;
 SNGL Crand, Metallic;
 RGB Ambient, Reflection_Max, Reflection_Min;
 SNGL Reflection_Falloff;
 int Reflection_Type;
 SNGL Reflect_Metallic;
 int Conserve_Energy;
};


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> it's a pigment_pattern because it's a pattern made from a pigment, not
because
> it's used in pigments.

Then the name feels out of order... it should be pattern_from_pigment, or
something. :) I don't know... I just don't like it... If the rest of you
feel comfy-fine with it, then OK, I'll put up with it...

Post a reply to this message

> I highly doubt that it works differently from the other patterns.

Is that a "no"?

> It's called "pigment_pattern" because it takes a pigment and turns it
> into a pattern. Makes perfect sense to me..."pattern" wouldn't, though.
> (What kind of pattern? What's this pigment doing here?)

It doesn't make sense to me... Especially when used in a "normal {}"
statement. "pattern" makes sense, since, well, it is a pattern. The pigment
would be there, being patternized... Hey! Maybe the keyword should be
"patternize"... OK, I'll shut up now.

Post a reply to this message

> Better might be to just get rid of it altogether, since there are now
> lots of better ways of doing most of what it can do.  Not likely to
> happen now, though, for hysterical raisins.

Yep, POV is getting old and needs to be 4.0'd soon.

Post a reply to this message

"Tony[B]" wrote:
> > it's a pigment_pattern because it's a pattern made from a
> > pigment, not because it's used in pigments.
>
> Then the name feels out of order... it should be
> pattern_from_pigment, or something. :) I don't know...
> I just don't like it... If the rest of you feel comfy-fine
> with it, then OK, I'll put up with it...

It's common for words to work like that. The last part describes what the
object is, and the first part describes what is special about it. Here's
some examples:

A mailbox is a box. It contains mails.

A race horse is a horse. It participates in races.

A horse race is a race. It is a race for horses.

Similary, a pigment_pattern is a pattern. The special thing about this
pattern is that it is made from a pigment.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org

Post a reply to this message

> Similary, a pigment_pattern is a pattern. The special thing about this
> pattern is that it is made from a pigment.

<sigh> Your fish is coming along nicely, BTW.

Post a reply to this message

"Tony[B]" wrote:
> Your fish is coming along nicely, BTW.

Ooh! Sounds good! :D

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org

Post a reply to this message