POV-Ray : Newsgroups : povray.general : The Language of POV-Ray Server Time
11 Aug 2024 15:13:01 EDT (-0400)
  The Language of POV-Ray (Message 161 to 170 of 297)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Ken
Subject: Re: The Language of POV-Ray
Date: 13 Mar 2000 07:10:04
Message: <38CCDB20.20D7E702@pacbell.net>
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

From: Chris Huff
Subject: Re: The Language of POV-Ray
Date: 13 Mar 2000 07:14:58
Message: <chrishuff_99-753500.07165013032000@news.povray.org>
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

From: Nigel Stewart
Subject: Re: The Language of POV-Ray
Date: 13 Mar 2000 07:28:10
Message: <38CCDE85.7E3C424@nigels.com>
> 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

From: Nigel Stewart
Subject: Re: The Language of POV-Ray
Date: 13 Mar 2000 07:32:58
Message: <38CCDFAA.8DAF3F78@nigels.com>
> > 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

From: Gilles Tran
Subject: Re: The Language of POV-Ray
Date: 13 Mar 2000 07:39:43
Message: <38CCE1C6.275E2B13@inapg.inra.fr>
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

From: Chris Huff
Subject: Re: The Language of POV-Ray
Date: 13 Mar 2000 07:51:08
Message: <chrishuff_99-43F11D.07525913032000@news.povray.org>
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

From: Chris Huff
Subject: Re: The Language of POV-Ray
Date: 13 Mar 2000 07:52:40
Message: <chrishuff_99-CC14D9.07543213032000@news.povray.org>
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

From: Nigel Stewart
Subject: Re: The Language of POV-Ray
Date: 13 Mar 2000 08:51:43
Message: <38CCF223.EE4E8A91@nigels.com>
> >   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

From: TonyB
Subject: Re: The Language of POV-Ray
Date: 13 Mar 2000 09:02:47
Message: <38ccf507@news.povray.org>
<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

From: Ken
Subject: Re: The Language of POV-Ray
Date: 13 Mar 2000 09:08:02
Message: <38CCF6C9.1D9BA5A4@pacbell.net>
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

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.