Hello,

I'm a system programmer and a technical writer. Usually I write about
programming for Windows, but some times ago (~ 1,5 year) I found POV-Ray
and I'm very impressed by this REALLY GREAT program. So now I'm thinking
about possible book. A book about POV-Ray. It seems to me, that POV-Ray
is almost unknown in Russia.
Now I'm thinking, what kind should this book be. Only a tutorial for
beginners? Seems, it's very boring for possible readers and for me. I'm
not an advanced user, so I can't write a book for advanced users. But!
It will be possible to write a book for those, who want to FEEL POV-Ray.
I couldn't understand many features of POV-Ray, because I'm not
photographer and I couldn't imagine them. I begin to learn POV-Ray with
it's source. This is a most preferable way for me. After that I began TO
FEEL something in POV_Ray. So, I can explain to readers many features of
POV-Ray from a point of view of programmer. For example, I explain
camera as a structure (it's written in camera.h), then I explain a
creation of defaul camera (parse.c and camera.c), where the default
values of parameters were set, why it's possible to use not all
modifiers in "camera" operator and so on. Seems, this book can be
interesting for many people. What do you think?
Of course, I'm not sure, that this book will be written, but why not? We
can write this book together and publish it in the same time. All
opinions will be appreciated.
Thank you.

Pavel Rumyantsev

Post a reply to this message

Pavel,

a question similar to yours (but it was a request and not an offer :)
) has been brought up in these groups. It concerned the exsistance of
a POV-Ray source code guide or manual. I think it was Chris Cason
(POV-Ray Team Coordinator) who summed up, "if you find one, let us
know :)."

All patch writers have to do it the hard way (is there an easy one?).
Fortunately, the source is well written and generally well documented,
but some things can only be found through trial and error. A guide to
the internal structure of POV would be of great use.

It is quite a hard task but in no case one without purpose. You
mention that you initially learned POV by its source. I know a lot of
programmers, and some good one, I dare say, but this is amazing! I
mean, the source is several megabytes big! Anyway, to me this
indicates that a) you are a Good Programmer™ and b) you know the
internals of POV quite well.

Chris Huff started writing a tutorial on writing patches, you might
want to look into it. It's the last post in povray.binaries.tutorials
. Other users frequenting this server have good programming skills,
too, but whether they would be willing to donate time and brain cells
to this project I may not and can not tell.

This project is likely to take a lot of time and hard work. Be aware
that POV-Ray 4.0 (the major version after the next one) will be
completely rewritten in C++. This may effectively render all the work
and time invested useless.

I can not help you much aside from giving a friendly and supportive
pat on the shoulder, which I am taking the opportunity to do now :) I
can only say that if this project yields real results, they will be
invaluable and of great use to patch writers and why not the Team
themselves?

One last note. This post reflects my own opinions. I do not speak for
the POV-Team (which I can not do anyway) nor for the TAG.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

I have often thought that there needs to be a book about using POV and that
also covers some of the source code, as well as some ray tracing basics. It
begs to be published by O'Reilly! If someone could demonstrate the
determination and ability, someone with a proven track record of success,
maybe the POV team would be willing to work closely with the author in order
to facilitate the release of such a book fairly close to the release of
v4.0. In any case, the help file is a great starting point, some times I
could really use a hardcopy of that.

I don't think it would be a terribly lucrative deal, but it certainly is an
opportunity waiting for an author. Visit O'Reilly's web site, they have an
email address where you can make recommendations for book ideas. They are
very willing to work with new authors with good ideas.

Jon

Post a reply to this message

Jon Berndt wrote:

>I have often thought that there needs to be a book about using POV and that
>also covers some of the source code, as well as some ray tracing basics. It
>begs to be published by O'Reilly! .....

Almost a year ago Twyst proposed something simmilar, read the thread:
From: "Twyst"
Subject: [Idea] User Documentation Project
Date: Wed, 23 Dec 1998 15:35:34 -0700
Message-ID: <3681705a.0@news.povray.org>

