"Chris B" <c_b### [at] btconnectcom> wrote:

> It is already possible to use VRML to describe a scene (not a POVRay scene).
> VRML has been about since about 1994.
> There is a project working to convert it to an XML base (xVRML) as it was
> originaly based on SGML principles. In fact I think they released an XML
> schema for it way back in 2003.

yes
and the xVRML Project has mad significant strides
since this note was posted...

see:  http://www.xvrml.net/

the spec sections for static scene elements are almost completed
and the sections for dynamics come next

an initial tech-demo viewer application is avail through the above URI

> I think there are probably lots of people on the VRML news groups and in the
> xVRML community that are interested in such a system.

I would agree

> I myself took a brief interest in this before discovering POVRay.

interesting the paths we all follow...
I took the opposite route
shifting my energy from PoV to VRML in 1994
and these past couple of years
focusing on developing an XML-based VR language (xVRML)

> put me off VRML (and the concept of using tagged markup languages for scene
> description in general) is the enourmously verbose manner used to describe
> an object.
> As has already been mentioned, POVRays Scene Description Language provides a
> highly elegant and concise yet flexible way to describe objects.

IMHO: PoV and other static-image-oriented systems
have different target domains and audiences than web-based VR
so I think of this as comparing apples and doughnuts

Constructivist approaches in education include
structuring lessons to "build on prior knowledge"
and we are trying to apply that lesson to xVRML

anyone who can understand HTML code
can learn to understand xVRML in a **very** brief time
because it is deliberately structured to take advantage of
existing understanding of HTML and other tag-based markup languages
already held by new content creators

I have been testing this out this Quarter
at the college where I teach...
I am teaching the same "intro to vr" class
which I have taught for five years now...
the students seem to have
about the same base of prior knowledge as always
and are about as smart as always
and yet this term
I switched to using the current (beta) xVRML version
and to using the current (alpha) tech-demo viewer app ("Carina")
and suddenly I have a class going through the material
at literally twice the rate that classes have done
so over the past 5 years
so I feel there is at least preliminary/anecdotal evidence
that this approach is working effectively

> scenes, and even then I've never seen any VRML scenes that come close to the
> sophistication of some of the newbie POVRay scenes posted on the povray
> newsgroups.

but of course...
the PoV newbies are working to create things which
consist of one rendered frame at a time
and which is not necessarily going to be
downloaded off of the web
while VR scene newbies are working to create things which
people can "fly through" at a decent multi-framerate
and which *are* necessarily going to be
accessed over the Web

different targets and domains

IMHO a lot of people who want to generate
photorealistic raytraced stills
and slowly-constructed animations
can also find a lot of interesting things to do
with lightweight 3D VR
rapidly obtained from the Web
and rapidly rendered as a just-in-time
animation under the control of the user

jeffs
http://www.xvrml.net/

Post a reply to this message

ABX <abx### [at] abxartpl> wrote:

> Obviously POV-Ray SDL is not perfect tool but also obviously it is a lot of
> power already and I very often choose it as simple scripting tool for series
> of simple operations. For example in samples there is a portfolio which easily
> outputs html files with all images rendered. But adding "cool" programming
> features just because they are "cool" is questionable. In spite of all POV-Ray
> is a renderer so let's concentrate on rendering features: types of objects,
> cameras, lights, build-in patterns, antialiasing, HDRI, splines, visual
> effects, radiosity etc, etc. There is so much to do around such features that
> making programming "cool" if you probably have already your favourite
> programming language which you can easily adopt to preparing SDL file is
> wasting of man power (IMO).
>
> ABX


I completly agree, POV-Ray shouldn't become an advanced programming language
like C++ or Java, but it should offer POV-artists a much more easier way of
making complex and realistic scenes. I think concentrating on that is the
only way of making POV more efficient.

I don't want to have to learn C++ before using POV, because POV is good as
it is now, the only thing i want is an easier way to make my scenes look
good. Making the language more complex isn't going to help anyone who's not
interested in the technological details, but wants to make a nice scene.

