"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

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

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

Speed, some patterns can't easily be done with the current function 
syntax, etc...


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

It would be, but what does that have to do with this? Nobody is 
following that philosophy...

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

Ron Parker wrote:

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

I think that's a great idea, like a parser extention.

Actually, but this is probably going way too far, all the built-in patterns
and objects could be ripped out and put in external data files, then it would
be very easy to make new additions.

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

Post a reply to this message

Rune wrote:
> 
> 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.
> 

If the POVMan patch ever makes it to official, this would actually not be such a
preposterous idea ;)
But seriously, there are innumerable patterns that, while potentially useful,
can already be done with what's available. The question is more like - where to
draw the line? I'm not going to argue about the present case, but I hope you
agree it is not practical to hard-code every possible pattern into POV source.
It's inefficient and inflexible.
A standard, documented set of pattern macros should be easy for anybody to use,
and as a bonus one has the option of modifying them to suit his needs. I for one
do not have the programming skills to modify a built-in pattern, but I do have
the POV skills to tweak a macro.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt

Post a reply to this message

Rune wrote:

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

Not as logical; backwards compatibility should try to be maintained. There has
to be some degree of permanence when these decisions are made. But that doesn't
mean it's too late to change future additions.

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

Post a reply to this message

Warp wrote:
> 
> 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?

What I am saying is I don't have to look at the code to understand
how to use a pattern. I know how to use the granite pattern with
complete confidence yet I know absolutely nothing about noise
functions. I don't need to. Additionally a hard coded pattern
can be used with ease not only in pigments but also normals,
texture maps, and pigment maps. The use of a macro complicates
this process. Can you define a normal pattern with a macro ?
I don't recall that being possible. Even if it is possible is
it as easy as it is with a built in pattern ?

-- 
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 wrote:
> 
> Additionally a hard coded pattern
> can be used with ease not only in pigments but also normals,
> texture maps, and pigment maps. The use of a macro complicates
> this process. Can you define a normal pattern with a macro ?
> I don't recall that being possible. Even if it is possible is
> it as easy as it is with a built in pattern ?
> 

If (as in the present case) the macro returns a function, you should be able to
use it anywhere a regular pattern keyword can be used. I.e. if the macro is
something like:

#macro MyPattern()
  function{...}
#end

then any of these should work:

pigment{MyPattern() color_map{...}}
normal{MyPattern() normal_map{...}}
density{MyPattern() density_map{...}}

etc. etc.
You don't need to know what the function itself looks like, you just need to
know the name of the macro, and the purpose of its parameters. Both of which
will presumably be well documented if the macro is part of an official
distribution.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Home page http://www.hot.ee/margusrt

Post a reply to this message

"Chris Huff" wrote:
> "Rune" wrote:
> > [Removing existing build-in patterns] 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.
>
> It would be, but what does that have to do with this? Nobody
> is following that philosophy...

Well, not you maybe, but others here certainly do...

Anyway, if it's just because you think my suggested pattern is not useful
enough, please tell me why the gradient pattern, with all its limitations,
is more general-purpose useful and powerful than the "band" pattern I'm
suggesting? And I could ask the same question for lots of the other
patterns.

Anyway I really hope you'll make that extension of the wave-types you were
talking about. It would mean that a single simple pattern could work as
gradient, planar, marble, my suggested pattern, and many more.
Another pattern could work as both onion and spherical.
Wood and cylindrical like patterns could also be achieved from the same
pattern. And so on...

This really would be more flexible.

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 <3A5FD39A.10B10F70@pacbell.net>, lin### [at] povrayorg 
wrote:

> What I am saying is I don't have to look at the code to understand
> how to use a pattern. I know how to use the granite pattern with
> complete confidence yet I know absolutely nothing about noise
> functions. I don't need to.

Nobody said you would have to look at the macro code! There is no more 
reason for you to open the include and look at the macros than to poke 
around in the POV-Ray source code!


