 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nigel Stewart wrote:
> This proposal is not "anti POV script", or
> anything like that.
Believe me, the following is not intended as an "anti-XML" speech
either, I just feel that incorporating XML parsing into POV-Ray
directly AND maintaining backward compatibility with existing
hand coded SDL will not meet the desired objectives, and I'm
just trying to present a reason why soas not to sound too
irrational for saying it. After this, I'll dutifully wade to
shore and get out of waters too deep for me <G>.
Going back to a couple of points you made...
> 3. Support co-existance so that POV-script can
> include XML based data and vice versa.
Ok, here's where I lose track of the plan. Because a little while
earlier, you said
> No, we are talking about a way that POV can be parsed
> _without_ a special POV parser.
>
The obvious advantage of which is that 3rd party apps wouldn't
have to write a complete POV parser from scratch. But the
extensibility of XML based languages comes from the founding
princible that any code your app won't know what to do with,
just let the parser ignore it. But while I'm impressed that
VRML is trying to evolve in this direction, I've got to wonder
how it's possible because if we do this...
> 4. Perhaps implement special tags for backwards
> compatibility, or supporting any version of
> pov script. For example:
>
> <povscript version="3.1">
> // Insert your POV script here
> </povscript>
Then what, specificly, is the XML parser going to do with the stuff
between the <povscript>...</povscript> tags? If it has no ability
to parse povscript, it has to ignore it. Yet of course it can't
parse povscript, since to incorporate the whole povscript parser
would defeat the original intent.
But in a 3D data file, ignoring part of the scene isn't a valid
option. Consider, for example, if you had SDL hand code that will
programmaticly place 1500 copies of an object using a #while loop.
Dutifully, you wrap it in <povscript> tags, and then set about
trying to import it into a modeller that incorporates an XML
parser. Trouble is, when the scene loads, it's missing 1500
objects because the XML parser had no plan for interpreting the
code in the <povscript> tags. The same is true with 3rd party
extensions to the language that were specially marked so the
parser would ignore them if it didn't recognize them.
In essence what I'm saying is: In order to model, tesselate,
convert, run lparser mutations, do quick render previews, or
anything else useful, the code between the <povscript> tags
must be read and understood by the app, or the result will
be a defective import that degrades the appearace of the scene
in some way. There'd be no problem if XML-POV were a separate
entity (no pun intended) from standard POV script, but there
are hundreds more examples like this and they all revolve
around trying to keep POV SDL (which we both agree is a
good thing) in XML style POV. It simply "loses too much in
the translation."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > <povscript version="3.1">
> > // Insert your POV script here
> > </povscript>
>
> Then what, specificly, is the XML parser going to do with the stuff
> between the <povscript>...</povscript> tags?
>
> ignoring part of the scene isn't a valid option.
Yes it is.
> Trouble is, when the scene loads, it's missing 1500
> objects because the XML parser had no plan for interpreting the
> code in the <povscript> tags.
True, you can't expect to use XML technology to handle non
XML encoding.
> The same is true with 3rd party
> extensions to the language that were specially marked so the
> parser would ignore them if it didn't recognize them.
True, but it still better than choking on 3rd party
extensions. In fact it is probably all that is possible.
> In essence what I'm saying is: In order to model, tesselate,
> convert, run lparser mutations, do quick render previews, or
> anything else useful, the code between the <povscript> tags
> must be read and understood by the app, or the result will
> be a defective import that degrades the appearace of the scene
> in some way.
No. This is merely an option to keep POV purists happy.
Nothing is "taken away" by using XML. Of course you don't
get the advantages of pure XML by mixing it with POV script.
People who want XML functionality have the choice of
avoiding POV script, and vice versa. Mainly, I'd promote
the ability to include old scenes and macro files.
3rd party tools would have to preserve, but igore extensions
and POV script - this is in fact a desirable property, not
a flaw.
The problems you describe here are a good example of why
you probably shouldn't use this feature unless you really
want to, and you know why you're doing it. Whether 3rd
party tools can handle POV script is beyond the scope of
an XML proposal.
To summarise - the problem identified is valid, but I
disagree with your conclusions. I do not think these
features/issues/problems "degrade" the usefulness of
XML at all.
--
Nigel Stewart (nig### [at] nigels com)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A project to use XML to allow portable exchange of
OpenGL oriented graphical information.
-----------------
XGL File Format Specification
http://www.xglspec.org/
The XGL file format is designed to represent 3D information for the
purpose of visualization. It attempts to capture all of the 3D
information that can be rendered by SGI's OpenGL rendering
library. It uses XML 1.0 syntax, so it is easy to write and
can be parsed by standard, freely available code. These feature
make XGL the ideal format to use when data must be exchanged between
two graphics systems for the purposes of visualization.
The XGL format is intended to work well with systems that use
OpenGL. It should be possible to take a program that renders 3D
information using OpenGL and have that program export an XGL
file. Then, an XGL viewer should be able to create OpenGL
objects that are exactly the same as those rendered by the
exporting program.
Because the XGL format uses XML syntax, it is easy to write
applications that read and write XGL. To export XGL, an
application needs only write out a text file using the XML
syntax. XGL supports a variety of mechanisms for arranging
and referencing data within the file, so it should be easy
to find a method of exporting data that is easy to implement
for any graphics system. There are a number of free XML
parsers available, eliminating the need to implement a
complex parser when building an XGL reader.
--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Foreword: i'm not sure that the thread still serves something, but what
tf!!
Nigel Stewart wrote:
>
> A project to use XML to allow portable exchange of
> OpenGL oriented graphical information.
>
> -----------------
>
> XGL File Format Specification
> http://www.xglspec.org/
[snip]
What do you actually propose???
that instead of declaring
sphere{
...}
we do:
<primitive
<sphere
Location="12,34,56"
<Texture
<checkered color1=1,.5,1 color2=1,.6,.4>
<transformation>
<rotate 10,0,0>
</tranformation>
>
>
>
(which is pretty structured, compared to what i have seen in web
pages)??
IMHO, it sure is simpler to make a quick parser for it(though , but you
lose much of the possibilities(actually, it becomes more of a hassle)
that using curly brackets to denote which operation is for what part of
the declaration).
BTW, i find that POV's syntax is easier to read(and to parse, if you
take the good way, probably) than XML, BC it was invented to make
human's coders life easier...
BUT, if we didn't have already anything on the table, XML would be a
not-so-bad idea... but how the f*** would u parse the example
above??(Definition language weren't made to support imbricked
things/tags that work only in another tag(see transformation: depending
of its position, it doesn't have the same meaning), imho)
(And, btw, OPenGL is NOT supposed to be human editable...)
LOL, i've got more text in parenthesis than not ;-)
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 30 Mar 2000 21:39:58 -0500, pk wrote:
>[snip]
>What do you actually propose???
>that instead of declaring
>sphere{
>...}
>
>we do:
><primitive
> <sphere
> Location="12,34,56"
> <Texture
> <checkered color1=1,.5,1 color2=1,.6,.4>
> <transformation>
> <rotate 10,0,0>
> </tranformation>
> >
> >
> >
That's not XML. It would look more like
<sphere location="12,34,56" radius="1">
<texture>
<checker>
<color rgb="1,.5,1" />
<color rgb="1,.6,.4" />
</checker>
<rotate><x>10</x></rotate>
</texture>
</sphere>
Note that the distinction between elements and attributes is pretty
arbitrary. When designing a DTD you would have to put some thought into
deciding whether it should be
<sphere location="12,34,56" radius="1" />
or
<sphere>
<location>
<vector>
<x> 12 </x>
<y> 34 </y>
<z> 56 </z>
</vector>
</location>
<radius> 1 </radius>
</sphere>
or something in between.
>(which is pretty structured, compared to what i have seen in web
>pages)??
Most web pages aren't even syntactically correct (Try to point
http://validator.w3.org at some randomly chosen web pages), HTML allows
various shortcuts, and - most importantly - it is meant for marking up
text, not describing a data structure.
>BTW, i find that POV's syntax is easier to read
So do I.
>(and to parse, if you take the good way, probably)
Depends on what mean. A specially coded POV-Script parser is probably
faster at parsing a szene than an XML parser. But writing an XML parser
is easier, and you don't have to do it, because it already exists. (Of
course, at least two povscript parsers exist, too, so this may be a weak
argument).
>Definition language weren't made to support imbricked things/tags that
>work only in another tag
It does. In HTML, for example, a <title> element can only occur inside a
<head> element.
hp
--
|_|_) | Sysadmin WSR \ Durchbruch in der Bionik, und Microsoft geht
| | | hjp### [at] wsracat \ Pleite und Gardena bringt organische PC's
__/ | http://www.hjp.at/ \ auf den Markt. -- Stefan Schaefer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter J. Holzer wrote:
>
> On Thu, 30 Mar 2000 21:39:58 -0500, pk wrote:
> >[snip]
> >What do you actually propose???
> >that instead of declaring
> >sphere{
> >...}
> >
> >we do:
> ><primitive
> > <sphere
> > Location="12,34,56"
> > <Texture
> > <checkered color1=1,.5,1 color2=1,.6,.4>
> > <transformation>
> > <rotate 10,0,0>
> > </tranformation>
> > >
> > >
> > >
>
> That's not XML. It would look more like
>
> <sphere location="12,34,56" radius="1">
> <texture>
> <checker>
> <color rgb="1,.5,1" />
> <color rgb="1,.6,.4" />
> </checker>
> <rotate><x>10</x></rotate>
> </texture>
> </sphere>
same idea: cumbersome 8)
> Note that the distinction between elements and attributes is pretty
> arbitrary. When designing a DTD you would have to put some thought into
> deciding whether it should be
>
> <sphere location="12,34,56" radius="1" />
there a > and a < missing
>
> or
>
> <sphere>
> <location>
> <vector>
> <x> 12 </x>
> <y> 34 </y>
> <z> 56 </z>
> </vector>
> </location>
> <radius> 1 </radius>
> </sphere>
>
> or something in between.
>
> >(which is pretty structured, compared to what i have seen in web
> >pages)??
>
> Most web pages aren't even syntactically correct (Try to point
> http://validator.w3.org at some randomly chosen web pages), HTML allows
> various shortcuts, and - most importantly - it is meant for marking up
> text, not describing a data structure.
lol...
> >Definition language weren't made to support imbricked things/tags that
> >work only in another tag
>
> It does. In HTML, for example, a <title> element can only occur inside a
> <head> element.
That's not what i meant, sorry...
I meant that there isn't a tag(transformations come to mind) that work
different way depending of the tag in which it's imbricked...
Anyway, i'd be happier if instead of only having predefined shapes, you
could extend the language with an interpreted language ala java, where
there is, say:
Primitive.Class
|
|-cube
|
|-cone
|
|-plane
...
Where the primitive class contains everything you need to define an
object, except the function that defines the object in itself(it parses
everything and calls the good function in the class)
Like, put the result in a public array in the same format the current
rendered uses, and then povray only has to render the everything in the
array...
BTW, i think that unreal script(that's what gave me the idea) is a good
example:
on my miserable(& only computer) 686/133mHZ 24MB ram no 3d card, it can
do more than 5 fps, while interpreting all the weapons that i shoot, all
the movement, all the ai(basically, the only thing that's not
interpreted in unreal is the renderer...) AND rendering the game...
IF you take a look, Unreal script is pretty much like Java, except that
you can decompile everything to its UScript source...
It'd pretty much make almost every patch useless, if you give it the
right capabilities...
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
pk wrote in message <38E666E0.4DD2693B@videotron.ca>...
>BTW, i think that unreal script(that's what gave me the idea) is a good
>example:
>on my miserable(& only computer) 686/133mHZ 24MB ram no 3d card, it can
>do more than 5 fps, while interpreting all the weapons that i shoot, all
>the movement, all the ai(basically, the only thing that's not
>interpreted in unreal is the renderer...) AND rendering the game...
By far the slowest part of the game is the renderer. Everything else
combined takes no more than about 1% of the cpu.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner wrote:
>
> pk wrote in message <38E666E0.4DD2693B@videotron.ca>...
> >BTW, i think that unreal script(that's what gave me the idea) is a good
> >example:
> >on my miserable(& only computer) 686/133mHZ 24MB ram no 3d card, it can
> >do more than 5 fps, while interpreting all the weapons that i shoot, all
> >the movement, all the ai(basically, the only thing that's not
> >interpreted in unreal is the renderer...) AND rendering the game...
>
> By far the slowest part of the game is the renderer. Everything else
> combined takes no more than about 1% of the cpu.
Well, that's the point: Uscript is NOT slow at all(it has to
interpreteverything in the game), and something like it could be used to
invent new operations, tranformation, primitives, etc, and interpret the
classes corresponding to the pov file without slowing down povray
significantly(Maybe that the POV team could ask the creators of
UnrealScript to give them the sources/parts of the source/help... 8)
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 01 Apr 2000 16:15:13 -0500, pk wrote:
>Peter J. Holzer wrote:
>>
>> On Thu, 30 Mar 2000 21:39:58 -0500, pk wrote:
[...]
>> <sphere location="12,34,56" radius="1" />
>there a > and a < missing
No, that line is correct. <tag/> is just an abbreviation of
<tag></tag>. Please see http://www.w3.org/TR/1998/REC-xml-19980210 for
details of the XML syntax.
>> >Definition language weren't made to support imbricked things/tags that
>> >work only in another tag
>>
>> It does. In HTML, for example, a <title> element can only occur inside a
>> <head> element.
>That's not what i meant, sorry...
>I meant that there isn't a tag(transformations come to mind) that work
>different way depending of the tag in which it's imbricked...
Tags don't "work" in XML. They just give structure to a document. The
meaning of the elements is completely up to the application. Besides,
transformations work quite the same regardless of where they are. They
just affect different things.
>Anyway, i'd be happier if instead of only having predefined shapes, you
>could extend the language with an interpreted language ala java, where
Interesting. There are people here who want to get rid of the
programming elements of POV-Script and others who want to turn it into a
full object-oriented programming language :-)
>there is, say:
>Primitive.Class
> |
> |-cube
> |
> |-cone
> |
> |-plane
> ...
>Where the primitive class contains everything you need to define an
>object, except the function that defines the object in itself(it parses
>everything and calls the good function in the class)
I don't see where this gives really an advantage over what you can do
with POV script. You can already define objects of any complexity and
handle them just like the primitive objects.
However, I sometimes miss the possibility do define methods which either
manipulate the object or return information about it. For example, if I
define an object "arm", I would like to write methods to set its
position in different ways (because sometimes I know where the wrist
should be and sometimes I know where the shoulder should be) and to
retrieve the position of the other pieces.
While I can write macros to do this, they are separate from the object,
which makes it difficult to keep them consistent. I think MegaPOV has
some features which make this easier.
hp
PS: Could you please quote only what is relevant to your answers? If my
newsreader didn't color quotes differently than normal text I wouldn't
even have seen that you put in one-line comments between dozens of lines
of my own text.
--
|_|_) | Sysadmin WSR \ Durchbruch in der Bionik, und Microsoft geht
| | | hjp### [at] wsracat \ Pleite und Gardena bringt organische PC's
__/ | http://www.hjp.at/ \ auf den Markt. -- Stefan Schaefer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter J. Holzer wrote:
>
> On Sat, 01 Apr 2000 16:15:13 -0500, pk wrote:
> >Peter J. Holzer wrote:
> >>
[snip]
> >> On Thu, 30 Mar 2000 21:39:58 -0500, pk wrote:
> >Anyway, i'd be happier if instead of only having predefined shapes, you
> >could extend the language with an interpreted language ala java, where
>
> Interesting. There are people here who want to get rid of the
> programming elements of POV-Script and others who want to turn it into a
> full object-oriented programming language :-)
lol
[snip]
> I don't see where this gives really an advantage over what you can do
> with POV script. You can already define objects of any complexity and
> handle them just like the primitive objects.
If you have just the bare minimum that's not interpreted, it makes
patches useless, and the reason why the pov-ray team will do other
version will NOT be because the community wants another type of light or
something like that, but because they'll want to add capabilities to the
interpreted language, or improve the interpreter ot the raytracer...
And, i think that there's a little misunderstanding: i suggest that
EVERYTHING except the raytracer(which is anyway interpreted by the cpu
8)... That way, you could change the way everything behaves...
an example:
the textured light patch. if the light was interpreted, you could just
use a function that tells you the distance from point 1 at angle x, y, z
until you reach an object, and then change the color of the light at
that angle(a micro sphere around the lightsources with a texture and
filter at 1 would be an easy solution)
> However, I sometimes miss the possibility do define methods which either
> manipulate the object or return information about it. For example, if I
> define an object "arm", I would like to write methods to set its
> position in different ways (because sometimes I know where the wrist
> should be and sometimes I know where the shoulder should be) and to
> retrieve the position of the other pieces.
Or like in this example, you could create a (not so) primitive and use
special statment for transformations... like set the position fo the
hand and of the shoulder, lenght of the arm, etc, and it calculates
everything...
> While I can write macros to do this, they are separate from the object,
> which makes it difficult to keep them consistent. I think MegaPOV has
> some features which make this easier.
Oh, and most of megaPOV could be forgotten, i think... And the argument
that every patch that works shouldn't be included in pov ray 3.5 could
be respected, while letting people use THE combination patch they want
to use...(i think that most of the patches that couldn't be done in the
language are really very important(radiosity could hardly be implemented
in the interpreted language 8)
> PS: Could you please quote only what is relevant to your answers? If my
> newsreader didn't color quotes differently than normal text I wouldn't
> even have seen that you put in one-line comments between dozens of lines
> of my own text.
Note taken 8)
--
AKA paul_virak_khuong at yahoo.com, pkhuong at deja.com, pkhuong at
crosswinds.net and pkhuong at technologist.com(list not complete)...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
