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