 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Johannes Hubert wrote:
> >
> > Of those, only case 3 looks like possibly decent use. Case 1 and 2
> look very
> > problematic.
>
> Java handles case 1 with a labeled break, doesn't it?
>
> Johannes.
Yes. Which is a bit different. Personally I try to avoid that also.
Among other things you might get a problem of buried meaning. Usually I
code first for correctness and clarity. Then if I get a performance
bottleneck, I go in, but only after measuring actual performance.
But also I usually don't do intense mathematical algorithms, so that may
be another factor.
--
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> In article <38C992EA.4C6238BD@ij.net>, Matt Giwer <jul### [at] ij net>
> wrote:
> > So what is the difference other than a different syntax? The 123
> > ways to create a loop? They all do the same thing in the end.
> > Even step = 3 with I=I+3.
> > Introducing additional syntaxes raises more problems than it
> > solves. With one elementary syntax that can do everything there
> > isn't nearly as much to read and a hundred fewer places for
> > parser differences to creep in.
> The only difference is syntax. But that is a meaningful difference.
> Although a for loop could also be implemented as a while loop, it can
> sometimes be easier to write and understand if written as a for loop.
Actually I would say it is usually more famliar which makes it
appear easier to understand.
> And what do you mean by "a hundred fewer places for parser differences
> to creep in"? I don't think the modifications would be very extensive,
> and there is only one parser.
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.
You can get another debate on permitting i to be both integer
and float.
This stuff may be OBE since the late 70s when was being paid to
look into it perhaps due to the dominance of C or the later
developments of Wirth after Pascal.
> > Next, complex conditional if then else statements. Can GOTO be
> > far behind?
> Umm, we have if-then-else statements. And switch statements. And goto is
> a bad idea for many reasons.
Without GOTO all branches are conditional to another routine.
Permitting GOTOs to exist after falling out of a routine simply
because it is sequencial is what we called spaghetti code. If you
have GOTO you have unconditional GOTOs.
They are nasty little buggers when they show up in late night
sessions. Never want to meet on in the dark.
--
A free internet for free minds.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner wrote:
> In "The Art of Computer Programming", Knuth uses a GOTO in one of the
> algorithms, simplifying things greatly.
Does he use it in TWO algorithms? or just one?
And what is his overall opinion of it?
BTW: I think I went through that once and don't remember it.
I do remember going through someone's Atari BASIC code once
trying to make sense of it. It was good. I even approached the
author with money for markeing if he could clean it up.
He said he could not clean up his own code as the GOTOs were
workarounds of things "too hard" to correct rigorously. And the
problem with that the possibility of added functionality was as
dependent upon his memory as his ability.
If his mind were off of it for a month, it was frozen code.
--
A free internet for free minds.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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'
--
A free internet for free minds.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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)
Anyway, XML is a way of passing data which avoids the need
for a hard-coded parser in the application. The "file format"
is editable, meaning that it can be extended quite easily
and that new tags for specific purposes do not crash parsers
that don't know what to do with the information. Also,
somthing using XML would be familiar to anyone who's used
HTML or XML for something else.
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>
The question is, I suppose, whether all these TAGS would be
intimidating to a new user, or someone who has spent a lot
of time learning the current scheme.
One thing to keep in mind is that editors could be a lot
smarter using XML than would be possible with a custom
file format. It would be very easy to allow a tree-edit
style, rather than flat text. It would also be easy to
guarantee a well-formed scene without running it through
POV to see if it parses alright.
I guess that XML would imply something of a hybrid mode
of editing between flat text and 3D modelling, which could
possibly unify these two ways of doing things. (I think
I could edit a tree-based editor without a mouse, but I
think a lot of the time I'd rather point-click and select
a colour, rather than typing "Orange", at the other extreme,
die hards that want to edit XML tags, are always free to
do so, without loosing the niceness of drag-and-drop, and
gatgets like that.)
What happens if we want to add new attributes to
a sphere? For example, for a gravity similation
system we also want the mass of the sphere...
In this situation, you extend the definition for
POV XML, add a tag <MASS> which is allowed to
occur in the scope of <SPHERE>, and on the programming
side, add a field to store the mass and initialise
it from the XML intermediate data in the XML parser.
POVray without support for the <MASS> tag, simply
ignores it.
One implication is that there are probably other efforts
to figure out generic DTD's (XML based file formats) for
3D objects, which could form the basis for a POV DTD.
In fact, by making all of the POV specific stuff optional
extensions, you have a good chance of importing and
exporting without running you files through conversion
tools.
I'm no XML expert, but it seems to me that it should at
least be considered, considering the advantages of it.
A few limitations of XML that come to mind - the typing
scheme is limited to "weak typing" which means that really
any text can be inserted between tags, whether it's supposed
to be a floating point number, radius, vector, or whatever.
So POV would probably still barf sometimes.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> One implication is that there are probably other efforts
> to figure out generic DTD's (XML based file formats)
Check out http://www.vrml.org/x3d.html, the working group
who are figuring out how to migrate VRML to XML.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Matt Giwer wrote:
> 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'
<shudder>
--
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote in message <38cb9a68@news.povray.org>...
> Also this new syntax would be very handy sometimes:
>
>#do
> ...
>#until(whatever)
>
> There really are times, where you want to execute the body of the loop at
>least once before the ending condition is tested (for example the condition
>is calculated in the body of the loop).
> With the current #while-loop you would have to calculate the condition
>in two places: First before the loop, and then inside the loop. Copying the
>same code to several places is not a good thing.
Adding this to the parser would be pure hell. EVERY other code block in the
language ends with "#end", making it impossible to mismatch block the start
and end of a block. However, a "#do...#until()" would allow constructs such
as:
#do
/* Do something */
#if(1 = 2)
#until(a = 3)
#end
or
#do
/* Do something */
#if(1 = 1)
#until(a = 3)
#end
The parser would need to be able to recognize this sort of construct and
then recognize that the first case will cause serious problems, but the
second one is fine.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> > One implication is that there are probably other efforts
> > to figure out generic DTD's (XML based file formats)
>
> Check out http://www.vrml.org/x3d.html, the working group
> who are figuring out how to migrate VRML to XML.
>
Arrrggg!!! Heelllppp!!!!
Run Away! Run Away!!!
Ok. sorry. it's not really all that bad. It's just that for many things,
VRML seems reaaaaaaaaaly ugly. Especially things like needing to
actually create a visible object before being able to reuse it, etc.
But, the big point of there being 3D XML efforts underway is a good one.
--
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nieminen Juha wrote:
>
> Matt Giwer <jul### [at] ijnet> wrote:
> : Introducing additional syntaxes raises more problems than it
> : solves.
>
> I don't think so.
> A more compact and clearer syntax makes the code more readable and minimizes
> the possibility of errors.
> For example, suppose you have this:
>
> #declare XLoopIndex1 = 0;
> #while(XLoopIndex1 < 100)
> ...
> (30 lines of code)
> ...
> #declare XLoopindex1 = nextValue();
> #end
Make weird_indexname
mark and copy weird_indexname
<CR><CR>
#declare weird_indexname - weird_indexname + whatever
Then go back to the <CR><CR> and insert code. One does know what
one intends before writing one hopes.
--
A free internet for free minds.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote in message <38CC8967.69CBD4F9@nigels.com>...
>Perhaps:
>
><POVSCENE>
> <SPHERE>
> <POSITION> 0,0,0 </POSITION>
> <RADIUS> 1.0 </RADIUS>
> <PIGMENT>
> <COLOR> BLUE </COLOR>
> </PIGMENT>
> <TRANSLATE> -0.5*x </TRANSLATE>
> </SPHERE>
></POVSCENE>
This looks like the scene description language from DKBTrace:
OBJECT
SPHERE <0 2 0> 1 END_SPHERE
TEXTURE
COLOUR RED 1 GREEN 1 BLUE 1
PHONG 1
DIFFUSE 0.1
REFLECTION 0.9
END_TEXTURE
END_OBJECT
OBJECT
PLANE <0 1 0> 0 END_PLANE
TEXTURE
CHECKER
COLOUR RED 1 GREEN 1 BLUE 1
COLOUR RED 0 GREEN 0 BLUE 1
END_TEXTURE
END_OBJECT
The equivalent POV code to this would be:
sphere{y*2, 1 pigment{rgb 1} finish{diffuse .1 phong 1 reflection .9}}
plane{y, 0 pigment{checker rgb 1, rgb <0,0,1>}}
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
PoD wrote:
> I like the idea of functions, but I suspect there would be a lot of
> resistance to their introduction.
> Why? they look rather like macros and people will get confused. I'm not
> saying people are dumb but a lot of POV users are not programmers and
> might not appreciate the difference between macros and functions.
That is because they are macros. It just depends upon where the
result is put.
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 -- again, last I was
involved. Assembly calls microcode to deal with registers.
--
A free internet for free minds.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mark Wagner" <mar### [at] gtenet> wrote in message
news:38cc90a4@news.povray.org...
|
| The equivalent POV code to this would be:
|
| sphere{y*2, 1 pigment{rgb 1} finish{diffuse .1 phong 1 reflection .9}}
| plane{y, 0 pigment{checker rgb 1, rgb <0,0,1>}}
And with brace matching it's real nice, can't lose sight of what ends where.
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Matt Giwer" <jul### [at] ijnet> 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
|
|
| |
| |
|
|
|
|
| |
|
|
