Christopher James Huff wrote:
> 
> In article <Xns### [at] 204213191226>,
>  "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> 
> > How a litle help for fist time - can I get list of all places in code that
> > I need to modify to add new output format ? For developer of Pov it's a few
> > minute to list it, for me (and most others) - hours (days ?) of reading
> > throught entire code.
> 
> Nothing like that. If you really have experience programming and it
> takes you an hour to locate the relevant code, I'd be surprised. Just
> start with the parsing code and follow it through the program.

Didn't you at one time have a tutorial on your site with the kind of info he
is looking for?

-- 
Ken Tyler

Post a reply to this message

In article <3D81430C.B9174306@pacbell.net>, Ken <tyl### [at] pacbellnet> 
wrote:

> Didn't you at one time have a tutorial on your site with the kind of info he
> is looking for?

Close: I posted a draft of a tutorial to one of the groups on this 
server...it's probably still there. I never got very far with it though.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> 
> In article <3D81430C.B9174306@pacbell.net>, Ken <tyl### [at] pacbellnet>
> wrote:
> 
> > Didn't you at one time have a tutorial on your site with the kind of info he
> > is looking for?
> 
> Close: I posted a draft of a tutorial to one of the groups on this
> server...it's probably still there. I never got very far with it though.

So you did.

    Subject: Making POV Patches(first draft) - attached files (1/1)
       Date: Sun, 05 Dec 1999 13:11:29 -0500
       From: Chris Huff <chr### [at] yahoocom>
 Newsgroups: povray.binaries.tutorials

Glad my memory is still somewhat valid.

-- 
Ken Tyler

Post a reply to this message

Christopher James Huff wrote:
>In article <Xns### [at] 204213191226>,
> "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
>
>> > Environment mapping is a hack designed to simulate reflection for
>> Pointless discusion if You do not want to comment this 3 arguments for
>> env_map I gave, AFAIR at least 1 person agree it might be
>> usefull/interesting.
>
>There are things a lot more than 2 people are interested in.
>It might be interesting to implement as a curiousity, for the laugh
>factor of implementing environment mapping in a raytracer. I do not see
>how it could be useful.
>
>
>> by
>>   ifstream f("c:/images/test.txt);
>>   float r,g,b,id;
>>   f>>r>>g>>b>>id;
>> ?
>> Put this in x*y loop, and convert into any format, or use in game as sprite
>> with different i.e. hit regions.
>
>That's C++. This is only useful to programmers, the average user won't
>have any use for it and won't be interested, and programmers have access
>to libraries for manipulating formats already supported by POV. Or they
>could write one: a TGA reader/writer is extremely simple to implement,
>and the files could be manipulated in any good graphics program. As I
>said, you shouldn't expect tons of interest in such a special-case
>feature.
>
>Christopher James Huff <cja### [at] earthlinknet>
>http://home.earthlink.net/~cjameshuff/
>POV-Ray TAG: chr### [at] tagpovrayorg
>http://tag.povray.org/
>
If I might dare offer such an example, I'd say that
env. mapping and a floating point file format (though not one
as simple as the one envisioned by Mr. Maj: point your google to
shared exponent floating point) could help implementing HDRI in POV.
Now, don't tell me HDRI is a hack: the whole ray-tracing stuff is a hack.
Mind you, a clever one, but still a hack.
I don't have to tell you all why HDRI maps are useful, right?
And, beside that, using denormalized mantissas for color components
is very useful for postprocessing (and far better than 16-bit output).
And don't tell me that POV outputs 24 bit, not 16: I mean 16 bit per colour
channel.
Just try to adjust the tone and contrast of a POV rendering for printing
and you'll see what I mean.
Now a little mantra (quite heartfelt, at least in my case): POV-Ray is a
mindbogglingly good program, incredibly free, well-developed
and we all get the sources. Every programmer who likes CG and has
to earn his bread developing other stuff (webapps, database and, gasp,
accounting) would *love* a {e}book on POV-Ray inner workings. Heck, we
would even *buy* it, even if it's in eBook format.
I surely can grok the whole thing by myself, alone, in a week, perhaps,
coming to grasp every little nuance of the source code (yes, I have that
experience in programming), but *I* *don't* *have* *time*. I want to see the
POV-Ray community grow,
I love it, I want to see the bleeding edge of CG research in POV-Ray.
But. But, I don't have time to contribute much: so I would love to buy
a book about POV-Ray programming, to have a CVS of an experimental POV-Ray.
*sigh*. Vox clamavit in deserto.
Alex

Post a reply to this message

Alex wrote:
> 
> If I might dare offer such an example, I'd say that
> env. mapping and a floating point file format (though not one
> as simple as the one envisioned by Mr. Maj: point your google to
> shared exponent floating point) could help implementing HDRI in POV.
> Now, don't tell me HDRI is a hack: the whole ray-tracing stuff is a hack.
> Mind you, a clever one, but still a hack.
> I don't have to tell you all why HDRI maps are useful, right?
> And, beside that, using denormalized mantissas for color components
> is very useful for postprocessing (and far better than 16-bit output).
> And don't tell me that POV outputs 24 bit, not 16: I mean 16 bit per colour
> channel.

Have you actually ever tried using the 48 bit color output generated by
POV-Ray?

And HDRI has nothing to do with environment mapping.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

I guess it would be of some help if there were some rules
you could look up, like the ones you mentioned:
Where do I have to edit to add new object?
...to add new output?
...new lightsource?
etc

I've got the source downloaded and want to have
a look at it when I've got the time, but I'm not too
sure that it is really THAT complicated. Perhaps
it just has a steep learning curve, but expecting to
get detailed information on how the program
runs and why... That's asking for too much, not
just this program, any program. Sometimes its
just personal experience which makes you choose
this path or the other.
But I think we've got a newsgroup for this kind
of stuff, wasn't it povray.programming?

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

>
> To write new shape, go to line in file ... and write this code : ...,
> nowe write intersection tests in file/line... and add new token to parser
> in line ...
>
> Realy everyone who isn't involved in development of POV can easly get lost
> in it's huge code.
>
> Like in example - .txt format - with file/line is opening file, closes it,
> parses it's name (and select extension), write line (or pixel - flush
> buffer) ?
>

