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

<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] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

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

On Tue, 14 Mar 2000 00:45:19 -0500, Glen Berry wrote:
>As for custom-patched versions of POV, every new patch should come
>with multiple examples of each new keyword and concept that are
>introduced. If the patch is available for Windows, then appropriate
>insert-menu addtions should be offered with the patch as well.

Thanks for your input, but if I had to live by those rules I never would
have released the superpatch into the wild and people would still be 
complaining about how many different patches there are.  Programmers do not 
make good writers, and vice versa.  Ideally, someone would volunteer to fix 
the docs and make insert-menu stuff and create example scene files, but all 
y'all do is bitch about how much better *we* could do.  Small wonder I 
stopped doing the superpatch, eh?

>I'm not a serious programmer, but I've always thought that the main
>obstacle to plugins was the attitude of the POV-Team being against
>such things. I thought some people had already proposed workable ideas
>for implementing plugins, but the POV-Team firmly refused the concept.

I'm one of those who proposed plugins before I was a member of the team.  
As I understand it, the idea was seriously discussed and ultimately
rejected because of cross-platform compatibility issues.  Perhaps after
the next round of changes (which I can't discuss now) some of those issues
will go away, but I can almost guarantee that someone, somewhere, will be
so upset by those ultimately useful changes that they'll organize a jihad.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

On 13 Mar 2000 03:56:42 -0500, Nieminen Juha wrote:
>Matt Giwer <jul### [at] ijnet> wrote:
>: 	Everything in computing can be done with the minimalist set of
>: micro-code which actually gets down to four or five instructions
>: depending upon your side in the debate
>
>  Actually 2 instructions are enough.

I once read that you could build a computer with just one instruction.
IIRC, the mnemonic was "decrement and jump if not zero" or something 
like that.  Obviously not the most efficient computer out there, though
(and with only one instruction, you don't need an opcode.  The code IS
the data.)

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

> <POVSCENE>
>   <SPHERE>
>     <POSITION> 0,0,0 </POSITION>
>     <RADIUS>   1.0   </RADIUS>
>     <PIGMENT>
>       <COLOR> BLUE </COLOR>
>     </PIGMENT>
>     <TRANSLATE> -0.5*x </TRANSLATE>
>   </SPHERE>
> </POVSCENE>


No, please.
I like to be able to use a simple text editor to write pov-script. This
POV-XML is just too long, too heavy, too difficult to read and more prone to
typo. And I find it to be un-aesthetic.
Didn't we discuss this issue already? Do you have new arguments?


Povingly,


Philippe

Post a reply to this message

Reluctantly, I will write here some of my thoughts on this polemical
subject. Reluctantly because I have little time, and because I now my
thoughts are far from being mature. Little time also means I did not read
(yet) all the messages in this thread, so I may address points that were
already discussed and "closed". But, please, bear with me, for I feel an
obligation to share my opinion.

Firstly, it seems that this discussion about POV's syntax, present and
future, quickly and repeatedly becomes a discussion about POV features and
wish lists. Many seem to address language/feature additions rather than
syntax changes. While these features additions would result in more keywords
and a few more syntax forms, most of the time they would not produce real
syntactic changes. To the non-programmer user, like I am, an OO style
camera.location is not different from a camera_location variable (but I
understand MyDeclaredObject.min_extent too).

I think POV syntax to be reasonably "good" as it is now. Reasonably because
it exhibits some incoherence. Some come from POV's history (evolution);
others come from different people implementing analogous functions in
different features. Some are, I believe, incoherence only to the
non-programmer, like shadowless and no_shadow. I believe reducing some of
these incoherences can make POV easier to learn and use. I'll throw in some
examples: - shadowless and no_shadow - I'd like all #declare to accept; as
an ending - the use of the comma in different statements could be unified -
texture is where I think POV _should_ have a syntax rewrite. Two examples
(my main concerns, actually): (1) the current implementation use many
different keywords for really similar functions - think of all the *_map;
(2) layering should be explicit, something like texture{layered{texture{T1},
texture{T2. or pigment{layered{.

As you have now surely understood, my only real "dissatisfaction" (quote,
because this word is too strong) in POV's syntax is its lack of unity... I
do not mean that I'd like its _looseness_ to be reduced: it is great to be
able to describe the same thing in different ways and each can choose its
favourite. I mean: I would like if each of these different syntax forms
could be used for every analogous task - and not, as it often is now, have
many features have its own syntax.

As to new features in the syntax, I would accept most gladly.

The for{,,} loop would surely be easier to use than the #while one, but then
I would like to see a while{,} and a #for.#end syntax. Access to object
information would be great, whether it is done with OO-style
MyObect.trace(.) or any other practical way. += style declaration would be
really useful. So would be better variable scoping. Generalisation of the
texture/pattern/function/isoshapes syntax could be really great, but
currently I can see no way of doing this without (1) loosing backward
compatibility (other than the #version switch) and (2) moving up to another
level of abstraction, making things more difficult to the newcomer.

New feature in POV I will always welcome warmly...



Now, I have done my duty, I feel at rest.


Povingly,


Philippe

Post a reply to this message

In article <chrishuff_99-470E46.16512213032000@news.povray.org>, Chris 
Huff <chr### [at] yahoocom> wrote:
>Maybe leaves?

True. Leaves would be a special child in the simple form; if the ifs 
object has three children, each end would get three leaves with the same 
angle changes as any other child. There would have to be a point 
(probably <0,0,0>) that is considered the 'base' of the leaf object.

ifs {
   ....
   leaf { predefinedObject }
}

>This looks rather interesting and quite powerful, although I didn't 
>understand all of it. Several of the features I wouldn't know how to 
>do(well, actually, I don't know how to add any kind of object), any 
>volunteers? :-)

I keep meaning to put my fractal macros on a web page. However, they are 
slow and memory heavy. And I don't personally understand all of the 
mathematics in them :*)

Jerry

Post a reply to this message

Glen Berry <7no### [at] ezwvcom> wrote:
: There must be something I am overlooking here. Aren't programs that
: deal with ASCII text some of the most easily portable programs? Why
: does a POV scene editor ( not a modeler, mind you ) have to rely on a
: lot of platform specific coding? I'm sure someone will be quick to
: remind me of the reason I seem to have forgotten.

  I think that the proposition was to bind a keyboard shortcut for the
task. This is highly system-dependant.

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

On 14 Mar 2000 08:36:03 -0500, ron### [at] povrayorg (Ron Parker)
wrote:

>On Tue, 14 Mar 2000 00:45:19 -0500, Glen Berry wrote:
>>As for custom-patched versions of POV, every new patch should come
>>with multiple examples of each new keyword and concept that are
>>introduced. If the patch is available for Windows, then appropriate
>>insert-menu addtions should be offered with the patch as well.
>
>Thanks for your input, but if I had to live by those rules I never would
>have released the superpatch into the wild and people would still be 
>complaining about how many different patches there are.  Programmers do not 
>make good writers, and vice versa.  Ideally, someone would volunteer to fix 
>the docs and make insert-menu stuff and create example scene files, but all 
>y'all do is bitch about how much better *we* could do.  Small wonder I 
>stopped doing the superpatch, eh?

Now Ron, did I bitch about you or any other patch writer? All I am
saying is that these things should get done. I don't care if the
original author does them, or someone else. One way or another, it
would be good to achieve this. Heck, I'll probably write some insert
menu stuff myself. Whatever I do write, I will share with everyone.

>I'm one of those who proposed plugins before I was a member of the team.  
>As I understand it, the idea was seriously discussed and ultimately
>rejected because of cross-platform compatibility issues.  Perhaps after
>the next round of changes (which I can't discuss now) some of those issues
>will go away, but I can almost guarantee that someone, somewhere, will be
>so upset by those ultimately useful changes that they'll organize a jihad.

I hope not. Holy wars are the most senseless of wars.

Later,
Glen Berry

Post a reply to this message