The pattern I request here is very simple, and yet something I think would
be very useful, and which I have wanted almost all from the start when I
began to use POV-ray.

The pattern is a bit like gradient and a bit like planar, but more powerful
IMHO. The syntax would be like gradient, only with another keyword of
course.

gradient2 <VECTOR>

...or something like that. gradient2 y would from y=0 to y=1 return 0 to 1.
But unlike regular gradient y it would stay at 1 at y>1 instead of
repeating. At y<0 it would return 0, and that's where it's different from
both gradient and planar. It increases in only the positive <VECTOR>
direction, not both in the positive and negative direction.

Let's take an example. I have a landscape partly under water. Around the
surface of the water I want a sand texture, everywhere above the water I
want soil and everywhere below the water surface I want an under-see
texture. Sure i could use gradient y or planar scaled *very* big and then
use only a tiny fraction of the color_map range. But it would be much more
intuitive with this gradient2 pattern.

There's lot's of other situations where you want one color/pigment/texture
from negative infinite to 0, and another color/pigment/texture from 1 to
positive infinite. The workarounds that can be done with gradient or planar
are not very good.

Another feature of the gradient2 pattern would be that the <VECTOR> could be
not only x, y or z, but any vector.

You may say that that's possible with regular gradient too, but the code
below shows that it doesn't give the expected results:

camera {location 5*y look_at z/8}
plane {y,0
   pigment {gradient x} // regular gradient x.
   // pigment {gradient 3*x} // no change ?
   // pigment {gradient <1,0,1>} // why mirrored ?
   // pigment {gradient <0.1,0,1>} // ???
   finish {ambient 1 diffuse 0}
}

Try to uncomment the different pigments one by one and you see what I mean.
I would want gradient2 to work intuitively with any vector. If
gradient2 -5*z is used the gradient really goes from 0 at z=0 to 1 at z=-5.
And if a vector like <0.1, 2, 10> is used, the gradient will indeed go in
that direction (and will not be mirrored along the axis!)

So, don't you think it would be reasonable with such a pattern? And it's not
like it would be difficult to code.

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 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Not sure whether it has everything you wanted, but how about:

#macro Gradient2 (Vector)

  #local FX=vnormalize(Vector).x; 
  #local FY=vnormalize(Vector).y; 
  #local FZ=vnormalize(Vector).z; 
  #local Len=vlength(Vector); 
      
  function {
      min(1,max(0,(x*FX + y*FY + z*FZ)/Len))
  }

#end 

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

But Runes suggestion would be easily available to many users who do not have
your mathmatical skills. Or do not frequent these newsgroups.

Not to start a war because I think Pov and its creators are wonderful. All
to often programs are written by very clever people who don't always realise
how thick the user is!  I'm an artist I trained for many years as one, my
mathamatical skills and programing skills are very limited. I do not have
much time to learn mathamatics at the level you lot work at and at 55 find
that level of thinking increasingly difficult. At the same time my artistic
skills continue to improve and grow.

All I ask is an awarness from the cleverer members of our fraternity that
there is a diversity of users with different needs, which is why I think as
many facilities as possible should be programed directly into Pov in as
simple and easy way to understand and use as possible.

After all those clever people can always amuse themselves by wrinting
patches for mathamatical dummies like me.

Mick


"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3A5868E7.11DD2F4F@gmx.de...
>
>
> Not sure whether it has everything you wanted, but how about:
>
> #macro Gradient2 (Vector)
>
>   #local FX=vnormalize(Vector).x;
>   #local FY=vnormalize(Vector).y;
>   #local FZ=vnormalize(Vector).z;
>   #local Len=vlength(Vector);
>
>   function {
>       min(1,max(0,(x*FX + y*FY + z*FZ)/Len))
>   }
>
> #end
>
> 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

"Mick Hazelgrove" <mic### [at] mhazelgrovefsnetcouk> wrote in message
news:3a587381@news.povray.org...
> But Runes suggestion would be easily available to many users who do not
have
> your mathmatical skills. Or do not frequent these newsgroups.
>
> Not to start a war because I think Pov and its creators are wonderful. All
> to often programs are written by very clever people who don't always
realise
> how thick the user is!  I'm an artist I trained for many years as one, my
> mathamatical skills and programing skills are very limited. I do not have
> much time to learn mathamatics at the level you lot work at and at 55 find
> that level of thinking increasingly difficult. At the same time my
artistic
> skills continue to improve and grow.
>
> All I ask is an awarness from the cleverer members of our fraternity that
> there is a diversity of users with different needs, which is why I think
as
> many facilities as possible should be programed directly into Pov in as
> simple and easy way to understand and use as possible.
>
> After all those clever people can always amuse themselves by wrinting
> patches for mathamatical dummies like me.
>
> Mick


     Hi, Mick. I agree, and would like to add to this too.  I am a complete
