Some people say that the POV Ray SDL is a turn off for new users, others say
that modeling programs are a turn off to scripters There seems to be a real
scism here. There are issues with Moray's right handed polor coordinates,
and some thing sPartch or Hamapatch are a better choce (tho I have not heard
why they are). When I was speaking of putting Moray text in a gray box I did
not mean that text would reproduce the user docs in Moray. I don't see my
book idea as competing with either Moray or POV Ray docs, that would be a
waste of trees. I want to improve the tutorials, not compete with them. I
think that the tutorials in the POV Ray and Moray docs are very uneven, some
are great, some are okay, and some are poor.

I know very little about this other products: blender, spatch, hamapatch,
anim8tor, amapi, rhino. I have tried blender but it would not run properly
on my Win2K machine with dual LCD monitors. Are these all freeware programs,
because the one disconnect with Moray is that its retail product and that
does not work very well with the free nature of POV. What about including
some of these products in the gray text, would that be a turn off?

I wonder about the statment "it's impossible to really unleash povray's
power without learning the scene description language"? How is that true?
"And some of the coolest povray stuff is not implemented in these modelers
yet." Well there is SO MUCH stuff in POV Ray that is implemented in these
modelers that I am not sure a book needs to cover everything in POV Ray,
that seems like a daunting and almost impossible requirement.

"Furthermore the structure of a book about Moray would should be quite
different from one about Povray." I don't see how this follows. Why would
they have to have different structures? Seems like "here is how to do
something in POV" could easily be parallel with "here is how its done in
Moray", or whatever modeler you are using.

I very much appreciate the feelback, its helping me calibrate my ideas for
the team that is forming. Nothing has been decided so this is a great time
for people to jump in and help shape this project.

Post a reply to this message

On Sat, 19 Jan 2002 22:48:31 -0800, "Mitchell Waite"
<mit### [at] dnaicom> wrote:

>I know very little about this other products: blender, spatch, hamapatch,
>anim8tor, amapi, rhino. I have tried blender but it would not run properly
>on my Win2K machine with dual LCD monitors. Are these all freeware programs,
>because the one disconnect with Moray is that its retail product and that
>does not work very well with the free nature of POV. What about including
>some of these products in the gray text, would that be a turn off?

Blender is free but it's virtually unusable without the docs, and that
has to be paid for. Rhino is certainly not free, the student's license
was $199 last time I checked. I think anim8or is not free either but I
may be wrong here.

>I wonder about the statment "it's impossible to really unleash povray's
>power without learning the scene description language"? How is that true?

The POV-Ray scene description language is a Turing-complete language.
You can write anything with it, from a virus to a raytracer (both of
these have been done.) Of course these are extremes, but things like
particle systems for modelling smoke and fire, l-systems and other
recursive systems for modelling plants, and other similar tasks are
definitely not and are *really* useful. Many such tasks rely on close
integration with the scene and can not be currently accomplished in
any other means.

>"And some of the coolest povray stuff is not implemented in these modelers
>yet." Well there is SO MUCH stuff in POV Ray that is implemented in these
>modelers that I am not sure a book needs to cover everything in POV Ray,
>that seems like a daunting and almost impossible requirement.

I think the book should concentrate on the pros and cons of a modeller
and not on specific feature sets. Pros: this and that done easily.
Cons: this and that can't be done.

>"Furthermore the structure of a book about Moray would should be quite
>different from one about Povray." I don't see how this follows. Why would
>they have to have different structures? Seems like "here is how to do
>something in POV" could easily be parallel with "here is how its done in
>Moray", or whatever modeler you are using.

The approach is different. Most hand-coders start with a *very* clear
idea of what they want to achieve, because once you've nested a
million CSGs and you don't like something, going back is somewhat
hard. With a visual scene creation tool such as Moray, you can touch
up and tune things one the fly. There's much more to it, of course,
such that with POV you have to at least STTFM (Skim Through The Fine
Manual) and a Moray 'hello world' lesson can start right away... but
I'll leave that to real Moray users (I've only tried it once, in the
POV 2.2 times).

>I very much appreciate the feelback, its helping me calibrate my ideas for
>the team that is forming. Nothing has been decided so this is a great time
>for people to jump in and help shape this project.

Hope my ramblings were of some help. Good luck!


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Mitchell Waite wrote:
> 
> [...]
> I want to improve the tutorials, not compete with them. I
> think that the tutorials in the POV Ray and Moray docs are very uneven, some
> are great, some are okay, and some are poor.

Could you give an example?  Of course the tutorials in the POV-Ray docs
have their limitations.  There is not room for a lot of illustartions and
they have to be quite technical, but i would not call any of them 'poor'.

> I wonder about the statment "it's impossible to really unleash povray's
> power without learning the scene description language"? How is that true?
> "And some of the coolest povray stuff is not implemented in these modelers
> yet." Well there is SO MUCH stuff in POV Ray that is implemented in these
> modelers that I am not sure a book needs to cover everything in POV Ray,
> that seems like a daunting and almost impossible requirement.

I think Gilles' suggestion to get some more experience in the practical
use of POV-Ray is very good.  Tell me if i'm wrong, but your above
statement seems to indicate that you are missing some of the most powerful
features of POV-Ray.  A book about current POV-Ray without while loops,
macros, 'trace' etc. would be really incomplete i think.

> "Furthermore the structure of a book about Moray would should be quite
> different from one about Povray." I don't see how this follows. Why would
> they have to have different structures? Seems like "here is how to do
> something in POV" could easily be parallel with "here is how its done in
> Moray", or whatever modeler you are using.

Things like the mentioned functions have no equivalent in a modeler like
moray, apart from that the introducing part would have to be totally
different.  With moray you would give an introduction to the user
interface, the basic functions and how to use the wireframe editor in
general.  With POV-Ray you would probably start with some explanation of
the language, the basic syntax elements etc.

My own favorite concept for such a book would be a collection of
independent chapters.  I always liked such books because they give a good
impression of the diversity of possible ways to work and do not force a
certain learning path.  Also it would simplify coordinating multiple
authors.  I personally would also like writing something for such a book
while i would not have that much interest in doing a chapter of a book
like you proposed - with moray i would even not be competent for doing so.

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

"Peter Popov" <pet### [at] vipbg> wrote in message
news:a07l4u4rsbi0cf4m8q8df8hgi2td22jlne@4ax.com...
> On Sat, 19 Jan 2002 22:48:31 -0800, "Mitchell Waite"
> <mit### [at] dnaicom> wrote:
>
> Blender is free but it's virtually unusable without the docs, and that
> has to be paid for. Rhino is certainly not free, the student's license
> was $199 last time I checked. I think anim8or is not free either but I
> may be wrong here.

Rhino: Educational - $195 Commercial - $895 but there's a full feature
save limited demo available (25 saves iirc) (www.rhino3d.com/download.htm)
As far as I can tell from the anim8or web site it it free, at least at the
moment.

Gail
--
#macro G(H,S)disc{0z.4pigment{onion color_map{[0rgb<sin(H/pi)cos(S/pi)*(H<6)
cos(S/pi)*(H>6)>*18][.4rgb 0]}}translate<H-5S-3,9>}#end G(3,5)G(2,5.5)G(1,5)
G(.6,4)G(.5,3)G(.6,2)G(1,1)G(2,.5)G(3,.7)G(3.2,1.6)G(3.1,2.5)G(2.2,2.5)G(9,5
)G(8,5.5)G(7,5)G(7,4)G(7.7,3.3)G(8.3,2.7)G(9,2)G(9,1)G(8,.5)G(7,1)//GS

Post a reply to this message

Peter Popov wrote:
> 
> The POV-Ray scene description language is a Turing-complete language.
> You can write anything with it, from a virus to a raytracer (both of
> these have been done.)

Oh, PLEASE tell me that one or both of these are available on the web
somewhere or in someone's personal archive.  I am a huge fan of Just Plain
Wrong coding (I wrote a CGI script or two in make(1), and actually used,
albeit not for long, ddcalc), and these sound brilliant.

Please, someone, give me a pointer to these projects.

Deaken

Post a reply to this message

In article <3C4AD7F1.47D921B5@sw-tech.com>, Deaken <dwy### [at] sw-techcom> 
wrote:

> Oh, PLEASE tell me that one or both of these are available on the web
> somewhere or in someone's personal archive.  I am a huge fan of Just Plain
> Wrong coding (I wrote a CGI script or two in make(1), and actually used,
> albeit not for long, ddcalc), and these sound brilliant.

The raytracer is part of the POV 3.5 documentation:
http://www.povray.org/working-docs/

I don't think the "virus" is available, and it wouldn't work with the 
security features in POV 3.5 anyway.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

Christopher James Huff wrote:

> I don't think the "virus" is available, and it wouldn't work with the
> security features in POV 3.5 anyway.

It would work if the security features were disabled.

-- 
Ken Tyler

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
:> I don't think the "virus" is available, and it wouldn't work with the
:> security features in POV 3.5 anyway.

: It would work if the security features were disabled.

  The problem with that "virus" is that it has no way to get a file listing,
ie. no way to know how files are named in the current directory.
  You can imagine how slow it is to go through all possible file names in
povray sdl... (it's extremely slow even with a highly-optimized C code).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Christopher James Huff wrote:
> 
> The raytracer is part of the POV 3.5 documentation:
> http://www.povray.org/working-docs/

Oh.  I thought you meant a raytracer actually written IN SDL, or perhaps
something that would parse what you had written and rewrite it before
sending it to the rendering engine.

> I don't think the "virus" is available, and it wouldn't work with the
> security features in POV 3.5 anyway.

It seems to be simple enough, in theory.  I just didn't want to reinvent yet
another wheel.

No, I'm not going to write it.  There are better things to do with the
interpreter.

Deaken

Post a reply to this message

Deaken <dwy### [at] sw-techcom> wrote:
: Oh.  I thought you meant a raytracer actually written IN SDL

  It is.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message