 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Matt Giwer" <jul### [at] ij net> wrote in message
news:38CC8966.A65A6022@ij.net...
> Nieminen Juha wrote:
> >
> > You are right.
> > However I think there are some places where the use of goto (at
least in
> > C and C++) is more or less reasonable:
>
> To rephrase Case 1
>
> > - Case 1:
>
> label1: for(cond1)
> label2 for(cond2)
> while(cond3)
> if(skip) goto end_loops elseif (cond1) goto label1
> then goto label2;
> end_loops:
>
> Real quick and I won't swear to it, that should be look for kbd
> 'L' and then 'ogin'
Brrrr. Is that an intentional or unintentional example of horrible
programming with the help of goto?
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner <mar### [at] gtenet> wrote:
: #do
: /* Do something */
: #if(1 = 2)
: #until(a = 3)
: #end
: or
: #do
: /* Do something */
: #if(1 = 1)
: #until(a = 3)
: #end
Both of those should issue an error.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart <nig### [at] nigelscom> wrote:
: An example of what code may look like?
: sphere {
: <0, 0, 0>, 1
: pigment { Blue }
: translate -0.5*x
: }
: Perhaps:
: <POVSCENE>
: <SPHERE>
: <POSITION> 0,0,0 </POSITION>
: <RADIUS> 1.0 </RADIUS>
: <PIGMENT>
: <COLOR> BLUE </COLOR>
: </PIGMENT>
: <TRANSLATE> -0.5*x </TRANSLATE>
: </SPHERE>
: </POVSCENE>
Looks horrible.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> Perhaps:
>
> <POVSCENE>
> <SPHERE>
> <POSITION> 0,0,0 </POSITION>
> <RADIUS> 1.0 </RADIUS>
> <PIGMENT>
> <COLOR> BLUE </COLOR>
> </PIGMENT>
> <TRANSLATE> -0.5*x </TRANSLATE>
> </SPHERE>
> </POVSCENE>
Please, NO!
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CC8967.69CBD4F9@nigels.com>, nig### [at] eisanetau wrote:
> > In all seriousness, object oriented would work very well for POV-Ray,
> > since it
> > models... objects!
>
> Jon,
>
> You havn't raised XML in this thread - I think it is quite an
> appropriate opportunity to talk about it. People are used to
> the HTML idea generally, but HTML has evolved into a bit of a
> mess, so it may not be a great idea to suggest XML from this
> viewpoint... (sigh)
> ...
> sphere {
> <0, 0, 0>, 1
> pigment { Blue }
> translate -0.5*x
> }
>
> Perhaps:
>
> <POVSCENE>
> <SPHERE>
> <POSITION> 0,0,0 </POSITION>
> <RADIUS> 1.0 </RADIUS>
> <PIGMENT>
> <COLOR> BLUE </COLOR>
> </PIGMENT>
> <TRANSLATE> -0.5*x </TRANSLATE>
> </SPHERE>
> </POVSCENE>
Er, no offense, but that is extremely ugly syntax and just about
unreadable. Add in looping, conditionals, variables(with arrays), and
macros, and you have a real nightmare. It is going in the opposite
direction I would like to see POV go. I think if this replaced
POV-Script, people would go to other things instead, and if it was an
option along with POV-Script, very few people would use it(even
modellers would probably output in POV-Script for file size reasons).
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CC8493.A5135501@ij.net>, Matt Giwer <jul### [at] ijnet>
wrote:
> I mean implementation differences. On an i++ while you can get a
> debate started among purists as to while i < 5 should bail out or
> 4 or 5 in that should the < be checked before or after evaluating
> and changing the variables in the loop.
Implementation differences between POV and what? There is still only one
parser currently available.
And we are talking about for loops, not the ++ operator. The ++ operator
is well defined, no reason for debate over it, and most likely couldn't
be applied to POV syntax without completely redesigning the variable
syntax.
A #for(;;) loop is also well defined and quite possible with POV syntax.
> You can get another debate on permitting i to be both integer
> and float.
Huh...what? POV doesn't have integer types, everything is a floating
point number. And how would this be a debate?
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Xplo Eristotle wrote:
> Finally, it's my opinion that the POV language is *already* OO. I would
> love for anyone who disagrees to explain to me how
Ok, I agree that POV is already OO. I personnally prefer the current "braces"
syntax, but let's say that it's just because I was trained in procedural
programming and that "dot" syntaxes are better for POV (note : I agree that they
are in professional development environments).
Now, what a full pov scene would look like if it was coded like that ?
For example, could it be possible to have an ideal "dot" translation of something
like the following (extract of a scene I'm working on). Or of a large CSG
construct ? I'm just curious.
G.
#declare m=2;
#declare ry=1*m;
#declare a=degrees(m/ry);
#declare at=0;
#declare tr=80;
#declare Pave = object{ #include "pave.inc" translate y*0.5 scale m*0.5*1.6}
#declare Paves=array[8]
#declare Paves[0]=object{Pave}
#declare Paves[1]=object{Pave rotate y*90}
#declare Paves[2]=object{Pave rotate y*180}
#declare Paves[3]=object{Pave rotate y*270}
#declare Paves[4]=object{Pave scale <-1,1,1>}
#declare Paves[5]=object{Pave scale <-1,1,1> rotate y*90}
#declare Paves[6]=object{Pave scale <-1,1,1> rotate y*180}
#declare Paves[7]=object{Pave scale <-1,1,1> rotate y*270}
#declare rd=seed(0);
#declare finPave=finish{ambient 0 diffuse 0.6 specular 0.02 roughness 0.05}
#declare sc=0.1;
#declare colPave=colHouse1+<0,0.04,0.04>;
#declare Sol=union{
#while (at<360*tr)
#declare np=int(rand(rd)*8);
#declare vpos=vaxis_rotate(ry*x,y,at);
#declare vturb=vturbulence(3, 0.5, 6, vpos*0.008); // Thanks Chris Huff
!!!
#declare vturb2=vturbulence(3, 0.5, 6, vpos*0.08);
#declare coltmp=color colPave*(1+abs(vturb2.x));
object{Paves[np]
rotate (1-rand(rd))*20*y
scale <1,(1+vturb.y*2)*0.3,1>
translate <ry,(1+vturb.y*2)*0.3,0>
rotate y*at
texture{
pigment{granite color_map{[0 coltmp][0.4
coltmp][0.6 coltmp*0.8][1 coltmp*0.5]}}
finish{finPave}
scale 0.1
}
}
#declare ry=ry+ m*m/(pi*(2*ry+m));
#declare a=degrees(m/ry);
#declare at=at+a;
#end
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CCCE55.DBB148AD@inapg.inra.fr>, Gilles Tran
<tra### [at] inapginrafr> wrote:
> #declare vturb=vturbulence(3, 0.5, 6, vpos*0.008); // Thanks Chris Huff
Er, actually, I didn't write that function. I wrote the vtransform()
function. :-)
Can someone try a vwarp function? I attempted one, but didn't make much
progress.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I think if this replaced POV-Script, people would go to other things
> instead, and if it was an option along with POV-Script, very few
> people would use it(even modellers would probably output in
> POV-Script for file size reasons).
Hmmm...
A consistently negative reaction...
An idea before it's time?
Or a community behind the times?
--
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 think if this replaced POV-Script, people would go to other things
> > instead, and if it was an option along with POV-Script, very few
> > people would use it(even modellers would probably output in
> > POV-Script for file size reasons).
>
> Hmmm...
>
> A consistently negative reaction...
> An idea before it's time?
or behind the times...
> Or a community behind the times?
or a community that knows where it wants to go.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CCD832.7716F736@nigels.com>, nig### [at] eisanetau wrote:
> > I think if this replaced POV-Script, people would go to other things
> > instead, and if it was an option along with POV-Script, very few
> > people would use it(even modellers would probably output in
> > POV-Script for file size reasons).
>
> Hmmm...
>
> A consistently negative reaction...
> An idea before it's time?
> Or a community behind the times?
Or a screwdriver being used as a hammer? It might eventually get the job
done, but isn't as easy to use, isn't designed to be used that way, and
will probably ruin the screwdriver.
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. It just isn't the right tool for the job, there would be
no reason to use it, and several reasons not to use it(it would be even
harder to program complex stuff in than it would be in POV-Script, and
harder for non-programmers to write scenes in, file sizes would be much
bigger...).
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
> 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.
> 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.
> 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.
> file sizes would be much bigger...
Mesh data aside, it is completely irrelevant.
5k vs 8k? Is it that important?
You're right though, a hybrid text/tree/graphical editor
would be the ideal incarnation of an XML based scene
development tool.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Check out http://www.vrml.org/x3d.html, the working group
> > who are figuring out how to migrate VRML to XML.
> VRML seems reaaaaaaaaaly ugly. Especially things like needing to
> actually create a visible object before being able to reuse it, etc.
The semantics of VRML are not the point. Eventhough VRML is not
perfect for everything, it is at least a standard. Is there no
benefit in taking about spheres in the same way that VRML does?
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> > #declare vturb=vturbulence(3, 0.5, 6, vpos*0.008); // Thanks Chris Huff
>
> Er, actually, I didn't write that function. I wrote the vtransform()
> function. :-)
Oops, thanks Ron or Nathan then (it's not clear who wrote it, at least in the
docs, didn't check the source). Anyway it's a wonderful function.
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CCE1C6.275E2B13@inapg.inra.fr>, Gilles Tran
<tra### [at] inapginrafr> wrote:
> Oops, thanks Ron or Nathan then (it's not clear who wrote it, at
> least in the docs, didn't check the source). Anyway it's a wonderful
> function.
I think it was the Smellenberghs.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > 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] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<bzzt!> It wasn't Ron's, or Nathan's or Smellenberghs'. It was originally
found by Ken on this site (which appears to have died):
http://kolos.math.uni.lodz.pl/~garusk/eng/povadds.htm
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
TonyB wrote:
>
> <bzzt!> It wasn't Ron's, or Nathan's or Smellenberghs'. It was originally
> found by Ken on this site (which appears to have died):
> http://kolos.math.uni.lodz.pl/~garusk/eng/povadds.htm
Strange. That is the second time that site has gone off line. Last
time I almost removed the link and it mysteriously came back on line.
Perhaps it will again someday - maybe not.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Johannes Hubert wrote:
>
> "Axel Baune" <aba### [at] neuroinformatikuni-ulmde> wrote in message
> news:38C8DAB2.3BE14CC3@neuro.informatik.uni-ulm.de...
> >
> > No, I don't think so. In most programming languages the state of the
> > variables used in a for-loop are undefined outside the loop, but most
> > programmers ignores this and use the mostly undocomented feature, that
> > after the for-loop the variable has the value of the variable in the
> > last loop incremented by the specified step.
>
Hello,
Johannes Hubert wrote:
> Not really correct either. You are probably thinking of C++, where the
> ISO/ANSI standard says that a variable declared (and initialized) inside
> of the for-statement is defined only in the statement and the block that
> belongs to it. A fact that is still ignored by most compilers (the
> standard is still kind of fresh).
The standard isn't that fresh. This 'definition' for an for-loop was the
original design of the computer scientists for the basic programming
language independant programming standard. But, however the compiler and
most standards ignored it till jet.
PoD wrote:
> This is getting away from the gist of the thread though.
Yes, you are right. All I wanted to express was, that with such (dirty)
possibilities of the for-loop, the code may be less understandable by
newbies and also for advanced users. I don't know how you leard new
programming languages, but I for myself learn mostly by looking into
code from advanced programmers. But sometimes it is very hard to
understand their code, because they used very cryptic programming and
'dirty' tricks (the for-loop is one of the programming structures at the
top of list used in 'dirty' tricks)
With you permission I will say no more to this. I've stated my opinion,
and I don't want to overstress it anymore.
Thanks, and sorry if my words are/were a bit rude,
Your Axel Baune
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Axel Baune" <aba### [at] neuroinformatikuni-ulmde> wrote in message
>
> Johannes Hubert wrote:
> > Not really correct either. You are probably thinking of C++, where
the
> > ISO/ANSI standard says that a variable declared (and initialized)
inside
> > of the for-statement is defined only in the statement and the block
that
> > belongs to it. A fact that is still ignored by most compilers (the
> > standard is still kind of fresh).
>
> The standard isn't that fresh. This 'definition' for an for-loop was
the
> original design of the computer scientists for the basic programming
> language independant programming standard. But, however the compiler
and
> most standards ignored it till jet.
I was talking about the ISO/ANSI C++ standard, which is "kind-of" fresh
(when was it ratified, summer of '98 or such?).
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think you are forgetting the point that XML was never designed to be
written or read by human users.
It is meant as a platform independent way to describe data, to be used
in different applications.
It is not meant to be written by hand in an editor, because if you try
that, you will soon despair (or are a true masochist :)
Thus, for all the people who are handcoding their POV-Scenes, XML is no
alternative to POV-Script. And will never be.
As a platform and application independent format to exchange 3D scene
descriptions maybe, but that is a different issue...
Johannes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> > > Check out http://www.vrml.org/x3d.html, the working group
> > > who are figuring out how to migrate VRML to XML.
>
> > VRML seems reaaaaaaaaaly ugly. Especially things like needing to
> > actually create a visible object before being able to reuse it, etc.
>
> The semantics of VRML are not the point. Eventhough VRML is not
> perfect for everything, it is at least a standard. Is there no
> benefit in taking about spheres in the same way that VRML does?
Not sure. I'd have to get back up to speed with the spec again to find
out. But I was just wanting to mention that any VRML specific usage of
XML should be critically examined, as their design views may differ from
those used to create POV-Ray. Things may or may not map well.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CC002C.6DBE9012@merlin.net.au>, PoD <pod### [at] merlinnetau>
wrote:
>Show me a simple syntax that lets you create a tree with different
>textures for trunk, branches, twigs, leaves, fruit, flowers.
>And has declarations of objects to use for the above.
Well, I'd separate out a simple IFS from full-blown LSystem, since it
ought to be easier (and happens to be what I'm interested in :*)
#declare deadSeed = seed(99);
#declare tree = ifs {
children 3 //number of children that bloom from each 'branch'
angles {
<30,0,0>, <0,60,60>, <0,30,0>
} //angle change for each child
sizes {
<.8,.75,.75>, <.6,1,1>, <.5,.5,.5>
} //size change for each child
deadends {
deadSeed
.1,.05,.05
} //chance of a dead end for each iteration, as well as the
//seed to use for randomness
levels 5
level_map {
[1-2 texture { trunknbranches }]
[3 texture { greentrees }]
[4 texture { greenleaves }]
[5 texture { flowers }]
} //might also use a 0-1 range
method dot_approximation //I've forgotten the name of this
//other method would be to draw every piece
turbulence .25
//turbulence might not be the right keyword; might have to
//be separated into 'angle_turb' and 'size_turb'.
//some items might not be able to be applied to some methods
//also, a completely separate 'flower' object might not be a bad idea:
//flower { object { treeFlower } }
//which goes on the end of any branch that makes it to the top level
}
Have I forgotten any necessary information?
Jerry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <jerry-9FD538.11170613032000@news.povray.org>, Jerry
<jer### [at] acusdedu> wrote:
> Well, I'd separate out a simple IFS from full-blown LSystem, since it
> ought to be easier (and happens to be what I'm interested in :*)
>
> #declare deadSeed = seed(99);
> #declare tree = ifs {
> ...
> }
>
> Have I forgotten any necessary information?
Maybe leaves?
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? :-)
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CCF223.EE4E8A91@nigels.com>, nig### [at] eisanetau wrote:
> I'm going to stand by this. Whether it is braces, tags,
> commas, dots or my favorite character ~ , it is not
> too important.
Maybe not to the computer, but to the person reading and writing it
there is a huge difference.
Are you saying that:
<STATEMENT>PARAMETERS</STATEMENT>
is as easy to understand as:
STATEMENT {PARAMETERS}
even when you have deeply nested complex statements? That is how I
understood what you were saying...
Hmm, the tilde character(~) as a block character... :-)
> 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 is complex to parse, but parsing isn't the only thing that is
important. The language is useless if you can't write it and understand
what is already written.
And I really don't see why I would want to use Internet Explorer(or any
web browser) to parse POV scripts or edit POV scripts with a web page.
This might be useful for some things, but I don't see how it applies to
POV-Ray. Could you please explain further?
> > 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.
And the costs would be code that only a machine could read and which has
to be written with the aid of a complex piece of software.
I guess we have different priorities. I(and apparently most people here)
want a language which is more flexible and easier to read than the
current POV-Script, and you want a language which you can write a parser
for more easily.(or use an existing parser for)
And for the majority of extensions, you would still have to modify the
POV source code.
> 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.
Writing POV from a program is easy, and it is easy to read and write
data that can be read and written by POV. That is one of the things the
file input-output commands were added for.
Have you tried outputting data into a plain text file and reading it
with POV macros?
> 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.
What exactly are you talking about?
> 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?
That is why I am working on POV C-SDL! Which happens to be human
readable-writable. :-)
> 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.
Do you think there is no reason the most popular programming languages
are designed the way they are? The "flat text" format happens to be
quite versatile, and human *creatable* and human *readable* instead of
something that can only be tweaked by hand and which has to be generated
and read by a program.
> 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.
While it may not be a "new" language, it is definitely a different one.
It is an XML representation of POV-Script, not POV-Script.
> 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.
You seem to define language differently from everyone else. A language
is more than the data model it represents. Otherwise, Pascal and C could
be considered the same language. XML would let *programs* manage the
data more effectively, but would greatly restrict what humans can do.
> 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)
Sorry, I goofed, I didn't notice you said that. But you have to admit it
is a big problem, and if you are using the VRML format, even you have to
admit it isn't POV script.
> 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>
Yeargh! That is awful! :-)
And what about loops and conditionals?
Try this:
#macro TextLabel(Text, Position)
text {ttf "timrom.ttf", Text, 0.1, 0
no_shadow
translate Position
}
#end
Do you really claim they are both as easy to read?
BTW, here would be a theoretical C-SDL version(using a slightly updated
syntax from what is posted in .off-topic:
function object TextLabel(string Text, vector Position)
{
return text {
font_name = "timrom.ttf";
text_string = Text;
has_shadow = no;
transforms.translate(Position);
};
};
> 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.
Syntax highlighting can be done now. I know, since both the official Mac
version and MacMegaPOV do it. And the Windows editor apparently does
too. I don't know about the Linux versions, but I assume they have
similar features.
> 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.
What cross-platform GUI tools are you referring to?
With plain text human-readable code, you can edit it with whatever text
editor you want, and there are many of them for each platform, some with
very powerful macro and scripting capabilities of their own. It will be
a long time until a similar variety of that type of tool is available on
all the platforms POV runs on. Many people would probably give up on POV
before then...
> Anyway, I don't see the need to be so hostile.
Sorry, I don't mean to appear that way.
> 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.
Just don't forget that it won't keep developing if everyone stops using
it because of a poor design choice.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It is complex to parse, but parsing isn't the only thing that is
> important.
You're right - parsing is not the only important
thing - but it is important.
> And I really don't see why I would want to use Internet Explorer(or any
> web browser) to parse POV scripts or edit POV scripts with a web page.
Internet Explorer is capable of displaying an XMLish POV
script in "traditional" POV script, complete with syntax
highlighting. Alternatively, you could display it in
whatever notation makes the most sense. The important
point is that many applications will be able to work with
XML, whereas not many applications will ever be able to
work with POV Script, except as ASCII text.
> I guess we have different priorities. I(and apparently most people here)
> want a language which is more flexible and easier to read than the
> current POV-Script, and you want a language which you can write a parser
> for more easily.(or use an existing parser for)
XML is more flexible than POV Script. One way to keep
everyone happy, would be to provide a translation layer
from POV script. It's a better design than having a
monolythic parser that tries to be everything to everyone.
> And for the majority of extensions, you would still have to modify the
> POV source code.
Yes, but these changes would be much simpler.
> Writing POV from a program is easy
Yes, but once in POV script, you can't do anything else
with it.
> That is why I am working on POV C-SDL! Which happens to be human
> readable-writable. :-)
What I've seen of POV C-SDL looks quite nice.
Do you think this should be layered on top of
POV, or compiled straight into the binary?
(Where do I find docco on POV C-SDL?)
> Do you think there is no reason the most popular programming languages
> are designed the way they are? The "flat text" format happens to be
> quite versatile, and human *creatable* and human *readable* instead of
> something that can only be tweaked by hand and which has to be generated
> and read by a program.
Programmers are quite familiar with the strengths and
weaknesses of using flat text. There is not reason that
programming languages should have to be this way. To
limit your imagination to this way of doing things is
unnecessary.
> You seem to define language differently from everyone else. A language
> is more than the data model it represents. Otherwise, Pascal and C could
> be considered the same language. XML would let *programs* manage the
> data more effectively, but would greatly restrict what humans can do.
Pascal and C are nearly equivalent languages. They are
basically the same technology. The fact that it's
possible to generise away from either Pascal and C
and provide translation to either - is a powerful idea.
The point here is the exact format expected by a particular
compiler (say C or Pascal) is not as important as the
struture of the underlying data that you're feeding it.
XML captures this data, while being generic about the
formatting.
> What cross-platform GUI tools are you referring to?
A few off the top of my head:
V is a cross platform C++ library for GUI's
Qt is the basis for the KDE project
Gtk is the basis for Gnome, and is being ported to windows
Java
There are quite a few other options.
> It will be a long time until a (graphical) tool is available on
> all the platforms POV runs on.
I don't think it's as big an issue as you believe it is.
> Many people would probably give up on POV before then...
I think that as long as people still have POV script
as an option, they are not going to be concerned with
the underlying technology used for implementation.
> Just don't forget that it won't keep developing if everyone stops using
> it because of a poor design choice.
I think that using POV Script as _the only_ way to get
data into POV is a worse design choice.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CD7C45.38B53962@nigels.com>, nig### [at] eisanetau wrote:
> XML is more flexible than POV Script. One way to keep
> everyone happy, would be to provide a translation layer
> from POV script. It's a better design than having a
> monolythic parser that tries to be everything to everyone.
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?
> > And for the majority of extensions, you would still have to modify the
> > POV source code.
>
> Yes, but these changes would be much simpler.
Not necessarily. It is pretty easy to add parsing code for most
features, and it should get a lot easier in POV 4.0 after the planned
conversion to C++.
> Yes, but once in POV script, you can't do anything else
> with it.
I really don't know what you mean by that...
> What I've seen of POV C-SDL looks quite nice.
> Do you think this should be layered on top of
> POV, or compiled straight into the binary?
> (Where do I find docco on POV C-SDL?)
I posted a description of my concept in .off-topic. It would be
translated by a separate program into POV-Script, either by converting
loops, conditionals, etc. to POV-Script syntax or by executing the C-SDL
code and outputting the objects and scene settings. Eventually, it might
be included as an actual feature of POV, but it would probably be wise
to wait for most of the problems to be worked out of it(of course, a
parser/converter has be be written for it before that can start. I am
making an attempt, but would welcome any help anyone would want to
give.).
> Programmers are quite familiar with the strengths and
> weaknesses of using flat text. There is not reason that
> programming languages should have to be this way. To
> limit your imagination to this way of doing things is
> unnecessary.
But is it actually limiting? I don't feel very limited...can you give an
example?
BTW, have you ever heard of the ProGraph programming "language"? Just
wondering...
> Pascal and C are nearly equivalent languages. They are
> basically the same technology. The fact that it's
> possible to generise away from either Pascal and C
> and provide translation to either - is a powerful idea.
But they are separate languages. They can both be used to express the
same idea, but they are different things. Just as English and Spanish
are different human languages, they can both express the same "data",
but are clearly separate languages.
> The point here is the exact format expected by a particular
> compiler (say C or Pascal) is not as important as the
> struture of the underlying data that you're feeding it.
> XML captures this data, while being generic about the
> formatting.
The problem is that it is too generic, it can't be hand-edited easily.
Special tools are required.
It is more of a file format than an actual language...
> > What cross-platform GUI tools are you referring to?
>
> A few off the top of my head:
>
> V is a cross platform C++ library for GUI's
> Qt is the basis for the KDE project
> Gtk is the basis for Gnome, and is being ported to windows
> Java
> There are quite a few other options.
And these will let me create and edit files written in this XML-POV
without being exposed to the XML "syntax"? Or they will let me write
programs that use XML?
> I don't think it's as big an issue as you believe it is.
I think it is. If I don't have the required tools, I can't use it.
> I think that as long as people still have POV script
> as an option, they are not going to be concerned with
> the underlying technology used for implementation.
I think I see what you mean now...some kind of XML-based interpreter
that can read POV-Script as well as XML?
> I think that using POV Script as _the only_ way to get
> data into POV is a worse design choice.
Why isn't POV-Script a good way of getting data into POV? The only
information absolutely required is the objects and things like
global_settings, background, etc. A program can just "run" a scene
described in another language and output the data in POV-Script.
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.
Whatever you think, I am not against XML. I think it is a great idea for
many things, just not the right tool for POV.
--
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nieminen Juha" <war### [at] sarakerttunencstutfi> wrote in message
news:38ccad49@news.povray.org...
> 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.
"on" and "off" ? Programming in pure binary, are you?
rc
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 10 Mar 2000 12:21:22 +0100, Axel Baune
<aba### [at] neuroinformatikuni-ulmde> wrote:
>Hello,
>
>PoD wrote:
>> Then use a while loop and nothing is lost, except that you've made your
>> script hard to read. There's probably an easier way to do it using
>> for()
>
>No, you couldn't do everything with a for-loop what you could do with a
>while-loop. The while-loop is far more flexible, beacuse the for-loop is
>a special case of the while-loop for cases where _one_ variable is
>looped through a range of values with a constant step width.
Did the man say he wanted to *replace* the while-loop, or does he
perhaps want to supplement the while-loop with a for-loop? I see
nothing wrong with having a for-loop in POV. For many situations, it
would be easier for newcomers to understand and it would work
perfectly. The for-loops I have used in the past have also allowed a
STEP parameter that defined the amount of increment for each loop. One
wouldn't have to be limited to incrementing or decrementing by one.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 09 Mar 2000 19:13:21 -0500, Chris Huff
<chr### [at] yahoocom> wrote:
>Still, my first point was a platform specific editor feature is no
>substitute for a language feature.
Whos said anything about a platform-specific editor?
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.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9 Mar 2000 19:53:59 -0500, ron### [at] povrayorg (Ron Parker)
wrote:
>There are other reasons to prefer += in a case like that.
I'll admit that I didn't understand the usefulness of this until you
explained it so well.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 11 Mar 2000 22:42:04 -0500, Chris Huff
<chr### [at] yahoocom> wrote:
>Remember though, that POV-Ray is created by people in their free time. I
>wouldn't want them to delay the releases so documentation like that
>could be written.
I think that the documentation could be improved quite a bit, even
without going into more complex aspects of scene creation. More
illustrations would be a good start.
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.
>> And it would be nice if POV-Ray had some sort of plugin architecture
>This is a nice idea, but would be nearly impossible to implement.
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.
Mind you, I don't dare say that it would be easy to add plugins, but I
think it should be possible somehow.
Even POV itself can't be simply compiled on every platform it is used
on, without some porting work performed by talented human programmers.
If this were not the case, then why is there a Mac specialist, a Linux
specialist, a Windows specialist, etc? It took a long time to get a
Linux port of a recent POV version. If POV were perfectly
cross-platform, then there wouldn't have been the wait.
Also, need I remind everyone that the various ports of Official POV
have different feature sets? The Windows version has a built-in
editor with color-syntax highlighting. I think the Mac version has
QuickTime support. The DOS version has neither.
I think that a plugin system could be devised. Instead of simply
dropping a plugin written for an Intel/Windows machine into a Silicon
Graphics machine running UNIX, one might have to port the plugin the
same way that POV itself is ported. It might even turn out that some
plugins might behave slightly different on different platforms, or
perhaps not be available at all on some platforms. This would be
acceptable to me, as long as everyone realized that plugins were to be
considered *options* and not part of the base functionality of POV
itself.
I don't hear people saying that 'Photoshop shouldn't use plugins
because not all plugins are available on all platforms'. In fact,
plugins are a vital part of Photoshop's appeal for many people, in
spite of the fact that some plugins aren't available on some
platforms.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 13 Mar 2000 17:50:40 -0500, Chris Huff
<chr### [at] yahoocom> wrote:
>In article <38CCF223.EE4E8A91@nigels.com>, nig### [at] eisanetau wrote:
>
>> 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.
>
>Just don't forget that it won't keep developing if everyone stops using
>it because of a poor design choice.
Poor design choices haven't stopped it yet. :)
...and yes, there *have* been at least a few poor design choices.
I say if someone has the ability to write an XML based POV, more power
to them. It would be nice to actually have such a program to test,
instead of just speculating about it. You won't often find me
discouraging experimentation with new ideas. It's often the more
unusual ideas that end up being the most enlightening. Even if an idea
never makes it into mainstream use, there is often still be a place
for it, or it might lead to bigger and better things, as yet
unforseen.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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. One simple routine that can do
everything is quite good enough.
--
A free internet for a free people.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 13 Mar 2000 20:46:03 -0500, Chris Huff
<chr### [at] yahoocom> wrote:
>Not necessarily. It is pretty easy to add parsing code for most
>features, and it should get a lot easier in POV 4.0 after the planned
>conversion to C++.
>
>
>> Yes, but once in POV script, you can't do anything else
>> with it.
>
>I really don't know what you mean by that...
You've been saying that a lot lately, but still you seem content to
judge that which you don't understand.
His point was the POV-Script isn't very easy for another program to
parse. Why would you want to parse POV code with another program? It
would be handy for 3rd party file format converters, modelers,
editors, object generators, and more. Several people have wanted to
write some cool utility programs. but were stopped cold at the
prospect of writing a parser that understood POV code flawlessly. It
would be possible to do, but in many cases, it would be harder than
writing the actual utility program it was to be used with.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 13 Mar 2000 07:16:50 -0500, Chris Huff
<chr### [at] yahoocom> 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.
Perhaps, for you. I think that the vast majority of people would prove
your statement grossly exaggerated at best. Your statements carry the
tone of a person who is either afraid of a new idea, or doesn't
understand it, and vehemently scorns any mention of it. In fact, you
have repeatedly said that you didn't understand the benefits that
Nigel has listed for you, but you seem to still feel qualified to
dismiss the idea as impractical. How can you properly judge that which
you don't understand?
I, on the other hand, would actually find it easier to read and write
in an XML style. Oh sure, it's more typing (assuming you don't have an
advanced editor), but it is more logical, predictable, and extensible.
The "punctuation" is also *MUCH* simpler with tags, because you don't
have to remember whether to use parenthesis, brackets, braces, single
quotes, or double quotes with a given keyword. For the most part,
there are only <> characters for punctuation.
Someone has said that the braces in POV make it really clear and easy
to understand. I say that closing tags, which are more specific than
simple closing braces, are even more simple to sort out. When I see a
closing brace, I have to back track and count braces to see what
keyword that closing brace is associated with. If it were a closing
TAG, then I would know immediately which keyword it was associated
with. How many times have you wasted time chasing a missing closing
brace, or perhaps had one brace too many? (Everyone has an occaisonal
typo, everyone from Ken to Ron Parker.) It would be much quicker to
find a missing or extraneous tag, because they are directly labeled as
to *what* they are actually closing.
>there would be no reason to use it
We've already given you a few reasons to use it, so that comment is
totally incorrect. I can only assume you mean it euphemistically.
>, and several reasons not to use it
Even though I am intrigued by the idea of POVML (XML styled POV), I
will agree that it would be more typing, at least in its *raw form*. I
have suggested in the past that if POVML were adopted, it might be a
good idea to create a cross-platform editor for it that tokenizes the
raw form to conserve file space. The idea is similar to what Atari
BASIC did. You typed in the BASIC program, and the BASIC interpreter
tokenized your file into a much more compact form for its internal
use. The end user only saw the expanded, human readable form, but the
file was actually stored on disk in a tokenized form. This
tokenization is not to be confused with the language interpretation
that happened at run time. In some respects, Atari BASIC was somewhere
between a pure interpreted, and a pure compiled language. Doing
something like this for POVML would solve the filesize problem, and
probably shorten the render-time parsing a little to boot, since at
least some of the parsing work could be done at entry time, during the
tokenization.
This editor could also automatically supply closing tags for you when
you typed the original tag. That would eliminate half the added typing
right there. It would also insure that you always *had* a closing tag,
and never forgot to type one. (Unlike the current situation with
braces and our current editors, where one can easily lose count and
forget a closing brace in a complicated piece of code.)
I think that XML styled POV code deserves exploration.
Later,
Glen Berry
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Glen Berry wrote:
> Someone has said that the braces in POV make it really clear and easy
> to understand. I say that closing tags, which are more specific than
> simple closing braces, are even more simple to sort out. When I see a
> closing brace, I have to back track and count braces to see what
> keyword that closing brace is associated with. If it were a closing
> TAG, then I would know immediately which keyword it was associated
> with. How many times have you wasted time chasing a missing closing
> brace, or perhaps had one brace too many? (Everyone has an occaisonal
> typo, everyone from Ken to Ron Parker.) It would be much quicker to
> find a missing or extraneous tag, because they are directly labeled as
> to *what* they are actually closing.
Then again there is nothing stopping you now from commenting your own code
to accomplish the same thing if clarity is what you seek. It would take
a little time to get used to idea but once you started to practice it you
would no longer have to worry about knowing which closing brace matched
which function. Must the program force you to use good code writing
practices ?
e.g.
} // texture
} // sphere
} intersection
I will also raise one more major disadvantage of moving toward the
<----> tags you mention. It will break every single POV-Ray utility
and modelling program ever created because they have all been programmed
to use the curly brace for opening and closing functions. One cannot
presume that every utility author will take the time to adapt their
programs to this new syntax and in fact it would be unreasonable to
presume that they would want to or are even still around to do so.
I would call that a crippling blow to everyone who uses a modeller
or utility designed to work with the program.
P.S. Most people lose track of which brace closes what because they
indent their code. Indented coding practices are evil and should
be banned.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<KEN>
I will also raise one more major disadvantage of moving toward the
<----> tags you mention. It will break every single POV-Ray utility
and modelling program ever created because they have all been
programmed to use the curly brace for opening and closing functions.
One cannot presume that every utility author will take the time to
adapt their programs to this new syntax and in fact it would be
unreasonable to presume that they would want to or are even still
around to do so. I would call that a crippling blow to everyone who
uses a modeller or utility designed to work with the program.
</KEN>
<GLEN BERRY>
One *more* disadvantage? This would actually be the first disadvantage
you have mentioned in this message. Your previous paragraph dealt with
an issue that could be dealt with in ways other than using an XML
style. It didn't show any inherent disadvantage in an XML style
however.
<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>
</GLEN BERRY>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <38CDD5B5.36C4EB94@ij.net>, Matt Giwer <jul### [at] ijnet>
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] yahoocom
Web page: http://chrishuff.dhs.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > 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] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> : 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] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
