|
 |
> > As pointed out already - it's recognisably like DKBtrace,
> > the point being that the use of braces, tags or commas
> > is really quite irrelevant.
I'm going to stand by this. Whether it is braces, tags,
commas, dots or my favorite character ~ , it is not
too important.
> it resembles the scripting language for DKBTrace, which
> wasn't designed with programming features in mind and was abandoned for
> the current type of scripting language. I see no reason to go
> backwards...
Backwards? Consider the fact that POV Script is complex
to parse. How many applications can parse it? Not many.
In XML, Internet Explorer 5 can parse pov script. Think
about it. With another layer, Internet Explorer 5 could
build a HTML page with a bunch of edit boxes that allow
editing. Or syntax highlighting, or whatever.
> > > It just isn't the right tool for the job
> > For text editing, perhaps not. But for other things, it leaves
> > POV script for dead.
>
> How is that so?
There are two ways to write software. One is to do
everything yourself, as you please. Another is to make
use of the work of others - libraries, standards, file
formats, technology trends. Povray relies on quite a
large and complex parser, implemented in C. To extend
Pov Script, you have to mess with the C parser. To
extend an XML based file format, you edit the DTD
(basically, the grammar) and add handlers for the
intermediate representation made available from the
XML parsing module. Adding new tags in a way that
doesn't break backwards compatibility is straight-
forward.
I would like to be able to write applications which
import and export POV compatible data - but I can't.
Pov script simply isn't easy to parse, only POV can
do it, and this is a handycap.
I think this whole "POV as programming environment"
is neat, but should be allowed to evolve in different
directions on top of something more solid than a
tangle of C parser code.
The current parser was state of the art, for it's
time. It's served us well, and it's been pushed
to it's limits. Is it conceivable that it is
time for an alternative?
> And what makes you think this? Even with the current POV-Script syntax,
> which is much more readable than this, it is easy to lose track of
> things in complex looping/conditional structures.
True, my assumption is that people ultimately want
more powerful and intuitive tools than a flat text
editor. XML is something is perhaps somewhere
between being "human editable" and "machine processable"
and I think that is a good balance for POV to find.
I suspect that XML can in fact keep everyone happy,
as long as someone goes to the trouble of a POV script
to POV XML converter. (Which I think should be a bit
simpler than the full POV parser)
> Even a simple particle system would be a nightmare in that language...
Not at all, you seem to get the impression that this is
a new language - it's not. It's simply POV Script in an
XML form. There are two issues here - (1) the data model,
and (2) the way you encode it in ASCII. I am really only
referring to (2). The whole point of XML is to allow you
to manage the data model more effectively - but it doesn't
mean that you throw away your existing data model to use XML.
> > Mesh data aside, it is completely irrelevant.
> > 5k vs 8k? Is it that important?
>
> How about 1MB mesh vs 3.5MB mesh? Or 30MB mesh vs 75MB mesh?
> Or even larger size increase?
I did specifically say "mesh data aside". And POV is
a terrible way to store meshes - seriously, even VRML
is more compact than Pov Script. Adding Indexed Face
Set meshes to POV would be one of the first "cool"
extensions that would be more easily done in XML.
(Partly because we can borrow the XML DTD for VRML
indexed face set, and be guaranteed compatibility)
> and I still don't see how programming features fit in.
OK, here goes, digging up a random macro to implement:
</macro>
<name> TextLabel</name>
<param>Text </param>
<param>Position </param>
<body>
<text no_shadow="true">
<ttf>timrom.ttf <var>Text</var> 0.1 0 </ttf>
<translate> <var>Position</var> </translate>
</text>
</body>
</macro>
Program code is structured data, after all!
Granted, it's not as easy to read as POV Script,
but converting to/from this to a syntax highlighted
POV Script version should be reasonably easy.
> In order to use something like this, a GUI editor would have to be
> created for each platform, even those without a built-in GUI.
It would certainly be a nice feature, regardless of
the actual scene decription format. And with more
cross-platform GUI tools becoming available, portability
no longer means text-only editing.
Anyway, I don't see the need to be so hostile.
All I want to see here is some more brainstorming
going on. If povray is still available in 2050,
it will only be because it keeps evolving.
--
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
|
|
