 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
(crossposted from povray.general - "The Language of POV" thread)
If you've got an itching, an interest, or a burning desire
for XML based POV data storage, speak now. Please don't
recycle the flames from the previous thread... :-)
What I would like to do is develop a proposal - do more
conceptual development, demonstrate more advantages,
consider the implications for the Povray architecture.
Ken Tyler on the idea of XML for Povray:
> > If there are other people who find these
> > possibilities attractive, I would be interested
> > in developing a more detailed proposal. Some
> > aspects would require interaction with the
> > POV team, or the TAG people - but I think it's
> > fair to present them with more than a
> > "we think XML is funky idea" or have them
> > sift through threads of conceptual development
> > and hysterical backlash.
>
> Speaking as a TAG member I will offer this advice. If you can get other
> people excited about your ideas, and between you draft a concrete proposal,
> I would be happy to present it to the POV-Team on your behalf for their
> consideration. It would really help if you could figure out a way to make
> all of us understand the ramifications of your proposal, and get us excited
> about it, but if you are sure it has merit I/we will not stand in your way.
>
> What you need to bring to the table -
>
> 1. Detail your proposal as far as functionality and purpose.
>
> 2. Describe in detail what advantages your proposal has over the current
> system.
>
> 3. Who benefits from the changes or additions of your proposal.
>
> 4. Try to give some indication of how difficult it will be to implement
> and what kind of language support will be needed to make it portable
> to all platforms that POV-Ray currently supports.
>
> Remember that if you cannont get other people here excited about your
> proposal there is little likelihood the POV-Team will get excited about
> it. Also remember that timing may be everything. Right now the POV-Team
> is actively working on finalizing the release of POV-Ray v3.5 which for
> all intents and purposes should be considered feature locked at this time.
> This means from the POV-Team's point of view any action they might take
> towards your proposal will have to wait for their planned C++ re-write
> for POV-Ray v4.0. As far as I know the POV-Team has not entered into
> any detailed discussions on what changes will be made in v4.0, other
> than the move to C++, and it is likely they will want to have their own
> data structure decided before accepting additional suggestions in this
> regard. Their internal discussions will likely be sometime down the
> road when the release of POV-Ray v3.5 has been made public and they have
> had a chance to hammer the public reported bugs out of it.
>
> Keep this in mind...
>
> What you are proposing may actually be better suited for a dedicated
> patch of the program rather than something the mainstream POV-Ray user
> will be interested in having in the official version of the program.
The previous post:
> So what exactly are you suggesting? That POV should use XML for data
> representation and should internally convert POV-Script to XML as well
> as supporting XML input?
I've been giving this some thought today, pondering the
technicalities as well the unexpected hysteria generated
on povray.general and the IMP list. Every day I go to
work improving a software product, trying to deliver the
features that users are asking for. I get a lot of
satisfaction from finding elegant, robust and user
friendly solutions to new problems. But, in the context
of povray, the mere suggestion of some kind of paradigm
shift seems to upset people very quickly.
Anyway - here is a more concrete model of how I think
povray data input should be handled. There needs to
be a clean and simple interface between the POV parser
implementation and the core POVray raytracing engine.
This API might look like a bunch of simple functions
such as "bool insertSphere(...)" which is as minimal
as possible, while supporting all of the POV data types.
Things like loops, variables and macros should be
strictly layered above this API. This API would also
make a nice DLL interface, eventhough the POVteam
don't like the idea of POV being used as a library.
The existing parser simply becomes one possible user
of this API. Text editing die-hards can do whatever
they please, without any threat from trendy programmer
types who want to do different things. Another user
of this API could be an interpreted C environment,
POV-CSDL, XML, or whatever takes people's fancy.
The POV-team control the "official" API, but allow
people to build on top of it freely. Ideally, the
API is also made available as DLL so that Java, C,
Delphi, etc programmers can do whatever they like,
in the language of their choice.
This handles input. Another question is output -
would it be useful and desirable to provide some
mechanism to extract the state of a POV world
at runtime? Maybe, maybe not. I do not intend
to deal with this at this stage.
Before closing, a few points about an XML pov
that perhaps have not been stated clearly:
XML is certainly not customised for the problem
of text editing descriptions of 3D scenes. It's
not bad, but it's not ideal.
XML is a mechanism that would allow third party
tools to manipulate POV scenes. You load the
data in, edit geometry, textures, etc, then
save the data out. One critical limitation in
POV script is the difficulty in parsing it.
In some ways, POV script has been so heavily
optimised for hand editing (in addition to
the macro and looping constructs) that it
is much more complicated than it needs to be
for many other tasks.
XML is a mechanism that simplifies extension.
You don't need to be a parser expert to define
new data types, or to add attributes to objects.
Because the grammar is less ambigous (taking
advantage of verbosity) an XML parser can
ignore irrelevant data - but preserve it.
Backwards compatibilty in a scheme like POV
script is a more difficult problem.
XML allows POV to take advantage of related
technology such as VRML. To support VRML
datatypes, we simply borrow the grammar -
no parser programming necessary. To support
a new procedural texturing architecture, we
borrow their grammar, no parser programming
necessary. (There is a big difference between
writing a parser and writing handlers for
an XML parser)
If there are other people who find these
possibilities attractive, I would be interested
in developing a more detailed proposal. Some
aspects would require interaction with the
POV team, or the TAG people - but I think it's
fair to present them with more than a
"we think XML is funky idea" or have them
sift through threads of conceptual development
and hysterical backlash.
XML is of immediate commercial interest to me
for other projects, so I can justify a lot of
time as developing expertise. ("homework")
I think that there should be at least a
group of people involved, and a healthy
discussion, in combination with some
public relations. If you think that XML
is an interesting technology to apply to
POVray, are just curious about XML, I would
encourage you to drop me an email.
XML does not mean manual editing of tags
in a text editor. People that keep harping
on this are just being silly. But I am quite
convinced that text editing should become a
thing of the past. (I never can remember
the RGB or even name for "that favorite
blueish grey" that I always like to use, nor
should I have to remember junk like that.)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Check out http://www.xml.org/xmlorg_registry/index.shtml
for a nice long list of XML based data definition projects.
POV should be in this list too.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 15 Mar 2000 00:14:02 +1100, Nigel Stewart <nig### [at] nigelscom>
wrote:
>(crossposted from povray.general - "The Language of POV" thread)
>
>If you've got an itching, an interest, or a burning desire
>for XML based POV data storage, speak now. Please don't
>recycle the flames from the previous thread... :-)
>What I would like to do is develop a proposal - do more
>conceptual development, demonstrate more advantages,
>consider the implications for the Povray architecture.
I would certainly like to see what could be done with XML.
Unfortunately, I am not really a programmer. If there is anything I
can help with, I will. I just don't know how much help I will be.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote in message <38C### [at] nigelscom>...
> Anyway - here is a more concrete model of how I think
> povray data input should be handled. There needs to
> be a clean and simple interface between the POV parser
> implementation and the core POVray raytracing engine.
> This API might look like a bunch of simple functions
> such as "bool insertSphere(...)" which is as minimal
> as possible, while supporting all of the POV data types.
> Things like loops, variables and macros should be
> strictly layered above this API.
I'm not particularly interested in an XML POV-script. However, completely
separating the parser from the renderer to allow other languages to be used
for writing POV scenes without going through the intermediary of POV-Script
sounds like an excellent idea.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I'm not particularly interested in an XML POV-script. However, completely
> separating the parser from the renderer to allow other languages to be used
> for writing POV scenes without going through the intermediary of POV-Script
> sounds like an excellent idea.
And an idea that I hope the POV team will consider revisiting.
They have taken the position that POV shall not be used as
a library, but I really do think it's worth reconsidering this
position - at least from a technical point of view.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
(Crossposted from private email to Ken, with permission)
> I do not personally like the example you gave and think
> it unnecessarily makes the scene language harder to use and
> understand.
I'm working on the assumption that hand-editing is
not the only way to describe a 3D scene. XML I think
is editable, but certainly not optimised for this task.
It is however, far more generic and flexible. XML would
never be a replacement for POV script, only an alternative.
> And correct me if I am wrong but isn't HTML just a glorified text based
> word processing and illustration language designed exclusively for 2d
> work?
HTML began as a mark-up language for ASCII. The idea was
to encode the structure of the document (headings, titles,
paragraphs, lists) into the document, and let the browser
decide how to format the result. This is not a new idea,
LaTeX does a similar thing, a document processing system
that to me is similar to XML in its reasoning.
Then, when the World Wide Web became mainstream, HTML got
polluted with tags that control the appearence of the page -
fonts and colours, table style, buttons, etc.
HTML is being evolved to XML in the form of XHTML, version
4 of the HTML standard. The idea of XHTML is that layout
information is in a different file to the document. If you
want to change the way the document looks, you change the
style sheet, rather than editing the data. Therefore,
style information is a template for any data of a given
format, rather than being copied into every instance of that
kind of data.
The document then is purely a data model of the information,
free of nasty formatting information. The XML design allows
databases and other applications read and write XML data
without being bogged down in formatting information.
VRML has been around for quite a long time, it is a file
format that describes many similar objects to those in
POV. VRML is evolving towards XML. The advantage is that
you no longer need a "VRML parser", you use a generic XML
parser and work with the internal representation of the
data - then write the data back out through a generic XML
emitter.
> I just don't see how it, or a variation of it, would apply to a
> 3D object oriented program such as POV-Ray - not to be confused with
> OO programming.
XML can be used for lots of data-description or
data-modelling problems - including POVray.
Is it not reasonable for POVray to be able to
interface to a database system for complex
scene generation? Or, a visualisation package,
or a CAD system? Or an XML editor with tools for
graphical editing of POV specific information?
An interactive texture editing tool? An
interactive CSG modelling application?
> > For someone with a "povray.org" email address, you are
> > behaving in a very entrenched, "old guard" kind of way.
> When I am speaking in the news groups I do so as myself and not
> representing the views of the POV-Team - which I am not even a
> member of.
Ken, perhaps I came across too strongly, but
given that you started the thread as a point
of discussion, I thought you should be more
neutral. Having a "povray.org" email
address is both a privelege and a responsibility.
There is still a perception of "official
viewpoint" even if it unintended.
Creating a lynch-mob environment will simply
scare programmers away from making any kind
of suggestion. Clearly my perspective is quite
foreign to many POV people, but it doesn't
mean that I am allowed to be as critical of
POV users, as users seem to be critical of any
new or different idea.
> As far as entrenched and old guard let me point out as a POV-Ray
> user who is not only proficient with the program, but also as one
> who is satisfied with it's current language structure, I have every
> right to defend it.
You're not only defending what you're like, but you're
attacking the unknown. These tactics are not fair,
and not productive.
> I think some of the changes being proposed
> jeopardize the ease of use I enjoy with the program
No, they don't.
> One of the key factors that has let POV-Ray
> enjoys it's success and popularity to date is the fact that
> it appeals to such a broad range of people that use if for
> very different reasons. If you lose sight of this you run the
> very real risk of alienating a large portion of it's user base.
No, because I have never suggested removing anything
from POVray that is already there and makes it
desirable to these people.
I keep hearing this threat on the povray newsgroups
of "alienating the user base" - but I don't quite
understand it's basis. We certainly need a better
model of interaction than this polarisation.
As a commercial software developer, I spend all day
pondering the user benefit consequences of software
design decisions. I must admit that I find it
strange to be accused of being an "enemy of the users".
--
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:
> > I do not personally like the example you gave and think
> > it unnecessarily makes the scene language harder to use and
> > understand.
>
> I'm working on the assumption that hand-editing is
> not the only way to describe a 3D scene. XML I think
> is editable, but certainly not optimised for this task.
> It is however, far more generic and flexible. XML would
> never be a replacement for POV script, only an alternative.
So if I understand you correctly I will be able to describe my Pov scenes
exactly as I do now without having to use TAGs and all of the other format
styles that come with XML ?
If XML is implemented how will it be incorporated into POV-Ray. Will it
be internal to the program or an external alternative? If external how
will it communicate with POV-Ray ? If POV-Ray has to have two scene
description languages how much baggage will it carry with it ? Is there
any parsing speed advantages with XML ? How much ?
> > > For someone with a "povray.org" email address, you are
> > > behaving in a very entrenched, "old guard" kind of way.
>
> > When I am speaking in the news groups I do so as myself and not
> > representing the views of the POV-Team - which I am not even a
> > member of.
>
> Ken, perhaps I came across too strongly, but
> given that you started the thread as a point
> of discussion, I thought you should be more
> neutral. Having a "povray.org" email
> address is both a privelege and a responsibility.
> There is still a perception of "official
> viewpoint" even if it unintended.
I never attempt to decieve and am careful to be myself. I understand
that there is a certain amount of both privelege and a responsibility
but I also have every right, no every obligation, to speak my own mind.
When I am Mr. TAG or Mr. Linkmaster I sign my messages as such and conduct
myself accordingly. The rest of the time I am going to stay just me.
> Creating a lynch-mob environment will simply
> scare programmers away from making any kind
> of suggestion. Clearly my perspective is quite
> foreign to many POV people, but it doesn't
> mean that I am allowed to be as critical of
> POV users, as users seem to be critical of any
> new or different idea.
I try to be subjective in my criticisms and seldom attempt to encite
a riot. I am also not afraid to speak my mind when I think it is called
for. I certainly don't think that all of our visitors hang on my every
word nor should they. Those who respect me I think do so because they
know me for who I am and not because of my e-mail address. Let's give
the visitors here a little credit for their intellegence.
> > As far as entrenched and old guard let me point out as a POV-Ray
> > user who is not only proficient with the program, but also as one
> > who is satisfied with it's current language structure, I have every
> > right to defend it.
>
> You're not only defending what you're like, but you're
> attacking the unknown. These tactics are not fair,
> and not productive.
The unknown can be a scary place but it's not like I am wearing blinders
either. Sometimes I take the "are you nutz?" stance just to see if I can
get the person making the suggestion to offer a little more clarity about
what they are proposing. We do get some pretty strange suggestions here
on ocassion and you really have to drag the information out of people if
you want to find out what they are really talking about.
> > 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 keep hearing this threat on the povray newsgroups
> of "alienating the user base" - but I don't quite
> understand it's basis. We certainly need a better
> model of interaction than this polarisation.
What polarization ? With as many people as we have using this
program, for so many differnt reasons, there is no polarazation
present at all. If we (we as in the pov world not ME) change
POV-Ray to support XML to please you, will I, and the other hand
coders be pleased ? Will the modelling programmers such as the
author Moray be pleased with having to recode his entire program
that he has been developing for 6 years supporting the current
syntax ? Will all of the utility writters want to go back and
rework their programs to use the new XML language ? Will I be
able to render all of my older scenes ? Who gets hurt and who
gains ? These are serious questions !
I guess that once I understand the answer to my fisrt question in
this message the sooner I will be able to either support XML or
not. And just because I do not support it does not mean that
others will not. If I decide to personaly not support it then
I will stay out of the way and let others do as they wish with
the idea. If Pov changes, and I don't like it, I'll just quit
using the program. Others may do the same.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > I'm working on the assumption that hand-editing is
> > not the only way to describe a 3D scene.
>
> So if I understand you correctly I will be able to describe my Pov scenes
> exactly as I do now without having to use TAGs and all of the other format
> styles that come with XML ?
I think that POV script and an XML format should
coexist. Translation from XML to POV script is
easy, going the other way depends on the design
of the POV parser.
> If XML is implemented how will it be incorporated into POV-Ray.
The best way I can think of is to define an API
between the core POV raytracer, which both
the pov script parser and the XML pov parser
can use.
> If POV-Ray has to have two scene
> description languages how much baggage will it carry with it?
Not much, supporting XML is a matter of linking
in a 3rd party libary and some code that interfaces
to the theoretical POV API. In all, a fraction of
the complexity of the current POV script parser.
> Is there any parsing speed advantages with XML ? How much ?
Maybe, maybe not. Hard to say. Interesting question.
> you really have to drag the information out of people if
> you want to find out what they are really talking about.
Ken, I think I've been quite willing to explain
the ideas.
> > > I think some of the changes being proposed
> > > jeopardize the ease of use I enjoy with the program
> If I have to hand code XML then yes they do !
Nobody is going to force you to hand code XML.
To me, this concern is something like a
bycycle owner being worried that if they
get a car - it will be too heavy to pedal.
One of the points of XML is allow
constrained, relevant, accurate and
application specific editing tools.
> What polarization ? With as many people as we have using this
> program, for so many differnt reasons, there is no polarazation
> present at all. If we (we as in the pov world not ME) change
> POV-Ray to support XML to please you, will I, and the other hand
> coders be pleased ?
This is exactly what I'm talking about. You are the
prosecuter, I am the accused. "You are hereby charged
with attempting to subvert the usefulness of the
POVray raytracer..." Why not just discuss the
technical issues without getting emotive?
> Will the modelling programmers such as the
> author Moray be pleased with having to recode his entire program
> that he has been developing for 6 years supporting the current
> syntax?
The Moray author may in fact have their own
opinion, but I expect that if migration is
optional they'd make a decision based on the
usefulness of the feature. I think it would
be very advantagous for the Moray author to
support XML - suddenly their market expands to
include VRML modelling.
> Will all of the utility writters want to go back and
> rework their programs to use the new XML language?
They wouldn't have to, but they might be
seduced by the new possibilities.
> Will I be able to render all of my older scenes?
That is entirely upto the guys who govern
POV script.
XML scenes are much more likely to survive
revisions because conversion can be
automated. (And because, XML is easy to
parse, while POV script isn't)
>These are serious questions !
Yes, and all the questions need to be asked.
> If Pov changes, and I don't like it, I'll just quit
> using the program. Others may do the same.
If POV doesn't change it will certainly
die a slow painful death. Each comment
like this is another nail in the coffin.
--
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:
> > If Pov changes, and I don't like it, I'll just quit
> > using the program. Others may do the same.
>
> If POV doesn't change it will certainly
> die a slow painful death. Each comment
> like this is another nail in the coffin.
Which is a good reason for me to now keep my comments to myself.
If you do put together a working proposal for the POV-Team let
me know and I will present it to them for you. You can be assured
that I will do so without bias or prejudice and will simply
provide them with whatever material you choose to present.
Other than that there is really not much more I can contribute
to this project because I really am uninformed where XML is
concerned and as such have little to offer in that regard.
Good luck in your endeavors,
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote in message <38D0C535.158EB2F0@nigels.com>...
> I think that POV script and an XML format should
> coexist. Translation from XML to POV script is
> easy, going the other way depends on the design
> of the POV parser.
>
>> If XML is implemented how will it be incorporated into POV-Ray.
>
> The best way I can think of is to define an API
> between the core POV raytracer, which both
> the pov script parser and the XML pov parser
> can use.
Would it be possible to parse and render a mixed format scene, for example,
an XML scene that makes use of existing POV-script include files?
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