> Can you define a normal pattern with a macro ? I don't recall that 
> being possible.

It is perfectly possible...function patterns work fine in normals.


> Even if it is possible is it as easy as it is with a built in pattern?

Yes. Just use the macro the same way you would in a pigment.

-- 
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 <3A5FC075.C7B98698@faricy.net>, David Fontaine 
<dav### [at] faricynet> wrote:

> I think that's a great idea, like a parser extention.

Maybe something like:
#keyword gradient2(Vect)
    // any pattern stuff...function {}, pigment_pattern, etc...
#end

This would add a new keyword with the "keyword keywordParameters" 
syntax. You would then use "gradient2 GradienVector" to use the pattern. 
Or maybe something like:
#block_macro MacroName(Parameters)
#end
This macro would be called like:
MacroName {Parameters}
instead of the usual parenthesis call.


> Actually, but this is probably going way too far, all the built-in 
> patterns and objects could be ripped out and put in external data 
> files, then it would be very easy to make new additions.

I've done something similar with a function include file that has 
functions for most of the patterns. Most of the functions are just 
pigment functions, but a few are implemented directly.

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

> Anyway, if it's just because you think my suggested pattern is not useful
> enough, please tell me why the gradient pattern, with all its limitations,
> is more general-purpose useful and powerful than the "band" pattern I'm
> suggesting? And I could ask the same question for lots of the other
> patterns.

Well, first, I think the pattern waveform syntax could be extended to 
allow gradient to do both jobs, as you mentioned below. And anyway, 
"gradient" existed long before macros or function patterns...there 
weren't any better alternatives then. And for such a simple pattern, 
there aren't any real advantages to having it built-in, and several 
disadvantages.


> Anyway I really hope you'll make that extension of the wave-types you were
> talking about. It would mean that a single simple pattern could work as
> gradient, planar, marble, my suggested pattern, and many more.
> Another pattern could work as both onion and spherical.
> Wood and cylindrical like patterns could also be achieved from the same
> pattern. And so on...
> 
> This really would be more flexible.

Which is why I prefer it to adding yet another specialized pattern.

-- 
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:
: Nobody said you would have to look at the macro code! There is no more 
: reason for you to open the include and look at the macros than to poke 
: around in the POV-Ray source code!

  This is exactly my point and exactly what I don't understand in Ken's
opinion.
  It seems like he thinks that he automatically knows how a builtin pattern
is used and what is its syntax, but he will not know the same things for
a macro.
  I just wonder how this can be possible. If someone tells me that there's
a builtin pattern called 'spiral2' in povray, I have not any idea what would
be its syntax or how it is used or how it will look like (I can guess from
the name, but will probably guess wrong in this case).
  What I make in this case is to look in the povray documentation how this
pattern is used and what does it do.
  How this differs from a standard macro goes beyond me.

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

Rune <run### [at] inamecom> wrote:
: 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.

  You are taking it to the extreme without reason.

  The point was that why implement in source code a pattern which can be
easily done with a macro, when it only would cause more problems than benefits?
A macro is just as easy to use as a builtin pattern and it has many advantages.

  However, not every pattern can be done with a macro (at least not with
the current megapov functions). For example mandel.

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

Rune <run### [at] inamecom> wrote:
: Anyway, if it's just because you think my suggested pattern is not useful
: enough

  Where did you get the idea that your suggested pattern is not useful enough?
No-one has said anything like that.
  Since when "useful things" are done in the source code and "less useful
things" with macros?

  Why do you think that Colefax's includes are not implemented in the povray
source code? Because they are not so useful?
  No, it's because there's no need to do it, and doing it would only make
more trouble than it's worth. There are more benefits for them being include
files than being part of the core renderer engine.

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

David Fontaine <dav### [at] faricynet> wrote:
: Actually, but this is probably going way too far, all the built-in patterns
: and objects could be ripped out and put in external data files, then it would
: be very easy to make new additions.

  This is not the best solution with all patterns (or whatever). Some