novice at this, and as such, find it difficult to even 'move' a cylinder
properly. I understand how it moves, but find that the time it takes to move
it, (and sphere's, triangles, cubes, etc.), is daunting, for me anyway.

     I've been thinking for some time now that 'if' a code could be produced
to move these basic items around, then time could be saved.

     My idea would be for someone to produce a code that 'finds' the centre
of these shapes in the render window, and then, by clicking your mouse on
the shape, and holding down, just move the shape to at least where you want
it to go, rather than taking 30 minutes to get it there in the first place.

  My understanding of computers is very limited in this field,
 so, is this feasible, at all, team?  Or am I missing something?

    ~Steve~

Post a reply to this message

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

> Not sure whether it has everything you wanted, but how about:

I was about to post something similar, but I would write it:

#macro Gradient2(Vector)
    #local Len = vlength(Vector);
    #local V = Vector/Len;
    #local FX = V.x;
    #local FY = V.y;
    #local FZ = V.z;
      
    function {
        min(1, max(0, (x*FX + y*FY + z*FZ)/Len))
        // You sure about the /Len here?
    }
#end 

Probably no actual difference in parse time, and render time would be 
the same...it just computes the length and a division fewer 
times(vnormalize() computes the length and divides the vector by that).

And axis-aligned versions would be even simpler:

#declare Gradient2X = function {min(1, max(0, x))}
#declare Gradient2Y = function {min(1, max(0, y))}
#declare Gradient2Z = function {min(1, max(0, z))}

Interesting how one fairly simple looking feature (the function pattern) 
can replace so many others...

-- 
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 <3a587381@news.povray.org>, "Mick Hazelgrove" 
<mic### [at] mhazelgrovefsnetcouk> wrote:

> But Runes suggestion would be easily available to many users who do 
> not have your mathmatical skills. Or do not frequent these 
> newsgroups.

That is the reason for many of the macro collections on the web.


> Not to start a war because I think Pov and its creators are 
> wonderful. All to often programs are written by very clever people 
> who don't always realise how thick the user is!  I'm an artist I 
> trained for many years as one, my mathamatical skills and programing 
> skills are very limited. I do not have much time to learn mathamatics 
> at the level you lot work at and at 55 find that level of thinking 
> increasingly difficult. At the same time my artistic skills continue 
> to improve and grow.

Well, you don't necessarily have to come up with this stuff to use 
it...there is even a chance of some stuff like this making it into the 
official distribution.


> All I ask is an awarness from the cleverer members of our fraternity 
> that there is a diversity of users with different needs, which is why 
> I think as many facilities as possible should be programed directly 
> into Pov in as simple and easy way to understand and use as possible.

There is a problem with this approach: the program gains more and more 
special features that could easily be done some other way, and soon it 
is impossible to learn the language and program maintenance is more 
difficult. If one feature can replace several others, I say go for that 
one feature.
For example, there is a "material_map" feature in POV that doesn't act 
like any other of the "_map" features (and doesn't have anything to do 
with materials, but they came later), it takes an image and uses it to 
map textures. There was already texture_map, which works with any 
pattern...it would have been better to add a single image_pattern or 
pigment_pattern feature which could be used with texture_map, 
pigment_map, etc...instead of adding more and more specialized features 
that only work with textures or pigments.

-- 
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 <3a5880ae@news.povray.org>, "25ct" <25c### [at] lineonenet> wrote:

>      My idea would be for someone to produce a code that 'finds' the 
> centre of these shapes in the render window, and then, by clicking 
> your mouse on the shape, and holding down, just move the shape to at 
> least where you want it to go, rather than taking 30 minutes to get 
> it there in the first place.
> 
>   My understanding of computers is very limited in this field,
>  so, is this feasible, at all, team?  Or am I missing something?

What you are looking for is a modeller. POV-Ray is a renderer.
In addition, making something like this cross-platform would be 
practically impossible...every OS handles windows and user interaction a 
bit differently. That is why the basic POV-Ray is a text-only console 
program. You might be able to cook up an interface in Java, if you want 
something that is equally bad on all platforms...
Even if you ignore that problem, how do you move an object in 3D space 
with the mouse with one view window? How would the display be updated? 
(raytracing while moving an object would, well, not give very good 
performance) And what do you mean by the "center" of the object? Center 
of mass, center of bounding box, etc...?

If you really want something like this, try one of the modellers and see 
if it improves...I personally haven't found a modeller I can use. It is 
far too platform specific to be a core POV feature, and more of a 
modeller feature than a renderer 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:
> 
> Well, you don't necessarily have to come up with this stuff to use
> it...there is even a chance of some stuff like this making it into the
> official distribution.
> 

That was exactly the idea i had, some collection of macros for different
purposes just like colors.inc and textures.inc would be quite good.  

> There is a problem with this approach: the program gains more and more
> special features that could easily be done some other way, and soon it
> is impossible to learn the language and program maintenance is more
> difficult. If one feature can replace several others, I say go for that
> one feature.

I agree.  There are dozens of special patterns that could be useful for
some purpose.  Adding everything to the program would make it much more
difficult and discouraging for the new user.

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

Chris Huff wrote:
> 
> I was about to post something similar, but I would write it:
> 
> #macro Gradient2(Vector)
>     #local Len = vlength(Vector);
>     #local V = Vector/Len;
>     #local FX = V.x;
>     #local FY = V.y;
>     #local FZ = V.z;
> 
>     function {
>         min(1, max(0, (x*FX + y*FY + z*FZ)/Len))
>         // You sure about the /Len here?
>     }
> #end
> 
> Probably no actual difference in parse time, and render time would be
> the same...it just computes the length and a division fewer
> times(vnormalize() computes the length and divides the vector by that).
> 

Sure, i did not spend time optimizing it :-)

Concerning the /Len: Rune wanted to take the length of the vector into
account.  Without it would be just like the gradient pattern.  

> 
> Interesting how one fairly simple looking feature (the function pattern)
> can replace so many others...
> 

Yes, although it's probably faster if they are hardcoded.  

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

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-FFA674.10394607012001@news.povray.org...
> In article <3a5880ae@news.povray.org>, "25ct" <25c### [at] lineonenet> wrote:
>
> >      My idea would be for someone to produce a code that 'finds' the
> > centre of these shapes in the render window, and then, by clicking
> > your mouse on the shape, and holding down, just move the shape to at
> > least where you want it to go, rather than taking 30 minutes to get
> > it there in the first place.
> >
> >   My understanding of computers is very limited in this field,
> >  so, is this feasible, at all, team?  Or am I missing something?



>
> What you are looking for is a modeller. POV-Ray is a renderer.
> In addition, making something like this cross-platform would be
> practically impossible...every OS handles windows and user interaction a
> bit differently. That is why the basic POV-Ray is a text-only console
> program.


  Thank you Chris. This is what I don't understand about it.
   I don't know what can be done or can't be done.



You might be able to cook up an interface in Java, if you want
> something that is equally bad on all platforms...


   :o)  Noooooo.  No, I'll stick with POV....


> Even if you ignore that problem, how do you move an object in 3D space
> with the mouse with one view window? How would the display be updated?
> (raytracing while moving an object would, well, not give very good
> performance) And what do you mean by the "center" of the object? Center
> of mass, center of bounding box, etc...?


    My apologies. I meant the centre of mass. I play around with 'Dimensions
3.0' now and again, and in that program you can move an object about its
centre of mass, in any direction. This is what got me thinking about being
able to move an object more efficiently in the render window 'after' the
image has been rendered - simply to adjust that object accordingly, and
then, somehow, the 'main' code would change accordingly also?


>
> If you really want something like this, try one of the modellers and see
> if it improves...I personally haven't found a modeller I can use. It is
> far too platform specific to be a core POV feature, and more of a
> modeller feature than a renderer feature.

     I guess that I will have to 'try' harder!  :o)

     It was just an idea.

    Thanks for your reply.

     ~Steve~
>
> --
> 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:
> Interesting how one fairly simple looking feature (the
> function pattern) can replace so many others...

Thanks for the function.

> If one feature can replace several others, I say go for
> that one feature.

That's my general opinion too. Only to a certain degree though.

I don't think build-in solid patterns are completely redundant just because
the function pattern can create any solid pattern. I think simple patterns
that will most probably be used very often should be built in, while
complicated specialised patterns can be made with the function pattern.

The reason I think it would be reasonable to include the gradient2 pattern
(or whatever you would call it) in POV-Ray itself is that it's so simple and
useful. IMHO that pattern is much more useful than many of the patterns that
are currently included in the official distribution of POV-Ray, and I've
needed it many more times than most of the other patterns...

We were talking about the slope pattern in p.u.p. There happened to be
another situation where I thought about the limitations of the gradient
pattern. If the gradient2 pattern were made I'd say a combination of
gradient2 <VECTOR> and a simple slope <VECTOR> would be as powerful as the
longer slope version discussed there. The only reason I "vote" for the long
slope syntax is that a flexible gradient pattern like gradient2 doesn't
exist.

In your opinion what are the criteria when deciding if a new pattern is
worthy of addition?

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 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

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

> Yes, although it's probably faster if they are hardcoded.  

Yes, but with such a simple function you probably would have to run a 
benchmark to see the difference.

-- 
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 <3a58a0ce@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> I don't think build-in solid patterns are completely redundant just 
> because the function pattern can create any solid pattern. I think 
> simple patterns that will most probably be used very often should be 
> built in, while complicated specialised patterns can be made with the 
> function pattern.

I agree...but the "gradient2" pattern seems like an over-specialized 
pattern to me.


> The reason I think it would be reasonable to include the gradient2 
> pattern (or whatever you would call it) in POV-Ray itself is that 
> it's so simple and useful. IMHO that pattern is much more useful than 
> many of the patterns that are currently included in the official 
> distribution of POV-Ray, and I've needed it many more times than most 
> of the other patterns...

I still don't quite understand why...but I've been thinking of some 
extensions to the pattern syntax that would allow the ordinary gradient 
to be used this way. Basically allowing pattern values outside the [0, 
1] range and specifying how they are clipped and scaled to fit in the 
proper range...it would be more flexible because you could specify where 
and how many bands you want instead of using yet another pattern. 
Probably an extension to the waveforms feature...


> In your opinion what are the criteria when deciding if a new pattern is
> worthy of addition?

Well, it would have to be impossible or difficult to do with existing 
features(for example, even the simplest slope pattern can't be done with 
function patterns), and it would have to be useful. The "gradient2" 
pattern is very easy to do with existing features, and I don't see it as 
being used very often, so I think it would fit much better in an include 
file. Also, as mentioned above, I've been thinking about a possible 
feature for *all* patterns that could replace it and be more flexible.

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

Mick Hazelgrove <mic### [at] mhazelgrovefsnetcouk> wrote:
: But Runes suggestion would be easily available to many users who do not have
: your mathmatical skills. Or do not frequent these newsgroups.

  Why code something in the POV-Ray source code when it's easily done with
a macro?
  Including a macro with these kind of specialized patterns in the standard
distribution of POV-Ray would be a lot better choice.

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

Post a reply to this message

"Chris Huff" wrote:
> I've been thinking of some extensions to the pattern syntax
> that would allow the ordinary gradient to be used this way.
> Basically allowing pattern values outside the [0, 1] range
> and specifying how they are clipped and scaled to fit in the
> proper range...it would be more flexible because you could
> specify where and how many bands you want instead of using
> yet another pattern. Probably an extension to the waveforms
> feature...

Sounds like a very good idea. I have some questions.
I don't know the POV source but judging from the way some patterns seem to
work I suspect that many patterns in fact does exceed the [0,1] range but
there's some global function that applies the mod function to all patterns
before they are returned. Is this assumption correct?

