![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Glen Berry wrote:
> <JEST>
> As for this "disadvantage" you bring up, it only exists for those
> people that want to use a legacy modeler with the new XML syntax.
> Those people who wish to live in the past can continue using the
> current version of POV with their current modeler. No one is going to
> force them to upgrade.
> </JEST>
<PANIC> Shoot the horse ! Shoot the horse ! </PANIC>
--
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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <38CDD5B5.36C4EB94@ij.net>, Matt Giwer <jul### [at] ij net>
wrote:
> Chris Huff wrote:
>
> Pardon for deleting all of yours but this is my issue.
>
> If syntax is extended then those issues will have to be
> addressed. That is my point.
What issues? That is what I want you to clarify.
The for loop is well defined, POV would use the existing definition,
which is quite possible with the POV syntax.
There is no debate that I have seen over integer versus float
variables within a loop, and that is irrelevant anyway, since POV
doesn't have separate types for integer and float.
The ++ and -- operators would not fit in the current syntax of POV,
so you can forget about them.
> One simple routine that can do everything is quite good enough.
So we should drop the #switch, #macro, and #while features and add #goto
and #label? And get rid of #local while we are at it...
--
Chris Huff
e-mail: chr### [at] yahoo com
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> > Yes, but once in POV script, you can't do anything else
> > with it.
>
> I really don't know what you mean by that...
I mean that once data is stored in POV format,
it is trapped there. Worse than that, it may not
even be compatible with the next version of POV.
> > (Where do I find docco on POV C-SDL?)
> I am making an attempt, but would welcome any help anyone
> would want to give.).
I'm happy to look at what you've got, or exchange
email, but I don't have enough time to follow it
on the newsgroups. I'll keep an eye out though...
> > Programmers are quite familiar with the strengths and
> > weaknesses of using flat text.
> But is it actually limiting? I don't feel very limited...
Yes it is. I spent all afternoon staring at C++ code
wondering why there is no facility to have graphical
documentation embedded in the source code. I do
graphics programming, and the geometric result of
code is not always obvious from the C++ code. Why
can't I extend the C++ file format to stick anything
in there that is relevant? Why can't I rename the
member "A::doXYZ()" without doing a search and replace?
Why can't I get an instant list of all everywhere that
a certain variable is modified, or a function called?
The compiler figures out all this information but
doesn't use it for useful things. C++ programmers
are trapped all day in this klunky ASCII view of
their problem.
I'm sure that some punch-card users didn't feel
very limited either. I used to think Commodore
Basic was pretty cool. Then machine language,
then C, then C++. You don't really see the
limitations until you are freed from them.
> > Pascal and C are nearly equivalent languages.
> But they are separate languages.
They are referred to as separate language, but
they are actually so similar that it may be better
to refer to them as "dialects of procedural programming".
> The problem is that it is too generic, it can't be hand-edited easily.
> Special tools are required.
Special tools are required for editing text too.
You need a computer, monitor, keyboard and
text editing program. Are you taking all this
technology for granted? It must be working well!
> I don't understand this "flexibility" argument, at some point it has to
> be converted into data structures in RAM. The only thing that would make
> adding features easier would be the universal syntax, and that could be
> done in other ways just as well.
Why would you do it in "other ways"? You think
you know better? Do you think XML is some gimmick
that Microsoft cooked up to make you upgrade all
of your software? Find out more about XML,
at the very least it will improve your ability
to argue against it. :-)
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> : From the viewpoint of a computer scientist (I'm one) this is a not a
> : syntactically correct defiend for-loop. The variable of a for-loop
> : belongs to the for-command and should be never _changable_ by the user.
I strongly disagree. It is in fact syntactically correct,
and there is no theoretical reason that the loop variable
is more sacred than any other variable.
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nigel Stewart wrote:
> 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.
If you take into consideration the 1000's of people that have tens of
1000's of hours vested in this program I think it is entirely acceptable
that they would question radical change.
> 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.
--
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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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.
Ken,
Thanks for the advice, and clarifying the roadmap for the POV team.
I don't see any point in rushing this into 3.5.
I would much rather talk about "THE XML PROPOSAL FOR POV" than
"MY XML PROPOSAL". :-)
Nigel
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nigel Stewart wrote:
> I would much rather talk about "THE XML PROPOSAL FOR POV" than
> "MY XML PROPOSAL". :-)
I meant a collective "your proposal" assuming you get others involved
with the project.
--
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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
<AMUSED>
See, we're all getting the idea of tags now, arn't we?
</AMUSED>
> > <JEST>
> > As for this "disadvantage" you bring up, it only exists for those
> > people that want to use a legacy modeler with the new XML syntax.
> > Those people who wish to live in the past can continue using the
> > current version of POV with their current modeler. No one is going to
> > force them to upgrade.
> > </JEST>
>
> <PANIC> Shoot the horse ! Shoot the horse ! </PANIC>
--
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Nigel Stewart wrote:
>
> <AMUSED>
> See, we're all getting the idea of tags now, arn't we?
> </AMUSED>
statement { I felt really dirty while doing it. }
--
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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |