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