And you are thinking of alternatives to this global "mod enforcement"?

It sounds like a good idea. But exactly why does all patterns need to be in
the [0,1] range anyway? Why can't we allow any values in patterns? To access
those unlimited values you would simply allow all values in color_maps too
etc. I have never understood the reason for this limitation.

But back to the original topic. Say you made a "wave-type" that clipped
patterns at 0 and 1 instead of "mod"-ifying them. That solves a third of my
problem with the gradient pattern.

Another third of the problem is that only the x, y, and z vector can be used
plus combination such as <1,0,1> or <1,1,1>. Other vectors don't work. For
example <2.5,0,0> is converted to <1,0,0> and <0.1,0,3> is converted to
<1,0,1>. Fixing this odd behaviour would not break old scenes, but only add
new functionality to the gradient pattern. Could you do that too?

The last third of my problem is that the gradient pattern is mirrored in the
xy plane, the xz plane and the yz plane (abs functions?). I think it should
rather be mirrored in the plane perpendicular to the pattern vector (which
would give the same result when the vector is x, y or z). One of the
"wave-types" you are talking about could take care of that. It would (among
other things) take the abs of the function. This "wave-type" should then be
the default to preserve backward-compatibility.

What do you think of my suggestions?
Have I misunderstood what it's all about?

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 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

>   Including a macro with these kind of specialized patterns in the
standard
> distribution of POV-Ray would be a lot better choice.

Agreed. So, who is going to compile all of these patterns, and put them into
the official distribution?

Post a reply to this message

Tony[B] <ben### [at] catholicorg> wrote:
: Agreed. So, who is going to compile all of these patterns, and put them into
: the official distribution?

  I think that the pov-team and the TAG are doing the main work on this.
People are very welcome to suggest their own macros.

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

Post a reply to this message

Rune wrote:

> The pattern is a bit like gradient and a bit like planar, but more powerful
> IMHO. The syntax would be like gradient, only with another keyword of
> course.
> 
> gradient2 <VECTOR>
> 
> ...or something like that. gradient2 y would from y=0 to y=1 return 0 to 1.
> But unlike regular gradient y it would stay at 1 at y>1 instead of
> repeating. At y<0 it would return 0, and that's where it's different from
> both gradient and planar. It increases in only the positive <VECTOR>
> direction, not both in the positive and negative direction.

It has already been done... but not in the official 3.1g
Please have a look about SHEET (or BAND ?) in some unofficial version.
It is exactly what it does.

The code of the functions was posted on the server.

Post a reply to this message

In article <3A599631.FFE03888@atosorigin.com>, Jerome Grimbert 
<jer### [at] atosorigincom> wrote:

> It has already been done... but not in the official 3.1g
> Please have a look about SHEET (or BAND ?) in some unofficial version.
> It is exactly what it does.

There are two patterns..."sheet" and "banded". The "sheet" pattern uses:

  value = EPoint[X]*TPat->Vals.Gradient[X]
        + EPoint[Y]*TPat->Vals.Gradient[Y]
        + EPoint[Z]*TPat->Vals.Gradient[Z];

  return(value>1.0 ? 1.0 : (value<0.0? 0.0:value));

which looks like what he wants. The "banded" pattern is the same as 
gradient, except it doesn't mirror around the origin, and the bands are 
always the same length.

-- 
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 <3a58e89a@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> Sounds like a very good idea. I have some questions.
> I don't know the POV source but judging from the way some patterns 
> seem to work I suspect that many patterns in fact does exceed the 
> [0,1] range but there's some global function that applies the mod 
> function to all patterns before they are returned. Is this assumption 
> correct?

Yes. There is a point in Evaluate_TPat() immediately before the 
waveforms that does this, using the fmod() function:
  if (TPat->Frequency !=0.0)
  {
    value = fmod(value * TPat->Frequency + TPat->Phase, 1.00001);
  }


> And you are thinking of alternatives to this global "mod enforcement"?

Yes. Specifically, a "waveform_list {}" feature. The current ramp wave 
would simply be the default, and you could override it with whatever 
waveform you want. You could even apply multiple waveforms, one after 
the other...sort of like post_process filters for pattern waveforms.
This would require some changes to current patterns in order to be 
really useful...gradient would become a gradient from -infinity to 
+infinity, for example...but nothing should be noticeable from the 
user(except a possible speedup because of the lack of redundantly 
wrapping to the [0, 1] range).


> It sounds like a good idea. But exactly why does all patterns need to 
> be in the [0,1] range anyway? Why can't we allow any values in 
> patterns? To access those unlimited values you would simply allow all 
> values in color_maps too etc. I have never understood the reason for 
> this limitation.

It is just to make creating color_maps easier...and certain things are 
only possible when you know the maximum and minimum values of a range. 
It wasn't something they just threw in for no reason...imagine if every 
time you changed a pattern, you had to completely renumber the 
color_map...you would probably end up using a 0-1 color map and a 
separate multiplier value to fit it to each pattern.


> But back to the original topic. Say you made a "wave-type" that 
> clipped patterns at 0 and 1 instead of "mod"-ifying them. That solves 
> a third of my problem with the gradient pattern.

That is close to what I am thinking of, except I would overhaul the 
entire waveform code and allow you to specify min and max values for 
that waveform filter.


