 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Which BTW is quite hard to maintain, and can't be incorporated
> > into a commercial tool because of the POV license.
>I've had a quick look through the source, and
> it doesn't really look that hard to maintain
If you don't think so, why don't you go and fix
the bug reported on povray.general under
"Re: POV-file that crashes POV-Ray". It's a
nice tangled one, from what I can see.
> After all, any file format is inherently proprietary
To different extents. One advantage with XML
is that a parser can read any XML file, not
just a particular variant.
> So I'm not sure what the difference here would be. I'm can't see how the
> POV licensing agreement would prohibit you from creating all the POV
> tools you wanted?
The POV license is much more restrictive than GPL or
the BSD license.
> since the people who use
> modeller's couldn't care less what language POV really used.
I think if the modellers suddenly had the choice of
taking their data from Rhino to Autocad to POVray and
then back to Rhino, without any conversion process,
they might regard it as a nice feature.
I think it's weird to claim that users of modelling
packages don't care what format their data is in.
> So why not make a commercial library to parse POV? That would solve your
> problem
No, we are talking about a way that POV can be parsed
_without_ a special POV parser.
> > This is the whole point of XML. You define the tags that are relevant
> > to your problem domain, specify this to the XML parser, and the rest
> > is mainly automatic.
>
> Again, how is this any different than the existing POV parser?
Because the POV parser is hard coded to parse POV, while an
XML parser can be configured to read any XML based format,
without programming.
> they are
> quite willing to provide the parsing libraries for an honest price.
Doesn't solve the problem of tracking each new version
of POV, or automating conversion of old files, or
handling extensions in a transparent way.
> I'm not sure I'm much of a fan of highly explicit structures, since they
> can easily become limiting and loose substantial flexibility.
Not true with XML.
> But POV is first and formost a rendering application.
POV is ONLY a rendering application. There are
good reasons that it should be more flexible.
> I don't see how any professional user's are shut out from using
> POV?
Because I can't use it as a library, POV has zero
commercial interest to me. I'd also want to bypass
the parser and populate the 3D scene from a Inventor
style scene graph, without using files. I'm shut out.
> The licensing agreement is not much different that the GPL licenses for
> Linux etc.
Yes it is.
> And just for a bit of a teaser, I am looking very seriously at using
> the POV parser in just this way! It means the end product will have to
> be completely open source
I don't see the point of doing this, just to get around the
POV license.
> I just have a very high disregard for people who
> think every body else should do all the work, then they should be able
> to recompile it and pocket all the profits.
Perhaps five years ago I could imagine the scenario
(before the Internet) where someone could take POV,
recompile it, put it in a fancy box, and sell it at
the shops.
> Well, pardon me for being so dense, but I can't seem to find them.
> Perhaps you could put togeather a formal list in some kind of point
> form?
The first post to this thread I thought was very detailed.
--
Nigel Stewart (nig### [at] nigels com)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > You might find that
> > ParPov, at http://www9.informatik.uni-erlangen.de/~cnvogelg/pov2rib/ , is
> > a better choice for your project.
Does anyone know if this supports macros?
It looks quite complete, otherwise.
--
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:
>
> > > You might find that
> > > ParPov, at http://www9.informatik.uni-erlangen.de/~cnvogelg/pov2rib/ , is
> > > a better choice for your project.
>
> Does anyone know if this supports macros?
> It looks quite complete, otherwise.
I seem to recall that it is based on POV-Ray v2.2 and even with that
support it is limited to certain subsets of primitives supported by
Pov. I also seem to recall it is buggy and hard to get working.
But this is all hersay until you get someone else to confirm what
I have said.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 21 Mar 2000 18:03:17 -0800, Ken wrote:
>
>
>Nigel Stewart wrote:
>>
>> > > You might find that
>> > > ParPov, at http://www9.informatik.uni-erlangen.de/~cnvogelg/pov2rib/ , is
>> > > a better choice for your project.
>>
>> Does anyone know if this supports macros?
>> It looks quite complete, otherwise.
>
>I seem to recall that it is based on POV-Ray v2.2 and even with that
>support it is limited to certain subsets of primitives supported by
>Pov. I also seem to recall it is buggy and hard to get working.
It claims support for "version 3" which probably means 3.0, so no macros
or media. I haven't tried too hard to get it working, but the docs do
seem to indicate that it only works with a certain version of some library,
and I seem to recall that PCCTS was a bear to get working.
Great things are happening with upcoming versions of POV, though, so
we shouldn't get too bogged down in all of this. Remember, this is
one of the problems Chris Young said we'd be looking at.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 15 Mar 2000 23:53:21 -0800, Ken <tyl### [at] pacbellnet> wrote:
>> > I think some of the changes being proposed
>> > jeopardize the ease of use I enjoy with the program
>>
>> No, they don't.
>
>If I have to hand code XML then yes they do !
I don't think that Nigel ever encouraged people to hand code in an XML
format. Perhaps you have him confused with me? :)
I started a thread on the IMP mailing lists about that sort of thing,
half-serious and half-joking. Later, I joined the thread you started
here and continued to advocate an XML script style.
Mainly, I wanted to see people's reaction to it, and possibly inspire
some people to think new thoughts. My personal intuition felt the
general idea of mixing POV and XML had some merit, but not being a
programmer, I wasn't sure what the details should be.
Nigel's ideas are definitely more advanced than my suggestions, and I
hope no one confuses what I said with something he said. I certainly
hope that everyone here takes his ideas seriously. I think they have
much merit to them.
Just remember, I was the person that suggested hand coding POV-XML,
not Nigel.
Later,
Glen Berry
IMP Communications Coordinator
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Be sure to read carefully the conditions on how to make and distribute a
custom version of povray.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart <nig### [at] nigelscom> wrote...
>
> The POV license is much more restrictive than GPL or
> the BSD license.
[clip]
> I think if the modellers suddenly had the choice of
> taking their data from Rhino to Autocad to POVray and
> then back to Rhino, without any conversion process,
> they might regard it as a nice feature.
[clip]
> POV is ONLY a rendering application. There are
> good reasons that it should be more flexible.
[clip]
> Because I can't use it as a library, POV has zero
> commercial interest to me. I'd also want to bypass
> the parser and populate the 3D scene from a Inventor
> style scene graph, without using files. I'm shut out.
You bring up very good points. All I can say is that the current license
restrictions on POV were originally intended to protect POV-Ray from
exploitation. Personally, I feel that they are overly restrictive, and POV
can be protected without such strict rules. Of course, I am speaking for
myself and not the POV-Team, but we have begun discussing some of these
issues (in the context of version 4.0).
-Nathan Kopp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 20 Mar 2000 19:09:32 -0800, Bruce <dke### [at] sksympaticoca> wrote:
>To Quote from the same pararaph's:
>"XML is designed to be human legible, and thus mainly text based."
>
>...and to quote from the example a couple pararaph's later:
> <stock_quote>
> <symbol>IBM</symbol>
> <when>
> <date>12/16/1999</date>
> <time>4:40PM</time>
> </when>
> <price type="ask" value="109.1875"/>
> <price type="open" value="108"/>
> <price type="dayhigh" value="109.6875"/>
> <price type="daylow" value="105.75"/>
> <change>+2.1875</change>
> <volume>7050200</volume>
> </stock_quote>
>
>
>My only comment is "just because it uses the modernized Greek alphabet,
>doesn't make it 'human legible'! Although I've been a programmer for a
>...few... years, and I can actually understand it, the term 'barely'
>comes to mind. Ask yourself when the last time was that while reading a
>book you ran across the <aTag> ... </aTag> construct?
I've said this a few times already, but I'll say it again. I'm not
really a programmer. I have written simple BASIC programs in the past.
I've dabbled with machine/assembly language on 6800, 6502, and 8086
compatible microprocessors. More recently, I have written a couple
very simple C language programs. When I look at typical source code
written in C/C++, Perl, or Java, I usually don't a clue what is going
on. These syntax systems seem very alien to me, and nearly
indecipherable. The examples of XML I have seen, are very readable by
comparison.
I think this says a lot. If a non-programmer like me can more easily
interpret XML than the common computer languages in use, it *has* to
be considered human-readable. You claim the word "barely" comes to
mind, but perhaps this is because you have grown so accustomed to
reading another existing computer language. XML *does* look different
than C/C++, Java, etc. You simply have to forget all your
preconceptions of what a language "should look like" to be able to
judge it properly.
>So. To convert the POV language to make it easier to use for people who
>want to make POV tools, seems like a bit of wasted effort, since the
>language parser is already available in source code.
Perhaps you are forgetting that several people have wanted to write a
robust parser for POV in the past, and to my knowledge, no one has.
Apparently, having the POV parser source code available isn't enough
help.
>XML may actually provide useful, but it ain't pretty! And it's a long
>way away from human legible.
I guess it must depend on the human in question. :)
>So tell me, what benefit would this actually provide?
Nigel has already given you a list of advantages. They seemed like
perfectly reasonable and understandable concepts to me. I had also
given some potential advantages myself (Keep in mind, my vision of an
XML implementation was different than Nigel's. I must admit that his
vision of an XML implementation is more interesting.)
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> > So why not make a commercial library to parse POV? That would solve your
> > problem
>
> No, we are talking about a way that POV can be parsed
> _without_ a special POV parser.
>
So, are you talking replacing POV's existing language, or simply
supplementing it? I was under the impression it was the latter,
but if you don't throw away backward compatibility concerns, this
solution will only parse XML format neo-POV files.
Either a POV file can or cannot contain old style code; If it
cannot, that's an end to backward compatibility. If it can, then
what is the generic XML parser going to do when it runs into non-XML
POV code? Ignore it? That's not a total solution and seems vaguely
like writing a parser that only recognizes the keywords added in
MegaPOV, and discards all standard 3.1 code. And #version won't
help, since the generic XML parser doesn't gain POV parsing
capabilities when it encounters a #version directive. You could
write a custom XML parser that also has old style POV parsing
capabilities, but then you've made more work instead of less.
If I understand other discussions around similar subjects, there
has recently been a proposal to create an external API style
language that is preprocessed into standard POV code. Perhaps an
XML style version of this proposal would work better than actually
changing the base SDL of POV-Ray. A scene code in XML style
code would then have all the advantages you indicate without any
of the encumbrance of backward compatibility concerns.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If I understand other discussions around similar subjects, there
> has recently been a proposal to create an external API style
> language that is preprocessed into standard POV code. Perhaps an
> XML style version of this proposal would work better than actually
> changing the base SDL of POV-Ray. A scene code in XML style
> code would then have all the advantages you indicate without any
> of the encumbrance of backward compatibility concerns.
If I understand your post correctly - we're talking about the
same thing in different ways. This is the way I imagine it
unfolding:
1. A clearly defined programmatic API is defined
between POV and the POV-script parser. Something
similar perhaps to the OpenGL API - A basic set
of function calls that can be used to build scenes.
(For the moment, let's ignore political issues
such as the POVteam position of "no API")
2. Definition of an XML based encoding of POV scenes
(perhaps not including loops and macros, to
start with) that can be parsed by an XML parser
and can be glued to the "POV API" without too
much fuss.
3. Support co-existance so that POV-script can
include XML based data and vice versa.
4. Perhaps implement special tags for backwards
compatibility, or supporting any version of
pov script. For example:
<povscript version="3.1">
// Insert your POV script here
</povscript>
or
<povscript version="3.1.megapatch">
// Insert funkier POV script here
</povscript>
I keep having to say the following:
We should keep POV script for it strengths,
ease of hand editing, and general funkyness.
This proposal is not "anti POV script", or
anything like that.
We should look at XML as being a standardised
and extensible scheme that users are not forced
to adapt to. I think that XML can be used
to improve backwards compatibility, rather
than this general reaction of "having to
change/relearn everything".
It may also be interesting to see what the
authors of 3rd party tools think about the
idea. My general concept is that you get the
data in and out in a painless manner, giving
any programmer the facility to manipulate POV
data.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