Post a reply to this message

On 12 Sep 2002 18:53:14 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> > >people here don't like future requests :-/ afaik
> > Sorry... ehm... what you meant?
> I have meany good ideas, I may implement them in MY demostration program 
> (C++ GCC) but I dont have time (now) to write path. And even if I do - so 
> many interesting pathes are not included in official pov. 

You are taking things wrong way, Rafal. You are thinking everybody sitting
here and waiting for new ideas to implement. That's not true. Look at my case.
I have to:
- rewrite sphere_sweep module
  http://news.povray.org/povray.unofficial.patches/27251/
- write mpeg port
  http://news.povray.org/povray.animations/26571/
- reimplement deform patch
  http://news.povray.org/povray.binaries.images/13449/
- retry clone patch
  http://news.povray.org/povray.binaries.images/14001/
- finalize my translation system for documentation
  http://news.povray.org/povray.documentation.inbuilt/26141/
- a lot of additions to iso_csg
  http://news.povray.org/search/?s=isocsg
- a lot of own SDL systems for animations and modelling
- a lot of small patches I think but have not precised
Note this all is only part of my hobby. I have to support some pages from
http://www.mdk.art.pl/ and mailing lists. Rafal, imagine, I also have wife and
two children and other family to see, house to finish, money to earn in
company, newspapers to read, movies to see etc etc. And I need to sleep, eat,
drink and piss :-)

I imagine every dedicated POVer has similiar problem. Moreover POV-Team have
to control newsgroups, websites, irtc, answer to mails, control donations and
related things like zazzle etc. etc.

So when you come here with ideas that's not that people don't like your
wishes. In case of me I can't get it to work becouse I'm busy man. But I can
quickly compare your ideas and express my opinion - it is something already
implemented as one of patches of features in 3.5, simple to hack with other
features or completly useless from view of my past experience.

You are saying you know C/C++ and you can't sit and write outputting raw
format to file during rendering ? I imagine it is about 30 min of effort. You
are spending more in this newsgroups per day. Phong ? Afaik is already
implemented. Buffering output for AA or enviroment map? It is not so easy but
not impossible. You can try if you wish. But don't expect we break our tasks
becouse you have a wish. If somebody need some feature and can simulate it
with existing features why he should spend e lot of time adding it in sources?