> Another third of the problem is that only the x, y, and z vector can 
> be used plus combination such as <1,0,1> or <1,1,1>. Other vectors 
> don't work. For example <2.5,0,0> is converted to <1,0,0> and 
> <0.1,0,3> is converted to <1,0,1>. Fixing this odd behaviour would 
> not break old scenes, but only add new functionality to the gradient 
> pattern. Could you do that too?

Hmm, I'd never noticed that limitation before...
It should be as simple as replacing these lines in gradient():
      temp = fabs(EPoint[i]);

      value += fmod(temp,1.0);
With this one line:
      value += fmod(fabs(TPat->Vals.Gradient[i]*EPoint[i]), 1.0);

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

"Jérôme Grimbert" wrote:
> Rune wrote:
> > gradient2 y would from y=0 to y=1 return 0 to 1. But unlike
> > regular gradient y it would stay at 1 at y>1 instead of
> > repeating. At y<0 it would return 0.
>
> It has already been done... but not in the official 3.1g
> Please have a look about SHEET (or BAND ?) in some unofficial
> version. It is exactly what it does.

Thanks for the tip!

Glad others than me could see the usefulness of such a pattern! ;)

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 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Rune <run### [at] inamecom> wrote:

> "J?r?me Grimbert" wrote:
>> Rune wrote:
>> > gradient2 y would from y=0 to y=1 return 0 to 1. But unlike
>> > regular gradient y it would stay at 1 at y>1 instead of
>> > repeating. At y<0 it would return 0.
>>
>> It has already been done... but not in the official 3.1g
>> Please have a look about SHEET (or BAND ?) in some unofficial
>> version. It is exactly what it does.

> Thanks for the tip!

> Glad others than me could see the usefulness of such a pattern! ;)

I've always wanted a pattern like that, although what I'd like is more of an
S curve.  Lots of mathematical formulae work for that, though.

Geoff

Post a reply to this message

Chris Huff wrote:

> In article <3a5880ae@news.povray.org>, "25ct" <25c### [at] lineonenet> wrote:
> >      My idea would be for someone to produce a code that 'finds' the
> > centre of these shapes in the render window, and then, by clicking
> > your mouse on the shape, and holding down, just move the shape to at
> > least where you want it to go, rather than taking 30 minutes to get
> > it there in the first place.
>
> What you are looking for is a modeller. POV-Ray is a renderer.

I've used programs like CorelDream3D, Bryce, etc., and they are a PITA as
far as this kind of operation.  My experience is that a little program that
tries to read your mind on these kinds of operations is more headache than
help.  In CD3D, you could describe the object in world or object
coordinates, move the object itself or its center of mass, and it was often
automatically converting the units back and forth without my permission,
especially in rotations.  I wouldn't stop you from trying programs like
Moray or a demo of say Rhino, but if you are trying to avoid all math you
might not be in luck. Furthermore, while I have immense respect for sPatch,
I guess I just "cannot draw with a mouse" and so I find mouse-grabbing
programs don't aid my artistic output that much. Furtherfurthermore, a
measure of my intelligence is that I never got off the ground with Moray and
wasn't ever able to really model much of anything with it.  Povlab OTOH
doesn't work.

In MegaPov, there are advanced functions like trace and min/max_extent that
I have found very helpful in figuring out exactly where a missing object is.
And if I may say so, even when modelling in povray, I've found that a little
more work and discipline up front can avoid "where is my object?" headaches
later--such as deciding up front that my blob character will have feet
bottoms at y=0 and head top at y=10.  Just firing away modelling based on
looks in current window makes for more headaches later.

Post a reply to this message

"Greg M. Johnson" <gre### [at] my-dejanewscom> wrote in message
news:3A5B091E.1F85F9FD@my-dejanews.com...

> And if I may say so, even when modelling in povray, I've found that a
little
> more work and discipline up front can avoid "where is my object?"
headaches
> later--such as deciding up front that my blob character will have feet

The white man speaks truth. My big mistake in early pov was to define, say,
a table at <10,0,15>, then define a candle-stick at <10,5,15>, then decide
that the candlestick was too small, scale it up and watch it disappear over
the horizon. Nowdays, all my objects and object components start with some
logical point at <0,0,0>.

Post a reply to this message

"Greg M. Johnson" wrote:
> Furthermore, while I have immense respect for sPatch, I guess
> I just "cannot draw with a mouse" and so I find mouse-grabbing
> programs don't aid my artistic output that much.

You're not the only one. I feel that I just can't use 3D programs with
GUI...

The positive way of thinking of it is: "Monitor and mouse works in two
dimensions only, but in my head I can visualise things in 3d"

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 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

> You're not the only one. I feel that I just can't use 3D programs with
> GUI...

I went through a Lightwave tutorial once... when I was done, I had a very
nice exploding planet and all, but I also had a headache.

> The positive way of thinking of it is: "Monitor and mouse works in two
> dimensions only, but in my head I can visualise things in 3d"

You feel like you just want to reach in there and grab the darn thing!

Post a reply to this message

"Greg M. Johnson" wrote:
> 
> I've used programs like CorelDream3D, Bryce, etc., and they are a
> PITA as far as this kind of operation.  My experience is that a
> little program that tries to read your mind on these kinds of
> operations is more headache than help.

Any program that tries to do your thinking for you is likely to be
more trouble than it's worth.  The more recent versions of MS Word
give me fits.

> Furthermore, while I have immense respect for sPatch, I guess I just
> cannot "draw with a mouse" and so I find mouse-grabbing programs
> don't aid my artistic output that much.

The chief flaw of many modellers I've seen is the tendency for all
editing to be done in planes parallel to the coordinate axes.  While
working on my modeller [1], I found that being able to interactively
rotate the view of the project makes it much easier to understand what
one is doing.