POV's got enough handy programming-features that i use to make my work
easier (like macro's, loops and defining variables and objects), they're
not to hard to understand and i'd like to keep it that way.

Post a reply to this message

iceqb <nomail@nomail> wrote:
> I completly agree, POV-Ray shouldn't become an advanced programming language
> like C++ or Java, but it should offer POV-artists a much more easier way of
> making complex and realistic scenes.

  One could argue that those two things are actually the same thing.

> I don't want to have to learn C++ before using POV

  A fully-featured object-oriented language does not automatically mean
that you *must* learn *all* the intrinsic complicated details of the
language in order to create scenes. I have always wondered why so many
people seem to think like it does.

  Let me present a comparison, using Windows:

  Does a regular user, who just wants to surf the net and read his email,
have to learn how to edit the Windows registry?
  The answer is naturally: No.

  Is it *bad* that Windows includes the means to edit the registry?
  Of course not. Those who want to edit it can do so. Is that bad?

  The fact that a feature *exists* does not mean that you *must* even
know about its existence in order to use the program.

  If fully object-oriented features are added to the scene description
language, so what? It doesn't necessarily mean that you must learn to
use them in order to create scenes.

  You have to realize that there are two kinds of POV-Ray users: Artists
and developers.
  The idea with enhancing the language is that developers have better
better tools to create easy-to-use libraries for the artists to use.

  Wouldn't you like it if you could just write 'import("scene.3ds")' and
magically the 3ds file is imported and rendered?
  If the SDL is enhanced enough and if some developer creates such a
library, then you can do exactly that, ie. import 3D-Studio files with
a one-liner (without even having to know that something called
"object-oriented programming" even exists).

  So I more or less completely disagree with you: POV-Ray *needs* and
would greatly benefit from a fully-featured programming language.

-- 

                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> iceqb <nomail@nomail> wrote:
> > I completly agree, POV-Ray shouldn't become an advanced programming language
> > like C++ or Java, but it should offer POV-artists a much more easier way of
> > making complex and realistic scenes.
>
>   One could argue that those two things are actually the same thing.
>
> > I don't want to have to learn C++ before using POV
>
>   A fully-featured object-oriented language does not automatically mean
> that you *must* learn *all* the intrinsic complicated details of the
> language in order to create scenes. I have always wondered why so many
> people seem to think like it does.
>
>   Let me present a comparison, using Windows:
>
>   Does a regular user, who just wants to surf the net and read his email,
> have to learn how to edit the Windows registry?
>   The answer is naturally: No.
>
>   Is it *bad* that Windows includes the means to edit the registry?
>   Of course not. Those who want to edit it can do so. Is that bad?

OK, I agree, but what if you have to deal with it once, just once, and you
haven't got a clue what to do, you could seriously damage your system.
So a little knowledge is always easy.

>   The fact that a feature *exists* does not mean that you *must* even
> know about its existence in order to use the program.

No, I don't know POV-Ray SDL inside-out to, but now, if I have to make
something that isn't done by anyone else, it's at least understandable,
and i don't have to code too large amounts of code for it. You're gonna get
confronted with the ins and outs of the code one day.

>
>   If fully object-oriented features are added to the scene description
> language, so what? It doesn't necessarily mean that you must learn to
> use them in order to create scenes.
>
>   You have to realize that there are two kinds of POV-Ray users: Artists
> and developers.
>   The idea with enhancing the language is that developers have better
> better tools to create easy-to-use libraries for the artists to use.
>
>   Wouldn't you like it if you could just write 'import("scene.3ds")' and
> magically the 3ds file is imported and rendered?
>   If the SDL is enhanced enough and if some developer creates such a
> library, then you can do exactly that, ie. import 3D-Studio files with
> a one-liner (without even having to know that something called
> "object-oriented programming" even exists).

If you're gonna make SDL an object-oriented language, you have to be
prepared
to start from scratch, because the current implementation isn't even close
to
that ideal. That means a new syntaxis with classes, structs, ... which
inevitably means relearning the whole deal!

Here's an other objection to extending SDL : security. With more
implementations
on file I/O in the SDL, it would be possible to overwrite crucial
systemfiles
(on Windows, doubtably on Linux), and corrupt the entire system. (thinking
virus or trojan!)

Another thing, what if you do rewrite SDL, and you do, as you say develop
libraries for artists, that means double shifts, wright because you can't
release it before the libraries, or no artist would understand it. (I might
be willing to learn, others won't)

>   So I more or less completely disagree with you: POV-Ray *needs* and
> would greatly benefit from a fully-featured programming language.

Post a reply to this message

iceqb <nomail@nomail> wrote:
> If you're gonna make SDL an object-oriented language, you have to be
> prepared
> to start from scratch, because the current implementation isn't even close
> to
> that ideal. That means a new syntaxis with classes, structs, ... which
> inevitably means relearning the whole deal!

  There's no reason why the new SDL could not resemble the current one.
  Some small changes may be necessary, but it shouldn't be something
unsurmountable. Besides, a compatibility import-mode for old SDL code
is also possible.

> Here's an other objection to extending SDL : security. With more
> implementations
> on file I/O in the SDL, it would be possible to overwrite crucial
> systemfiles
> (on Windows, doubtably on Linux), and corrupt the entire system. (thinking
> virus or trojan!)

  You can already do that with the current SDL (assuming you haven't
configured the file restrictions correctly), so what's the big deal?

> Another thing, what if you do rewrite SDL, and you do, as you say develop
> libraries for artists, that means double shifts, wright because you can't
> release it before the libraries, or no artist would understand it. (I might
> be willing to learn, others won't)

  You don't need libraries to create the basic scenes you can already
create with the current SDL. Just some small syntactical changes would
need to be learnt.

-- 

                                                          - Warp

Post a reply to this message

iceqb wrote:
> on file I/O in the SDL, it would be possible to overwrite crucial
> systemfiles (on Windows, doubtably on Linux), 

Windows has as many, if not more, restrictions on overwriting crucial 
system files than Linux does. Linux has only the permission system to 
restrict it. Windows has System Recovery to fix it and the backup DLL 
directory that automatically fixes it as soon as you change one.

-- 
   Darren New / San Diego, CA, USA (PST)
     The samba was clearly inspired
     by the margarita.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

>   You don't need libraries to create the basic scenes you can already
> create with the current SDL. Just some small syntactical changes would
> need to be learnt.

I didn't look at it that way, i must admit. But if you're working with this
syntaxis day in day out, you eventually have to deal with the small anoying
stuff that come along with it. Not everything is premade somewhere, by some
programmer. You're gonna have to be able to write it yourself at some
point.

But if you're willing to learn, i think a new and improved SDL is quite
powerfull, but it just takes some more time to learn.

PS: Sorry for late responses, limited access to internet. :)

Post a reply to this message

HELLO. i am late but i am here.

the idea of an POV-XML, i think is to take control of the scene for
multiples reasons, enginering aplications, etc. Of course the pov syntax
will be the same for every one. Why not think about an universal language
for the 3d world like X3D. I never saw the x3d specification but the
philosophy i think is ok.

Post a reply to this message

raynmune thelord wrote:
> HELLO. i am late but i am here.
> 
> the idea of an POV-XML, i think is to take control of the scene for
> multiples reasons, enginering aplications, etc. Of course the pov syntax
> will be the same for every one. Why not think about an universal language
> for the 3d world like X3D. I never saw the x3d specification but the
> philosophy i think is ok.
> 

When will people understand that XML, and all derivatives, is
*DOCUMENT* oriented ? Not processing oriented !
If you are ready to drop all the algorithms from Pov SDL, then yes,
please go on and go back to DBKTrace 2.12...
It was a time were you had to write in C (or whatever) a code that
would generate the thousands sphere statement needed to make that
nice sea-shell...

I means, no #local, no #declare, not only of scalar, but also of
object, texture, and so!
No loop, no conditional statement...
I'm not even sure about animation...

Also, #include in XML are a PITA to perform, until you have a
portable network architecture for a valued-added repository.

I do not mind about an XML/X3D OUTPUT for povray (once the scene has
been parsed, just add the method to output that to a stream...), but
parsing... No Thanks. And for the output, I hope you have some
Multi-Tera-bytes drives availables.
(Do not talk about "compressed" XML/X3D... if you really want
compressed syntax, let's use the best one: PER-ASN.1, unaligned!
that's one is impressive, opened, but analysis by hand might take
you about two hours for a line once you're an expert of it...)

Last, about Universal 3D... there is no universal 3D usage... and 3D
 must be optimised, otherwise the volume of data is far too big.
Can you draw the conclusion by yourself ?

-- 
Eifersucht ist die Leidenschaft, die mit Eifer sucht, was Leiden
schafft.

Eco: -8.75 Soc: -6.72
http://www.politicalcompass.org/

Post a reply to this message

raynmune thelord wrote:
> HELLO. i am late but i am here.
> 
> the idea of an POV-XML, i think is to take control of the scene for
> multiples reasons, enginering aplications, etc. Of course the pov syntax
> will be the same for every one. Why not think about an universal language
> for the 3d world like X3D. I never saw the x3d specification but the
> philosophy i think is ok.
> 
> 

It should be no problem to write a xsl transformation that makes
POV-Ray code out of some xml scene description.

Post a reply to this message