On Mon, 03 Apr 2000 22:16:21 -0400, pk wrote:
>And, i think that there's a little misunderstanding: i suggest that
>EVERYTHING except the raytracer(which is anyway interpreted by the cpu
>8)... That way, you could change the way everything behaves...
>an example:
>the textured light patch. if the light was interpreted, you could just
>use a function that tells you the distance from point 1 at angle x, y,
>z until you reach an object, and then change the color of the light at
>that angle(a micro sphere around the lightsources with a texture and
>filter at 1 would be an easy solution)

I'm not familiar with the inner workings of Povray, but I suspect that
the way light works is deep in core of the raytracer. If you implement
this in an interpreted language, you might as well implement the rest of
the raytracer in that language, too. 

	hp

-- 

|_|_) | Sysadmin WSR     \ Durchbruch in der Bionik, und Microsoft geht
| |   | hjp### [at] wsracat     \ Pleite und Gardena bringt organische PC's
__/   | http://www.hjp.at/ \ auf den Markt.           -- Stefan Schaefer

Post a reply to this message

Peter J. Holzer wrote:
> 
> On Mon, 03 Apr 2000 22:16:21 -0400, pk wrote:
> >the textured light patch. if the light was interpreted, you could just
> >use a function that tells you the distance from point 1 at angle x, y,
> >z until you reach an object, and then change the color of the light at
> >that angle(a micro sphere around the lightsources with a texture and
> >filter at 1 would be an easy solution)
> 
> I'm not familiar with the inner workings of Povray, but I suspect that
> the way light works is deep in core of the raytracer. If you implement
> this in an interpreted language, you might as well implement the rest of
> the raytracer in that language, too.
Actually, each photon isn't interpreted, but the lightsource keyword is,
in this example....
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...

Post a reply to this message

pk <thi### [at] videotronca> wrote...
> And, i think that there's a little misunderstanding: i suggest that
> EVERYTHING except the raytracer(which is anyway interpreted by the cpu
> 8)... That way, you could change the way everything behaves...
> an example:
> the textured light patch. if the light was interpreted, you could just
> use a function that tells you the distance from point 1 at angle x, y, z
> until you reach an object, and then change the color of the light at
> that angle(a micro sphere around the lightsources with a texture and
> filter at 1 would be an easy solution)

You could theoretically replace every element of a ray-tracer with
interpreted (by interpreted I/we mean software-interpreted) code.  The
question is, "would you want to?"  For example, the calculation for the
example that you gave is computed MANY times as a scene is traced.  You'd
only want to use an interpreted version if you needed to.  On the other
hand, it would be nice to provide the option to use interpreted code if the
desired feature was not implemented in the core functionality.  But you
could do this fairly easily without using XML.

-Nathan

Post a reply to this message

Nathan Kopp wrote:
> You could theoretically replace every element of a ray-tracer with
> interpreted (by interpreted I/we mean software-interpreted) code.  The
> question is, "would you want to?"  For example, the calculation for the
> example that you gave is computed MANY times as a scene is traced.  You'd
> only want to use an interpreted version if you needed to.  On the other
> hand, it would be nice to provide the option to use interpreted code if the
> desired feature was not implemented in the core functionality.  But you
> could do this fairly easily without using XML.
I never said that i was for XML Pov 8)
And, the difference between the approach you're proposing and just
interpreting next to 100% of the keywords is that you can change an
already existing keyword, but that's not a big advantage over the
additionnal speed that interpreting only what doesn't already exist
gives you...
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...

Post a reply to this message

On Thu, 6 Apr 2000 12:22:56 -0400, Nathan Kopp wrote:
>On the other hand, it would be nice to provide the option to use
>interpreted code if the desired feature was not implemented in the core
>functionality. But you could do this fairly easily without using XML.

Yep, we should have changed the subject. This doesn't have anything to
do with XML any more.

However, if povray was a library, we could link it into pike. Then it
would not only be programmable in pike, java, perl and PHP4, we would
also get XML support, could store the szenes in SQL databases, and have
the first web server with built-in raytracer, too :-)

	hp

-- 

|_|_) | Sysadmin WSR     \ Durchbruch in der Bionik, und Microsoft geht
| |   | hjp### [at] wsracat     \ Pleite und Gardena bringt organische PC's
__/   | http://www.hjp.at/ \ auf den Markt.           -- Stefan Schaefer

Post a reply to this message

Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
: However, if povray was a library, we could link it into pike. Then it
: would not only be programmable in pike, java, perl and PHP4, we would
: also get XML support, could store the szenes in SQL databases, and have
: the first web server with built-in raytracer, too :-)

  Too bad it's expressly prohibited...

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
> Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
> : However, if povray was a library, we could link it into pike. Then it
> : would not only be programmable in pike, java, perl and PHP4, we would
> : also get XML support, could store the szenes in SQL databases, and have
> : the first web server with built-in raytracer, too :-)
> 
>   Too bad it's expressly prohibited...
Well...
It's not "too bad": i really prefer pov the way it is then the way it
could have been if pov was a library ...
(though a library that's freeware ( != gpl) would be ok, i suppose)
Anyway, with OOPov-Ray(better than "A pov-ray that allows defining new
keywirds using OOP 8), someone could do a function tha translates any
kind of file into a pov file...
BTW, is pov.programming a special NG or what? bc this thread has been
going on for more thn 20 days(the longest time i've ever seen a thread
to survive 8)
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...

Post a reply to this message

> > : However, if povray was a library, we could link it into pike.
> >   Too bad it's expressly prohibited...
> Well...
> It's not "too bad": i really prefer pov the way it is then the way it
> could have been if pov was a library ...

	This doesn't make sense.  A POV API would be a different
	interface to POV script, and both would be used for
	different purposes.  A programmatic API takes nothing away
	from the POV script interface. 

> BTW, is pov.programming a special NG or what? bc this thread has been
> going on for more thn 20 days(the longest time i've ever seen a thread
> to survive 8)

	It's a thread that keeps coming back, periodically.
	Maybe one day we can tease out of the POV team, the
	exact reason for the policy. :-)

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

In article <38EE5D72.B098B031@videotron.ca> , pk <thi### [at] videotronca>  
wrote:

> BTW, is pov.programming a special NG or what? bc this thread has been
> going on for more thn 20 days(the longest time i've ever seen a thread
> to survive 8)

Messages in the POV-Ray newsgroups, except in povray.off-topic do not expire
as long as server harddisk space permits.


     Thorsten

Post a reply to this message

Nigel Stewart <nig### [at] nigelscom> wrote...
>
> It's a thread that keeps coming back, periodically.
> Maybe one day we can tease out of the POV team, the
> exact reason for the policy. :-)
>

As I understand it, the reason for the "no libraries" policy is to protect
POV-Ray from commercial exploitation.  It may be possible to protect POV
without this limitation, but that will have to be discussed further before
any major changes are made.

-Nathan

(I speak for myself, not for the POV-Team.)

Post a reply to this message