Regards,
John
--
[1] Not even half done, I'm afraid.  I had something halfway decent
put together last year, and then decided to add movable limbs and
subdivision surface support to the features.  This is not hard, but
designing an intuitive user interface is proving to be difficult...

Post a reply to this message

"Rune" <run### [at] inamecom> wrote in message
news:3a5b1acf@news.povray.org...
>
> You're not the only one. I feel that I just can't use 3D programs with
> GUI...
>

Same here - I find them useful for those aspects of a render, such as
patches and meshes, which are dauntingly complex to hand-code, but even so
it feels like sewing with gloves on.

Post a reply to this message

John VanSickle wrote:
> The chief flaw of many modellers I've seen is the tendency for all
> editing to be done in planes parallel to the coordinate axes.  While
> working on my modeller [1], I found that being able to interactively
> rotate the view of the project makes it much easier to understand what
> one is doing.
 
[Snip]
> ... This is not hard, but
> designing an intuitive user interface is proving to be difficult...

If You want to see good modeller with this respect, then I'd recommend
to try Rhino (www.rhino3d.com). It has quite intuitive and well thought
user interface: views in all viewports could be changed on fly (even
during selecting point or giving input to some complex command),
zooming, rotating, panning is easy with keys or mouse. Additional nice
feature is dynamic shading in view: one can move surface control points
and view result in other view immediately...

Post a reply to this message

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

> > The positive way of thinking of it is: "Monitor and mouse works in two
> > dimensions only, but in my head I can visualise things in 3d"
> 
> You feel like you just want to reach in there and grab the darn thing!

That is exactly how I feel...the only modeller I would be able to use 
efficiently would be one with a 3D display(goggles are clumsy, something 
like shutter-glasses or those 3D monitors), complete freedom of movement 
of the point of view, and probably using some kind of VR gloves to 
manipulate objects, with the "number typing" method available. 
Otherwise, I'm always struggling to get things positioned where I have 
them visualized.

-- 
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 <3A5### [at] erolscom>, John VanSickle 
<van### [at] erolscom> wrote:

> The chief flaw of many modellers I've seen is the tendency for all
> editing to be done in planes parallel to the coordinate axes.  While
> working on my modeller [1], I found that being able to interactively
> rotate the view of the project makes it much easier to understand what
> one is doing.

This is the approach I am thinking of using for a pseudo-modeller 
project...allowing you to freely move around the scene and position 
objects. Not using a mouse, but a sort of graphical object editor and 
OpenGL preview. The language would be CSDL...which will actually not be 
very C-like when I'm finished with it.
Don't worry about competition...it will be written in Cocoa and Obj-C, 
and will only run on Mac OS X.

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

Thanks guys.

        After reading through your posts, I feel I could have replied to you
all personally, but then I'd run out of things to say! So I'll reply to you
all collectively, </me imagines a 40 hr Borg render!>  <bg>.

      You've all actually helped out quite a bit. I'll stick with PoV, and
persevere with the math of it all, (which I know will come to me at some
point).  But what I will do is try the link Vahur gave, and try to get
'comfortable' with the number crunching in that program, (thanks Vahur). I
know it will help.

     I found Runes comments;  "The positive way of thinking of it is:
"Monitor and mouse works in two
 dimensions only, but in my head I can visualise things in 3d",
 very useful. I can only agree with this.

    I also found Chris' comments about him still having hassles with moving
things around very encouraging. I guess thats the way PoV works....  ;o)



  I'm going to take some time out now and have a play! <g>

   Speak to you all soon....

    Again, thanks.

    ~Steve~

Post a reply to this message

In article <3a5e1933@news.povray.org>, "25ct" <25c### [at] lineonenet> wrote:

>     I also found Chris' comments about him still having hassles with 
> moving things around very encouraging. I guess thats the way PoV 
> works....  ;o)

I don't want to get you discouraged again, but it seems you 
misinterpreted what I wrote...it is *modellers* that give me hassles 
with moving objects, not POV. The pseudo-modeller I was talking about 
would use a very POV-like way of specifying this kind of thing.

Hmm, one thing that may help: add three colored, thin cylinders to your 
scene, each starting at < 0, 0, 0> and going along each axis. Color-code 
them red, green, and blue for x, y, and z. This can help you keep track 
of position and orientation.

-- 
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" <chr### [at] maccom> wrote in message
news:chrishuff-9EF24C.16144211012001@news.povray.org...
> In article <3a5e1933@news.povray.org>, "25ct" <25c### [at] lineonenet> wrote:
>
> >     I also found Chris' comments about him still having hassles with
> > moving things around very encouraging. I guess thats the way PoV
> > works....  ;o)
>
> I don't want to get you discouraged again, but it seems you
> misinterpreted what I wrote...it is *modellers* that give me hassles
> with moving objects, not POV. The pseudo-modeller I was talking about
> would use a very POV-like way of specifying this kind of thing.


   My apologies Chris.....

...The 'phone rang?....My cat had kittens?...<groans> ;o)


>
> Hmm, one thing that may help: add three colored, thin cylinders to your
> scene, each starting at < 0, 0, 0> and going along each axis. Color-code
> them red, green, and blue for x, y, and z. This can help you keep track
> of position and orientation.

     Thanks,  I'll try that.

     ~Steve~


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