> What's the probelm to get now all pathes for pov, copy code, do few tests 
> and release Pov 3.6 ?

You can find at http://abx.art.pl/pov/patches/patches.php?Date=All that there
was 14 ready patch-like ideas within one month after source releases not
counting wish-like ideas like your posts. I imagine every patch to be included
in something like 3.6 have to be first:
- rediscussed in the team
- investigated for possible bugs
- investigated for compatibility with other features
- have (re)written sample files and documentation
- checked for copyrights if necessary
- copied to sources
- compiled (a few times probably)
- included in installation packages
- uploaded to server
and all this with all tasks counted at begining of this mail. But hey! Why so
big effort if it is already published and if somebody who need it can
implement it yourself?

I repeat it last time Rafal: if you have skills, ideas, and compilers, connect
it as published patch. If somebody would find it interesting he could use it.
If more than two people would use it somebody can be interested in porting it
to official package.

And all this above doesn't mean I think current development model is perfect.
But I clearly see excuse for it. I hope you see it too, do you?

ABX

Post a reply to this message

On 12 Sep 2002 20:11:17 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> Maybe just - it would be greate to have some tutorial like :

In case you missed this I'm making my patches this way.

> To write new shape, go to line in file ... and write this code : ...,
> nowe write intersection tests in file/line...

Please read planes.cpp probably simplest object in pakcage. Isn't it readable?
Of course don't miss Parse_Plane in parse.cpp.

> and add new token to parser 
> in line ...

This description is written in one of my patch descriptions
http://www.abx.art.pl/pov/patches/patches.php?Author=ABX
Have you missed this ?

> Realy everyone who isn't involved in development of POV can easly get lost 
> in it's huge code.

I'm not involved in development of POV and I know how to read it. Instead of
criticising try to learn read it. It basic skill of programmer. I'm imagine
you are programmer.

> Like in example - .txt format - with file/line is opening file, closes it, 
> parses it's name (and select extension), write line (or pixel - flush 
> buffer) ?

In simplification
- tokens are hosted in two files.
- parsing objects is one file
- every object has separated file.
- every file format has separated file.
All together not even 100 cpp files. It is one of the simples development
model I know. Comparing in small company I'm working with 900 files with 15 MB
of sources mostly not written by me. Would you imagine I can refuse my boss to
implement some feature becouse I can't read source ?

I understand povray source code is not trivial for newbie but not impossible
to read.

ABX

Post a reply to this message

>
>Have you actually ever tried using the 48 bit color output generated by
>POV-Ray?

Yes. It is perfectly fine, unless I want to generate an HDRI.

>And HDRI has nothing to do with environment mapping.

Yes it does. Go out and take a picture in the nearest park (use a pano cam),
digitalize the image, and use it as an environment for the illumination and
as an enviro map for those small reflections you want to appear on
<reflective surfaces> of that beautiful <thing> you modeled and you are
showcasing in a natural environment.

16-bit integer (or fixed-point, if you want) help a lot. Most of the time
are perfectly adequate, but you can't obtain a dynamic range as high as
with floats: granted, the larger is the range, the larger is the
quantization, but you can get away with it.
When and if POV-Ray mutates (either officially or unofficially) in a
spectral ray-tracer, precision in smaple output might become an issue...

If you aim to get a full range encoding, which accomodates most
requirements,
LogLuv encoding is even better (full range and full gamut).

Alex

Post a reply to this message

ABX wrote:

> > What's the probelm to get now all pathes for pov, copy code, do few tests
> > and release Pov 3.6 ?
> 
> You can find at http://abx.art.pl/pov/patches/patches.php?Date=All that there
> was 14 ready patch-like ideas within one month after source releases not
> counting wish-like ideas like your posts. I imagine every patch to be included
> in something like 3.6 have to be first:

As far as I know there are no plans [by the POV-Team] for a version 3.6 and no
plans to change those plans. People are going to have to put up with unofficial
patches until POV-Ray v4.0 comes out.

-- 
Ken Tyler

Post a reply to this message