 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Johannes Hubert wrote:
>
> "Axel Baune" <aba### [at] neuro informatikuni-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
|
|
| |
| |
|
|
|
|
| |
|
|