patterns are difficult to make with functions/scripting. Other patterns need
to be very fast in order to be usable, and making them with the scripting
language would only slow them down unnecesarily (a script version could be
done for flexibility reasons, but it shouldn't be the default).

  In my opinion, a new pattern (or whatever we are making) should be a
macro/include if:
  - It's easy to do with the povray scripting language (not necessarily
easy to code, but I mean that you don't have to make serious compromises
for example between parsing/rendering times, memory usage, etc).
  - It's fast enough to be useful; it doesn't take too long to parse and
is pretty fast to render.

  It should be made part of the source code if:
  - It's very useful and generic (making something that perhaps 0.01% of
people might use makes no sense).
  - It's not possible to make with the scripting language (for example the
photon mapping feature or many fractal patterns), or it will be extremely
difficult to do and/or it will take lots of extra memory and time while
doing it in C would be fast and efficient (eg. something requiring dynamic
lists, trees, etc), or:
  - It is a lot faster made with C than with the scripting language.

  I mentioned in a previous article reasons to favor macros/includes when
possible and practical. It makes the development of POV-Ray easier.

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

>   This is not the best solution with all patterns (or whatever). Some
> patterns are difficult to make with functions/scripting. Other patterns need
> to be very fast in order to be usable, and making them with the scripting
> language would only slow them down unnecesarily (a script version could be
> done for flexibility reasons, but it shouldn't be the default).

Is there no way to make external patterns as fast as internal ones? That would
probably require major changes to the code though (if possible).

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

Post a reply to this message

In article <3A60C792.D0AC3B43@faricy.net>, David Fontaine 
<dav### [at] faricynet> wrote:

> Is there no way to make external patterns as fast as internal ones? 
> That would probably require major changes to the code though (if 
> possible).

You would basically have to include a compiler with the program...and 
rewrite it for each platform to produce code for each processor and do 
the same optimizations that the development environments used to produce 
POV on those platforms do.
Function patterns are fairly fast now, there isn't a lot of reason to go 
through all this. There are some optimizations that could be done, 
though.

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

David Fontaine <dav### [at] faricynet> wrote:
: Is there no way to make external patterns as fast as internal ones?

  Interpreted code can never be as fast as optimized machine code. You
always get some overhead.
  The interpreted code can be sometimes almost as fast as machine code,
but there is always a little overhead. Sometimes interpreted code is a lot
slower.

  The only way of making fastest possible "plugins" is to make them in C
(or some other similar compiled language) and compile them to DLL's or
something similar and making povray to support them.
  This has been discussed several times before and it's not a very good
option in povray.
  In a one-platform software (such as Moray) it's an excellent option.

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

On Sat, 13 Jan 2001 15:24:34 -0600, David Fontaine wrote:
>Is there no way to make external patterns as fast as internal ones? That would
>probably require major changes to the code though (if possible).

Expect "major changes to the code" in version 3.5.  That's all I'm going to 
say, though, unless someone wants to make some official statement.

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

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Expect "major changes to the code" in version 3.5.  That's all I'm going to 
: say, though, unless someone wants to make some official statement.

  You shouldn't have said that. Now you left us (me included) waiting
anxiously for the surprise... :)

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

David Fontaine wrote:
> 
> 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.
> 
The main difference should be that there is (or ought to be) a help
page about the hard-coded pattern, whereas the documentation of 
macro are usually 'scarce'... (in fact, the documentation of any
include file is usually INSIDE the file itself... starting with
the povray standard include files for wood, gold, glass and so.)
Which means you have no chance to use an integrated search engine 
when you look for something : you have to know that it may exist
in an include file, open it and try to find what your looking for.

Post a reply to this message