I still like the idea.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

Maybe a solution would be a community wide expansion of the current manual.
If one person was established as the project coordinator through whom all
contributions were forwarded for final editing and ensuring a standard
format.
Possibly we are looking at 3 volumes, much as the current manual, a. A
Basic Tutorial; b. A Technical Reference; and c. Specialty Functions and
Add-ons.
The 'current' version of the book could always be available in pdf or other
formats for those who treasure the printed page. Most 'quick print' shops
now charge very little to run a pdf to paper.

ingo <ing### [at] homenl> wrote in message
news:8E9996E21seed7@204.213.191.228...
> Jon Berndt wrote:
>
> >I have often thought that there needs to be a book about using POV and
that
> >also covers some of the source code, as well as some ray tracing basics.
It
> >begs to be published by O'Reilly! .....
>
> Almost a year ago Twyst proposed something simmilar, read the thread:
> From: "Twyst"
> Subject: [Idea] User Documentation Project
> Date: Wed, 23 Dec 1998 15:35:34 -0700
> Message-ID: <3681705a.0@news.povray.org>
>
> I still like the idea.
>
> Ingo
>
> --
> Photography: http://members.home.nl/ingoogni/
> Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

David Vincent-Jones wrote:

>Maybe a solution would be a community wide expansion of the current manual.
>If one person was established as the project coordinator through whom all
>contributions were forwarded for final editing and ensuring a standard
>format.

That poor person would go crazy within a month. The first week everybody 
sends his tutorial and personal wishes to him. Two weeks later everybody 
starts asking when the book will be ready and why their tutorial is not 
incorporated.
To do someting like that you'll need an editorial team, something like the 
POV-team or the IMP-team. A teamleader/spokesman and 3 - 5 (skilled) editors.

>Possibly we are looking at 3 volumes, much as the current manual, a. A
>Basic Tutorial; b. A Technical Reference; and c. Specialty Functions and
>Add-ons.

This is one of the important things to do for a Doc-team. Set up a structure 
for the book, what chapters, what levels etc. Once this (and more) is done 
they can go search the right autors for each part (chapter / paragraph ..). 
They have to give the autors quite detailed info on what is expected on a 
certain item.
One the article is written the team can edit it into the desired form. 
Illustrations and demo-scenes have to be made.
Then the next group of people come to action. The translators (German, 
French, Spanish, Japanese, Chinese, Russian, ...). The English language is 
not as common as manny people seem to think. I know of several Dutch who 
never really got to using POV because they simply don't understand the 
manual.

>The 'current' version of the book could always be available in pdf or other
>formats for those who treasure the printed page. Most 'quick print' shops
>now charge very little to run a pdf to paper.

This is a matter of using the right tools (SGML/XML?)to make the basic 
document. From there convert to anything you want.
Make shure the document is easy extendible. Adding a chapter for a patch 
should be a matter of writing the text with the right template and updating 
the index.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

I for one wouldn't even want to begin such a monumental task as this kind of
thing being talked about.  Take for instance the descrepency between the
Windows platform of POV-Ray Insert menu, which shows a 'blob' to be:

// create a smooth blobby shape
#declare StrengthVal = 1.0 // (+ or -) strength of component's radiating
density
#declare RadiusVal   = 1.0 // (0 < RadiusVal) outer sphere of influence on
other components
blob
{
  // threshold (0.0 < threshold <= StrengthVal) surface falloff threshold #
  threshold 0.6
  sphere { < 0.75,   0,    0>, StrengthVal, RadiusVal }
  sphere { <-0.375,  0.65, 0>, StrengthVal, RadiusVal }
  sphere { <-0.375, -0.65, 0>, StrengthVal, RadiusVal }
  cylinder { -z, +z, 0.1, StrengthVal, RadiusVal }
  // [sturm]
  scale 2
}

And the Scene Help shows it as:

BLOB:

blob { BLOB_ITEM... [BLOB_MODIFIERS...]}

BLOB_ITEM:

sphere{<Center>, Radius, [ strength ] Strength [COMPONENT_MODIFIER...] } |
cylinder{<End1>, <End2>, Radius, [ strength ] Strength
[COMPONENT_MODIFIER...] } |
component Strength, Radius, <Center> |
threshold Amount

COMPONENT_MODIFIER:

TEXTURE | PIGMENT | NORMAL | FINISH | TRANSFORMATION

BLOB_MODIFIER:

hierarchy [Boolean] |
sturm [Boolean] |
OBJECT_MODIFIER

 Notice the strength and radius reversal (and why hasn't that been corrected
yet? :^D
  It would be a daunting task to get a book made on POV-Ray whether it be
about the source or the program scripting and expect it to be 100% correct.
I know I'm just a pessimist, so aside from this I'm behind anyone all the
way on the project.


Bob (not blob)

"ingo" <ing### [at] homenl> wrote in message
news:8E99C38E2seed7@204.213.191.228...
> David Vincent-Jones wrote:
>
> >Maybe a solution would be a community wide expansion of the current
manual.
> >If one person was established as the project coordinator through whom all
> >contributions were forwarded for final editing and ensuring a standard
> >format.
>
> That poor person would go crazy within a month. The first week everybody
> sends his tutorial and personal wishes to him. Two weeks later everybody
> starts asking when the book will be ready and why their tutorial is not
> incorporated.
> To do someting like that you'll need an editorial team, something like the
> POV-team or the IMP-team. A teamleader/spokesman and 3 - 5 (skilled)
editors.
>
> >Possibly we are looking at 3 volumes, much as the current manual, a. A
> >Basic Tutorial; b. A Technical Reference; and c. Specialty Functions and
> >Add-ons.
>
> This is one of the important things to do for a Doc-team. Set up a
structure
> for the book, what chapters, what levels etc. Once this (and more) is done
> they can go search the right autors for each part (chapter / paragraph
..).
> They have to give the autors quite detailed info on what is expected on a
> certain item.
> One the article is written the team can edit it into the desired form.
> Illustrations and demo-scenes have to be made.
> Then the next group of people come to action. The translators (German,
> French, Spanish, Japanese, Chinese, Russian, ...). The English language is
> not as common as manny people seem to think. I know of several Dutch who
> never really got to using POV because they simply don't understand the
> manual.
>
> >The 'current' version of the book could always be available in pdf or
other
> >formats for those who treasure the printed page. Most 'quick print' shops
> >now charge very little to run a pdf to paper.
>
> This is a matter of using the right tools (SGML/XML?)to make the basic
> document. From there convert to anything you want.
> Make shure the document is easy extendible. Adding a chapter for a patch
> should be a matter of writing the text with the right template and
updating
> the index.
>
> Ingo
>
> --
> Photography: http://members.home.nl/ingoogni/
> Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

BLOB Hughes wrote:
 
> I for one wouldn't even want to begin such a monumental task as this kind of
> thing being talked about.
<snip>
>   It would be a daunting task to get a book made on POV-Ray whether it be
> about the source or the program scripting and expect it to be 100% correct.
> I know I'm just a pessimist, so aside from this I'm behind anyone all the
> way on the project.

 You can count me out too. I have enough headaches without a project like
this one.

-- 
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

ingo wrote:

> This is one of the important things to do for a Doc-team. Set up a structure
> for the book, what chapters, what levels etc. Once this (and more) is done
> they can go search the right autors for each part (chapter / paragraph ..).
> They have to give the autors quite detailed info on what is expected on a
> certain item.

I'm agree with Ingo. DOC_TEAM! It's a great idea! Why not? Seems, many people
need this kind of tutorial.
If it's need, I can translate a little chapter about camera and send it to this
conference. It can be an example of MY OWN (only my own) vision of possible book.

Pavel Rumyantsev

Post a reply to this message