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