Jérôme Grimbert <jer### [at] atosorigincom> wrote:
: The main difference should be that there is (or ought to be) a help
: page about the hard-coded pattern, whereas the documentation of 
: macro are usually 'scarce'...

  It doesn't have to be.
  If povray 3.5 includes a set of standard macros, I'm sure they will be
documented as any builtin feature.

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

Jérôme Grimbert wrote:

> > 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.
> >
> The main difference should be that there is (or ought to be) a help
> page about the hard-coded pattern, whereas the documentation of
> macro are usually 'scarce'... (in fact, the documentation of any
> include file is usually INSIDE the file itself... starting with
> the povray standard include files for wood, gold, glass and so.)
> Which means you have no chance to use an integrated search engine
> when you look for something : you have to know that it may exist
> in an include file, open it and try to find what your looking for.

You're missing the point, an 'official' macro could and would be documented
inside the povray help file just like a built-in pattern. User-created stuff
does sometimes lack good documentation, but that's not limited to macros,
'patches' can have it too.

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

Post a reply to this message

David Fontaine wrote:
> 
> Jérôme Grimbert wrote:
> 
> > > 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.
> > >
> > The main difference should be that there is (or ought to be) a help
> > page about the hard-coded pattern, whereas the documentation of
> > macro are usually 'scarce'... (in fact, the documentation of any
> > include file is usually INSIDE the file itself... starting with
> > the povray standard include files for wood, gold, glass and so.)
> > Which means you have no chance to use an integrated search engine
> > when you look for something : you have to know that it may exist
> > in an include file, open it and try to find what your looking for.
> 
> You're missing the point, an 'official' macro could and would be documented
> inside the povray help file just like a built-in pattern. User-created stuff
> does sometimes lack good documentation, but that's not limited to macros,
> 'patches' can have it too.
> 

<nitpick on>
Would you extend this documentation requirement also to the 'official'
texture definition? I would be interested to have the documentation
for the wood/glass/stones includes files (of 3.1g!).
(While you are at it, I'm also interested in the objects from
shape*.inc ... and I guess that every include file may be of
interest to at least someone, so that would make a lot of new 
pages)

<nitpick off>

<reality check>
Assuming that 3.5 is ready now (I HAVE NO CLUE ABOUT THAT, it's
only an assumption for this rhetorical question), how much delay 
would be introduced by the complete documentation of the official
include files ? 
One year or more, I guess...

Post a reply to this message

In article <3A63FDCB.16C5F746@atosorigin.com>, Jérôme Grimbert 
<jer### [at] atosorigincom> wrote:

> <nitpick on>
> Would you extend this documentation requirement also to the 'official'
> texture definition? I would be interested to have the documentation
> for the wood/glass/stones includes files (of 3.1g!).
> (While you are at it, I'm also interested in the objects from
> shape*.inc ... and I guess that every include file may be of
> interest to at least someone, so that would make a lot of new 
> pages)
> <nitpick off>

How much documentation do those require? They are just variable 
declarations. You include the file, put the variable in your code, and 
that's it...
Maybe the general use of the files should be described in the 
documentation, but the demo scene files do a better job of documenting 
them than a description of each individual texture and object would. 
("T_Green_Glass: A green glass texture. T_Dark_Green_Glass: A darker 
green glass texture. T_Blahblah_Glass: Another blahblah glass texture." 
etc, etc....)


> <reality check>
> Assuming that 3.5 is ready now (I HAVE NO CLUE ABOUT THAT, it's
> only an assumption for this rhetorical question), how much delay 
> would be introduced by the complete documentation of the official
> include files ? 
> One year or more, I guess...

If you are really pessimistic...I see no reason for writing and 
documenting the macro set to take a whole year. Even if you include 
documentation for the existing includes.

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