Mick Hazelgrove wrote:
> 
> But Runes suggestion would be easily available to many users who do not have
> your mathmatical skills. Or do not frequent these newsgroups.
> 
> Not to start a war because I think Pov and its creators are wonderful. All
> to often programs are written by very clever people who don't always realise
> how thick the user is!  I'm an artist I trained for many years as one, my
> mathamatical skills and programing skills are very limited. I do not have
> much time to learn mathamatics at the level you lot work at and at 55 find
> that level of thinking increasingly difficult. At the same time my artistic
> skills continue to improve and grow.

There are three types of people in the world. Those that are good at
 math and those that are not.

I agee with your points epecially where this feature request is
concerned. I have often wished for a different behavior for the
gradient pattern. Why go looking though a bunch of macro files
for a specific function when if can be hard wired into the program.
It would certainly be much more useful than the "rainbow" feature,
which has such limited functionality as to be almost useless, yet
remains in the feature list for v3.5.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: Why go looking though a bunch of macro files
: for a specific function when if can be hard wired into the program.

  Let me think about some reasons why a macro would be better:

  1) The larger the program, the more the bugs. If everything is hard-coded
into the program, the source code gets larger and harder to maintain.
  A bug in a macro is a lot easier to fix than a bug in the source code
(eg. an update macro pack could be released instead of releasing a whole
new version of povray).
  Besides, macros are less likely to have bugs than C source code.

  2) Hard-coding this kind of feature into the binary makes it pretty
non-flexible. When a pattern (or whatever) is hard-coded into the binary,
then you just get that pattern and that's it. If you want a bit different
pattern, you are out of luck.

  3) When the pattern is a macro, you can actually see its "source code".
You can learn from it, modify it, make your own version of it and so on,
at no extra cost (such as having to have a compiler and manage to compile
the whole thing again and again). If the pattern is hard-coded in the binary,
you have no easy way to get any advantage of it.

  4) There's no advantage between hard-coded and macros when you are looking
for a certain pattern. If both, built-in patterns and macro patterns are
documented in the same way, it really doesn't matter which way it is
implemented. You still have to search through the documentation to see if
there's any pattern you like there; it doesn't matter how the pattern is
implemented.

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
> Ken <tyl### [at] pacbellnet> wrote:
> : Why go looking though a bunch of macro files
> : for a specific function when if can be hard wired into the program.
> 
>   Let me think about some reasons why a macro would be better:
[Snip]
All valid and correct reasons. For the very same reasons I started to
implement my patch (i.e. support for RenderMan shaders). Only possible
downsize of such approact is the fact that it is slower during parsing
and rendering. But computers are now quite powerful, so flexibility of
software outweights longer run times. (This could be seen in growing
popularity of various scripting languages).

> char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
> main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
> c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Nice sig!

Post a reply to this message

Warp wrote:
> 
> Ken <tyl### [at] pacbellnet> wrote:
> : Why go looking though a bunch of macro files
> : for a specific function when if can be hard wired into the program.
> 
>   Let me think about some reasons why a macro would be better:

And this is the exact response I expected from someone with advanced
mathematical and programming skills. You just don't get it.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

On Fri, 12 Jan 2001 07:11:33 -0800, Ken wrote:
>
>
>Warp wrote:
>> 
>> Ken <tyl### [at] pacbellnet> wrote:
>> : Why go looking though a bunch of macro files
>> : for a specific function when if can be hard wired into the program.
>> 
>>   Let me think about some reasons why a macro would be better:
>
>And this is the exact response I expected from someone with advanced
>mathematical and programming skills. You just don't get it.

If the macro is provided with the release of POV you download and install,
you won't have to go looking for it (ideally) and you'll be able to use it
almost like any other keyword, modulo the slight performance hit someone
mentioned (and that we're working on fixing.)  

Just because you *can* find and change the behavior of the macro doesn't 
mean you have to.  I'm sure plenty of people here use Chris Colefax's 
macros without the slightest clue how they work, and there's no reason
why any other macro, particularly one that's included with the program, 
wouldn't be the same.  

But if you *want* to change the behavior, it's a lot easier if it's a 
macro than if it's a keyword, and far more portable to other installations 
of POV.

Something I'd love to see in the parser, though perhaps it would be too
confusing, is the ability to invoke macros using alternate syntax, so
you could have macro invocations that looked more like first-class tokens.
The idea is that you then wouldn't have to remember whether the pattern 
you want to use is implemented as a macro or a builtin, i.e. you use
"hexagon color, color, color modifiers" but you use "hextiles(mortar, 
pigment, pigment, pigment, pigment) modifiers" or you use "sphere {center,
radius modifiers}" but you use "object {TorusSpline(radius, points, start)
modifiers}".  But I'm not sure how to implement any of this cleanly at the
moment.

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

Post a reply to this message

Ron Parker wrote:

> Just because you *can* find and change the behavior of the macro doesn't
> mean you have to.  I'm sure plenty of people here use Chris Colefax's
> macros without the slightest clue how they work, and there's no reason
> why any other macro, particularly one that's included with the program,
> wouldn't be the same.

When I saw this -

#macro Gradient2 (Vector)

  #local FX=vnormalize(Vector).x; 
  #local FY=vnormalize(Vector).y; 
  #local FZ=vnormalize(Vector).z; 
  #local Len=vlength(Vector); 
      
  function {
      min(1,max(0,(x*FX + y*FY + z*FZ)/Len))
  }

#end 

I concluded I have absolutely no idea what it does, how to use it,
nor do I stand any chance of modifying it with any predictable outcome.
However I understood exactly what Rune was asking for and delighted
at the thought of something basic but very useful being added to the
program that both new and experienced users could take advantage of.

I guess we cater to the mathematical and programmer elite these days
leaving the rest of us to play with solid colored spheres and boxes.
(sorry, cheap shot)

> Something I'd love to see in the parser, though perhaps it would be too
> confusing, is the ability to invoke macros using alternate syntax, so
> you could have macro invocations that looked more like first-class tokens.

What you propose is nothing short of extraordinary. I applaud your
thinking process. Now if you would just....

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

On Fri, 12 Jan 2001 07:53:32 -0800, Ken wrote:
>When I saw this -

[snip macro]

>I concluded I have absolutely no idea what it does, how to use it,
>nor do I stand any chance of modifying it with any predictable outcome.
>However I understood exactly what Rune was asking for and delighted
>at the thought of something basic but very useful being added to the
>program that both new and experienced users could take advantage of.

The problem with that macro isn't that it's a macro.  The problem is that
it's not documented.  I'd say that even without documentation, you stand
a better chance of figuring out how it works than you would with a first-class
pattern that wasn't documented.

>What you propose is nothing short of extraordinary. I applaud your
>thinking process. Now if you would just....

I'm not sure how this was intended, so I won't reply except to ask what the
last part of the third sentence was supposed to have been.

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

Post a reply to this message

Ron Parker wrote:

> >What you propose is nothing short of extraordinary. I applaud your
> >thinking process. Now if you would just....

...make it possible.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: I concluded I have absolutely no idea what it does, how to use it,

  So if you have a builtin pattern and you only know its name, you'll
immediately know how to use it and what does it do?
  What's the difference?

-- 
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););}    /*- Warp -*/

Post a reply to this message

Ron Parker wrote:
> 
> The problem with that macro isn't that it's a macro.  The problem is that
> it's not documented.  I'd say that even without documentation, you stand
> a better chance of figuring out how it works than you would with a first-class
> pattern that wasn't documented.
> 

Since i originally wrote it, i'm probably the one to blame for that.  I
did not write it as something complete, furthermore i was quite in a hurry
at that moment.  Anyway, if you think it's useful for a macro collection,
i could describe it more detailed both for usage as well as how it works
internally.  

Concerning the rest of the discussion, i think it's quite reasonable to
expect some basic programming skills from an advanced povray user, since
povray code *is* some kind of programming language.  Furthermore most
povray users have some basic geometry knowledge.  

Anyway i don't think that means everyone should be able to understand this
macro at the first glance, but i agree with all of the arguments Warp
mentioned.  I also think that a typical povray user should be able to
teach him/herself how such a macro works using some basic math knowledge
or a math book from a local library and the povray documentation.  On the
other hand if such a function is implemented in the povray source code
it's much more difficult to understand it by looking at 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

"Ken" wrote:
> I understood exactly what Rune was asking for and delighted
> at the thought of something basic but very useful being
> added to the program that both new and experienced users
> could take advantage of.

I'm glad you think that way too. And I even consider myself one of the
programmer types...

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 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Warp, if it was up to you, would you remove all solid build-in patterns if
it wasn't for the backward-compatibility?

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 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3A5F287C.139688BB@pacbell.net>, lin### [at] povrayorg 
wrote:

> I concluded I have absolutely no idea what it does, how to use it,
> nor do I stand any chance of modifying it with any predictable outcome.

What makes you think you would have better luck if it was in C, embedded 
in the POV-Ray source code?

The user won't have to look at the macro, ever. They will just look in 
the documentation, see it in the section on "Pattern Macros", and learn 
how to use it in the same way they learn the built-in patterns. However, 
someone who wants to know how it is done simply has to open an .inc file 
and look at the appropriate macro. *They* are the ones who will see the 
macro and want to modify it, not the ordinary users. The only thing they 
will have to do is #include "patmacs.mcr" and put a macro call where 
they would otherwise put a keyword.

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

Why don't you just take the full step and remove all build-in solid patterns
from POV-Ray. Or maybe preserve them for backward-compatibility, but at
least generate a warning when used.

That would be the logical extension of the philosophy that no new patterns,
no matter how general useful and powerful they are, can be added to POV-Ray.

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 6)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Ken wrote:

> Warp wrote:
> >
> > Ken <tyl### [at] pacbellnet> wrote:
> > : Why go looking though a bunch of macro files
> > : for a specific function when if can be hard wired into the program.
> >
> >   Let me think about some reasons why a macro would be better:
>
> And this is the exact response I expected from someone with advanced
> mathematical and programming skills. You just don't get it.

I don't understand. If someone else has already programmed the pattern for
you, what's the difference if it's a macro or hard-coded? From the user's
perspective I would think it wouldn't matter, from the programmer's the
macro solution is far better. It's not like you code fonts into a word
processor.

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

Ken wrote:

> When I saw this -
>
> #macro Gradient2 (Vector)
>
>   #local FX=vnormalize(Vector).x;
>   #local FY=vnormalize(Vector).y;
>   #local FZ=vnormalize(Vector).z;
>   #local Len=vlength(Vector);
>
>   function {
>       min(1,max(0,(x*FX + y*FY + z*FZ)/Len))
>   }
>
> #end
>
> I concluded I have absolutely no idea what it does, how to use it,
> nor do I stand any chance of modifying it with any predictable outcome.

[snip]
Yeah, most people don't know how to use camera{} before reading the docs either.
The macros would come with documentation. I don't see the problem.
As for modifying it, you don't have to, but at least it's possible this way. Are
you saying if it was hard-coded you could dl the source and recompile it more
predictably than with modifying a macro?

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message