POV-Ray : Newsgroups : povray.programming : A Proposal for XML POV : Re: A Proposal for XML POV Server Time
29 Jul 2024 00:25:07 EDT (-0400)
  Re: A Proposal for XML POV  
From: pk
Date: 3 Apr 2000 22:16:45
Message: <38E95075.9B9D18F5@videotron.ca>
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

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