> > You're missing the point, an 'official' macro could and would be documented
> > inside the povray help file just like a built-in pattern. User-created stuff
> > does sometimes lack good documentation, but that's not limited to macros,
> > 'patches' can have it too.
> >
>
> <nitpick on>
> Would you extend this documentation requirement also to the 'official'
> texture definition? I would be interested to have the documentation
> for the wood/glass/stones includes files (of 3.1g!).
> (While you are at it, I'm also interested in the objects from
> shape*.inc ... and I guess that every include file may be of
> interest to at least someone, so that would make a lot of new
> pages)
>
> <nitpick off>

Please read http://www.intrepidsoftware.com/fallacy/ss.htm

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

Post a reply to this message

David Fontaine wrote:
> 
> Jérôme Grimbert wrote:
> 
> > > You're missing the point, an 'official' macro could and would be documented
> > > inside the povray help file just like a built-in pattern. User-created stuff
> > > does sometimes lack good documentation, but that's not limited to macros,
> > > 'patches' can have it too.
> > >
> >
> > <nitpick on>
> > Would you extend this documentation requirement also to the 'official'
> > texture definition? I would be interested to have the documentation
> > for the wood/glass/stones includes files (of 3.1g!).
> > (While you are at it, I'm also interested in the objects from
> > shape*.inc ... and I guess that every include file may be of
> > interest to at least someone, so that would make a lot of new
> > pages)
> >
> > <nitpick off>
> 
> Please read http://www.intrepidsoftware.com/fallacy/ss.htm
> 

Interesting, but the main problem is to delimit the scope
of the documentation for a future release (whose code
and files is only known by the Team). 
Documenting ONLY the built-in has a big advantage: there
is no last minute addition/update and the Team can focus on
the code.
Moreover, there is few built-in and the syntax is usually
decided and fixed (with optional part too).
With macro, somes may want to make generic parameter
 (such as first argument is always a vector, the second a map,...)
 even when the argument is a non-sense for a specific macro,
whereas others may want a dedicated parameter list per macro.
and so on.

And back to the speed argument, if it is easy to do with a macro,
it's ok with me, especially if the macro avoid me to type a hundred line
(and moreover, allow me to easily perform quickly update to the 
scene [because I only need to modify the macro definition and not
the hundred of call to it]).
But if the pattern is really a basic one, even if it can be done with a 
macro, it may be worth to thing about having it built-in.
That's why I did the triangular and square pattern patch: I feeled it was
unfair to have only the hexagon pattern in 2D.

Post a reply to this message

Jérôme Grimbert wrote:

> Documenting ONLY the built-in has a big advantage: there
> is no last minute addition/update and the Team can focus on
> the code.

I can understand that to some extent, but is that not up to the POV-Team to make those
changes? They could easily say official add-ons will be modified and distributed by
the same routine the same as compiles.


> Moreover, there is few built-in and the syntax is usually
> decided and fixed (with optional part too).
> With macro, somes may want to make generic parameter
>  (such as first argument is always a vector, the second a map,...)
>  even when the argument is a non-sense for a specific macro,
> whereas others may want a dedicated parameter list per macro.
> and so on.

I don't think so. With MegaPOV and upcoming 3.5 functions, the macro can serve the
same exact purpose as a function and be used practically the same as a keyword. Most
of the built-in patterns don't even take parameters, for those that do they would be
analogous to function parameters and the number would depend on the pattern itself.
The only problem I can see is optional parameters (like you said), since there is no
macro overloading.


> And back to the speed argument, if it is easy to do with a macro,
> it's ok with me, especially if the macro avoid me to type a hundred line
> (and moreover, allow me to easily perform quickly update to the
> scene [because I only need to modify the macro definition and not
> the hundred of call to it]).
> But if the pattern is really a basic one, even if it can be done with a
> macro, it may be worth to thing about having it built-in.
> That's why I did the triangular and square pattern patch: I feeled it was
> unfair to have only the hexagon pattern in 2D.

I can see your points here. Yes, there are probably times when a built-in is a good
idea.
It would be nice of course if there was access to syntax coloring options (other than
assigning colors to categories), though I realize this is not POV's purpose.

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

Post a reply to this message