In article <38C### [at] nigelscom>, nig### [at] eisanetau wrote:

> > The reason it got a consistently negative response is that it would
> > require a graphical editor to comprehend the simplest scene written in
> > that language. 
> 
>   Keep in mind that you're speaking from the point of view of
>   having already made an investment in the current format.
>   As pointed out already - it's recognisably like DKBtrace,
>   the point being that the use of braces, tags or commas
>   is really quite irrelevant.

Actually, I am not. I am actually working on a language that can be used 
instead of POV-Script.
As you said, 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...


> > 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?


> > it would be even harder to program complex stuff in than it
> > would be in POV-Script
> 
>   No, it wouldn't.  It would be more consistent, more flexible
>   and more extensible.

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.
Even a simple particle system would be a nightmare in that language...


> > harder for non-programmers to write scenes in
> 
>   No, the data is the same, tags are arguably easier for 
>   non-programmers to grasp than "sphere { <0,0,0> 1.0 }"
>   which isn't informative in the slightest.

No, it would be harder for people to write, and nearly impossible to 
read. Tags are *not* easier to understand, if you want to make the 
current language easier to understand, try something like
"sphere {position = < 0, 0, 0>, radius = 1.0}".
Not only does your proposal require much more typing, it makes it much 
easier to lose track of things. Everything disappears in a mess of tags.


> > file sizes would be much bigger...
> 
>   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?
This can be very important if you have several large files.


>   You're right though, a hybrid text/tree/graphical editor
>   would be the ideal incarnation of an XML based scene
>   development tool.

It would be absolutely necessary if you want to write a complex scene, 
and I still don't see how programming features fit in.
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.

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

Post a reply to this message