On 17 Mar 2000 08:55:14 -0500, ron### [at] povrayorg (Ron Parker)
wrote:

>Besides, I don't think you've thought through the consequences of what you're
>asking for here.  Essentially, you're saying you want to take this nice little
>sharing, giving community we have here and balkanize it into language-based
>camps.

Ahem!

:)


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

Post a reply to this message

On Fri, 17 Mar 2000 23:46:50 +0200, Peter Popov wrote:
>On 17 Mar 2000 08:55:14 -0500, ron### [at] povrayorg (Ron Parker)
>wrote:
>
>>Besides, I don't think you've thought through the consequences of what you're
>>asking for here.  Essentially, you're saying you want to take this nice little
>>sharing, giving community we have here and balkanize it into language-based
>>camps.
>
>Ahem!

I knew I'd get you to bite on that one. :)

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

On 17 Mar 2000 17:01:26 -0500, ron### [at] povrayorg (Ron Parker)
wrote:

>>>Besides, I don't think you've thought through the consequences of what you're
>>>asking for here.  Essentially, you're saying you want to take this nice little
>>>sharing, giving community we have here and balkanize it into language-based
>>>camps.
>>
>>Ahem!
>
>I knew I'd get you to bite on that one. :)

It's just that you spelt balkanise wrong. :)


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

Post a reply to this message

> Essentially, you're saying you want to take this nice little
> sharing, giving community we have here and balkanize it into language-based
> camps.

You talk about the "support nightmare", but I can see the
complexity of POV-script increasing with each release,
which in turn will result in similar problems. I'd rather
see a focus on rendering technology than parsing technology.

<wish>
Set POV free, and let us use it as an API
</wish>

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

Post a reply to this message

PoD wrote:
> 
> Nigel Stewart wrote:
> >
> >         Yes it should.  Enforced portability is very limiting.
> >         I'm talking about the portability of POV scenes,
> 
> HUH ?!?!?!?!?!?! WTF????
> You want to be able to make non portable scene files???
> What are you smoking?

Probably some kind of 
 union {
 cone {...}
 cylinder {... interior {media...}}
 finish {recognizable_smell...}
}

Fabien.

Post a reply to this message

In article <38D2BBBE.107BB51B@nigels.com>, nig### [at] eisanetau wrote:

> You talk about the "support nightmare", but I can see the
> complexity of POV-script increasing with each release,
> which in turn will result in similar problems.

Multiple languages for each platform would be very difficult to support. 
Adding to and expanding the language will be much easier to support. I 
don't see why you want this...people will no longer be able to ask "how 
do I do this", they will have to choose a language too, and people using 
other languages wouldn't be able to help them. There would have to be at 
least one expert for each language. And if they are platform dependant, 
that makes the problem much larger.(the same scene file that renders on 
Windows POV-Ray should run the same on POV-Ray Mac or Linux POV. There 
should be no differences, other than version numbers)
I don't see any benefit in platform dependant things like this, and a 
lot of problems...


> I'd rather see a focus on rendering technology than parsing 
> technology.

I don't see the POV Team trying to come up with new kinds of parsers for 
each release...their focus is definitely not on parsing technology.


> <wish>
> Set POV free, and let us use it as an API
> </wish>

Who is this "us" you speak of?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Nigel Stewart <nig### [at] nigelscom> wrote in message
news:38D2BBBE.107BB51B@nigels.com...

> <wish>
> Set POV free, and let us use it as an API
> </wish>

Exactly that is what the POV-Team is trying to prevent, IMO, and for the
reasons they give in POVLEGAL. I can understand that.

--
Rudy Velthuis

Post a reply to this message

Chris Huff wrote:

> > I'd rather see a focus on rendering technology than parsing
> > technology.
 
> ...their focus is definitely not on parsing technology.

Well there is to the extent that they try to add enhancements and
optimizations to the current parser whenever they can.

-- 
Ken Tyler -  1300+ 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

> Multiple languages for each platform would be very difficult to support.

All you have to support is an API.

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

Post a reply to this message

Nigel Stewart wrote in message <38D5606D.FEF25671@nigels.com>...
>
>> Multiple languages for each platform would be very difficult to support.
>
>All you have to support is an API.
>
>--



If want you want is a graceful mechanism for supporting extensions to the
scene language, I wouldn't look much further than XML
and namespace support.

Thus, extensions to the pov scene language can be handled with namespaces.
Those authors who are interested in making scenes run on a platform which
does not support that extension should markup more carefully than those who
don't.  As long as the reference "compile" of POV gracefully handled these
extensions, what reason would someone have to object?

e.g.
<sphere class="SnookerBall">
    <megapov0_9:phat_photon>...
    </megapov0_9:phat_photo>
</sphere>

Help me out here:
Pros:
o) POV sources (like MORAY, my perl scripts, etc. as opposed to sinks, like
the raytracer itself) can markup 3D scenes with minimum fuss
o) New POV editors could exploit XML Schemas
o) The concepts of "style" are equally applicable to pov source files as
they are to XHTML
o) Source format becomes "future proof"
o) Future developers will understand XML processors in the same way that
current developers understand "i++" in C.
o) Existing, proven, technology
o) Easy way to both add new tags and incorporate third-party developer's
experiments and fun stuff
o) ...?

Cons:
o) legacy .pov files.  (see below)
o) Complexity for non-programmer user... (less of an issue for me: I think
POVML would be easier to markup than the current POV scene language, but
that's a pretty emotional statement)
o) All the newsgroup space and arguments that go into choosing what the
actual elements should be (eg. verbose like above, or concise, like SVG,e.g.
<pov:sphere transform="t[ranslate] 125*z r[otate] 0 1 0 60 s[cale] 10"...>)
[again, less of an issue, because,like most people on this list,  I love
constructive discussion)
o) Potential for "tower of babel" diversity among extensions.
o) I haven't thought about what impact this would have on the reference
implementation codebase
o) ...?

Issues:
o) I recommend staying away from DTDs if you want to use namespaces.
o) I suggest that all existing scene graph language files be supported, and
that a future version of POV has a builtin (commandline?) function to
transform from .povml  to .pov and viceversa.
o) Is there an "ANSI C"-ified  interface to XML parsing?  Code reuse would
be a good thing...
o) I'd also probably argue (hmmm, I obviously feel really feel strongly

might not scale well.  A persistant DOM engine would solve that problem, but
I don't think there is a stable code base for that sort of thing at the
moment.
o) ...?

Let's look ahead to version 5, 6, 7 of POV.  These issues should only have
to be dealt with once.


Nick Drew
hyp### [at] btinternetcom

"I'm not giving in to mob rule, I'm merely jumping on a bandwagon..."

Post a reply to this message