On Fri, 11 Aug 2000 12:12:51 -0500 Chris Huff <chr### [at] maccom> wrote:

>The authors of the functions are listed in the source code, but 
>different people have written various parts of the source, and not all 
>of it is documented. I don't even know if the person who wrote the 
>original parser is still on the POV Team.

  Chris Young wrote the bulk of the parser code. He has since 'retired'.

-- 
Alan - ako### [at] povrayorg - a k o n g <at> p o v r a y <dot> o r g
http://www.povray.org - Home of the Persistence of Vision Ray Tracer

Post a reply to this message

On Fri, 11 Aug 2000 10:57:03 +0100, Neil Freebairn wrote:
>Chris Huff <chr### [at] maccom> wrote in message
>news:chrishuff-E4C9B8.09352610082000@news.povray.org...
>> In article <3992a1a5@news.povray.org>, "Neil Freebairn"
>> <nei### [at] lineonenet> wrote:
>> > Many of the features new to POV 3.1 (and perhaps some to the
>> > soon-to-be-released v3.5) bring the scene language closer to a
>> > language proper, say a 4GL.
>>
>> Uhh, "4GL"?
>
>4th generation language, which here is my shorthand for words I'm not
>familiar with to describe the kinds of features one sees in C, Pascal, etc,

These languages are usually thought of as 3rd generation languages (the
first two generations being machine code and assembler).
4GLs are high level, declarative languages which either don't have
explicit procedural constructs (like loops or ifs) or at least rarely
need them. SQL is one. Some people think the unix shell is one. Indeed
we could think of PovScript as a 4GL (we don't tell the engine how to
render the scene, we just describe the scene and tell it to render at
some specific resolution).

I think 4GLs went somewhat out of fashion with the OO hype.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

On Fri, 11 Aug 2000 17:18:36 +0100, Neil Freebairn wrote:
>
>Chris Huff <chr### [at] maccom> wrote in message
>news:chrishuff-2701B4.09084811082000@news.povray.org...
>> In article <3993ce85@news.povray.org>, "Neil Freebairn"
>> The text that created an object is not associated with the identifier,
>> only the object data itself is. You would have to write out code
>> representing the current state of the object, so it *would* be a
>> conversion function.
>> It might be possible to save the string that produced the object, but I
>> have no idea how to do that.
>>
>
>I don't know very much about language parsing, but I'm guessing it works a
>bit like this.
>
>In parsing a declarative, the POV-Ray parser encounters '#declare' (or
>'#local'), stores the identifier 'MyObj', looks for the equals, then reads
>everything after the equals until the end is flagged (various conditions
>apply). At this point, if we could save this string - the right-hand side of
>the equals - against this identifier for returning using our function, we'd
>be home and dry.

I don't think so. I haven't looked at the Pov parser in detail, but from
what I have seen, it's a typical tokenizing recursive descent parser. It
always only keeps the current "token" (an identifier, operator, string,
...) as a string (plus some buffer for performance reasons). After it
has recogized the token, its string representation is discarded and it
is either converted to some internal format or only used to decide what
to do next.

So, when the final '}' of an object declaration is reached, there is
nowhere in memory a complete string representation of the object. There
probably isn't a logical place where it could have been saved, cause the
parsing threaded its way through a dozen or more different functions,
each only handling a small part of the input. 

You have, however, the complete internal represenation of the object
(some kind of tree structure) and it should be possible to dump that
in any format you want. There is already a patch for povray which does
something like this: After parsing the whole scene, it just dumps it in
some binary format (called POB I think) to a file.
To dump in PovScript or give PovScript the ability to access a string
representation of its own objects, it would just have to be changed to
produce PovScript instead of the binary representation. A simple but
rather boring coding exercise, IMHO.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote in message
news:chrishuff-F96918.12125111082000@news.povray.org...


> > Since everything including declaratives has to be achieved through the
> > execution of commands for which there always has to be a code string
> > representation, so long as we capture all such declaratives, we should
> > capture all such changes to an object's state.
>
> Would this be very useful? You would basically have to re-parse the
> whole thing, including identifiers, transformations, etc, only in
> POV-Script. I think it would be more useful to have the actual object
> data be translated into a string, as well as more efficent in use of
> memory and simpler. So "sphere {< 3, 5*2, 8>, Rad*0.5}" with Rad==2
> would be translated to "sphere{<3,10,8>,1 texture{...}interior{...}",
> with object flags and other additional data also being included.
> Transforms would be output as matrices. This would be much easier to
> parse within POV-Script itself for writing to another file format.
> Another use of this feature would be include files and macros which
> output a large number of objects...you could save the objects in an
> include to save calculation time.

As I see it, the difficulty in converting POV-Ray files to other common 3D
file formats is that POVScript dynamically generates a (static)
representation of the scene, whereas these other formats employ static
representations 'from the start', i.e. with POVScript you don't know what
you've drawn until you've drawn it, to paraphrase somebody famous (E.M.
Forster?). If so, we'll need (at least) 2 'interpretive passes' to convert
the POVScript to another representation, (at least) one to determine what we
end up with, and (at least) one to convert the resulting static
representation to another format. Because I'm not familiar with C, and
because I'd like to develop and use the tool soon, I'm trying to achieve
this, quick 'n' dirty, using PovScript itself plus whatever utilities I can
find to help implement a solution. The approach I've adopted uses Thomas
Baier's POB SDK, which, in v0.9, the latest incarnation I've been able to
find, can handle everything but macros and conditional directives. My
short-term goal has therefore been to create a tool which translates
POVScript 3.1 code into a version of POVScript parseable by POB SDK v0.9.
The process I've developed parses the original POVScript 3.1 files
(including all .inc files referred to) to create an intermediary POVScript
3.1 file that then creates a final POVScript 3.1 file that generates exactly
the same 3D scene and rendered output as the original, but has employs no
macros or conditional directives.

My desire to do this is to help both myself and a dozen or so other people
out there who through news.povray.org, c.g.r.r and other places have been
searching for the same tool, and to strengthen POV-Ray's integration with
other great 3D applications and utilities. There are no doubt better ways,
and my hope is that by developing the process, a way of integrating a file
format conversion utility such as the POB-SDK into POV-Ray more closely may
be found.

Neil

Post a reply to this message

Peter J. Holzer <hjp### [at] SiKituwsracat> wrote in message
news:slr### [at] tealhhjpat...
> On Fri, 11 Aug 2000 17:18:36 +0100, Neil Freebairn wrote:
> >In parsing a declarative, the POV-Ray parser encounters '#declare' (or
> >'#local'), stores the identifier 'MyObj', looks for the equals, then
reads
> >everything after the equals until the end is flagged (various conditions
> >apply). At this point, if we could save this string - the right-hand side
of
> >the equals - against this identifier for returning using our function,
we'd
> >be home and dry.
>
> I don't think so. I haven't looked at the Pov parser in detail, but from
> what I have seen, it's a typical tokenizing recursive descent parser. It
> always only keeps the current "token" (an identifier, operator, string,
> ...) as a string (plus some buffer for performance reasons). After it
> has recogized the token, its string representation is discarded and it
> is either converted to some internal format or only used to decide what
> to do next.
>
> So, when the final '}' of an object declaration is reached, there is
> nowhere in memory a complete string representation of the object.

I wasn't terribly clear about this, but, since I only needed to refer to the
basic functions of the process, my description of POV's parser was meant to
describe only the essential black boxes, and therefore to be in some sense
sufficiently abstract to be guaranteed to be correct. 'At this point' would
better be said "at these points [i.e. when we have pieces of a longer string
that we recognise as tokens or not]".

> There
> probably isn't a logical place where it could have been saved, cause the
> parsing threaded its way through a dozen or more different functions,
> each only handling a small part of the input.

But that isn't to say that these functions couldn't concatenate their small
bits of parsing input back into the complete 'original' string.

> You have, however, the complete internal represenation of the object
> (some kind of tree structure) and it should be possible to dump that
> in any format you want. There is already a patch for povray which does
> something like this: After parsing the whole scene, it just dumps it in
> some binary format (called POB I think) to a file.

With one exception, everything I've read suggests that the existing POB SDK
cannot parse macros. Thomas Baier, the author, says it can be done, but I
suspect (in the absence of very much information from him) he means the same
as you: the converter is there, it just needs to be integrated. It's the
integration that I am trying to achieve through a quick'n'dirty route.

> To dump in PovScript or give PovScript the ability to access a string
> representation of its own objects, it would just have to be changed to
> produce PovScript instead of the binary representation.
> A simple but rather boring coding exercise, IMHO.

As I had hoped! I was hoping that enthusiasm for the result - a pathway from
POV-Ray to all the other great 3D apps and utilities out there - might
provide the motivation...

If not, perhaps you could describe in some detail what would need to be
done.

Neil

Post a reply to this message

On Sun, 13 Aug 2000 22:18:17 +0100, Neil Freebairn wrote:
>
>Peter J. Holzer <hjp### [at] SiKituwsracat> wrote in message
>news:slr### [at] tealhhjpat...
>> There probably isn't a logical place where it could have been saved,
>> cause the parsing threaded its way through a dozen or more different
>> functions, each only handling a small part of the input.
>
>But that isn't to say that these functions couldn't concatenate their
>small bits of parsing input back into the complete 'original' string.

Yes, they could. but it probably means lots of little changes scattered
all over the source code. Also I don't think this is "the right way to
do it".

>> You have, however, the complete internal represenation of the object
>> (some kind of tree structure) and it should be possible to dump that
>> in any format you want. There is already a patch for povray which
>> does something like this: After parsing the whole scene, it just
>> dumps it in some binary format (called POB I think) to a file.
>
>With one exception, everything I've read suggests that the existing POB
>SDK cannot parse macros.

As far as I know (please correct me if I'm wrong), the POB SDK cannot
parse any PovScript. It can only parse POB files. To convert PovScript
into POB, you use a specially patched version of Povray, which dumps the
internal scene representation to a POB file. At this point, macros don't
exist any more, so they aren't a problem.

But the patches at Thomas' site are for Povray 3.0. Obviously, you
cannot use Povray 3.0 to parse a file which uses features (like macros
or media) which were only introduced in Povray 3.1. You would have to
port the patches to version 3.1. To do this you need to know C.


>> To dump in PovScript or give PovScript the ability to access a string
>> representation of its own objects, it would just have to be changed
>> to produce PovScript instead of the binary representation. A simple
>> but rather boring coding exercise, IMHO.
>
>As I had hoped! I was hoping that enthusiasm for the result - a pathway
>from POV-Ray to all the other great 3D apps and utilities out there -
>might provide the motivation...

I tried to convert a model of mine to some other format about a year
ago. It was still a povray 3.0 scene, so i could use POB. However, I
found that wasn't any help. The problem with converting PovScript to
almost any other format is those formats can only handle surfaces, not
bodies. This means that you cannot convert something as simple as

    difference {
	sphere { <0,0,0>, 1 }
	sphere [ <0,1,0>, 0.5 }
    }

into those format by simple text conversion. You have to compute where
the two spheres meet and replace the two sphere parts (what's "Kalotte"
in English? - calotte seems to be some kind of hat) by equivalent bezier
patches, or nurbs, or a bunch of triangles. I think there is even a
(low quality) macro for this, but it needs MegaPOV.

Apart from that, writing a PovScript-to-Povscript converter in C and
then a PovScript-to-SomethingElse converter in PovScript seems to me to
be about the most roundabout way to do this. Kind of like implementing a
Basic Interpreter in TeX, or a calculator with sendmail macros. 

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

In article <slr### [at] tealhhjpat>, 
hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:

> (what's "Kalotte" in English? - calotte seems to be some kind of hat)

Well, what does it mean?


> I think there is even a (low quality) macro for this, but it needs 
> MegaPOV.

Tesselating a sphere is pretty easy, and wouldn't require MegaPOV. I 
think the macro you are referring to is one which uses trace() to scan 
the surface of an object, it can tesselate almost any object, but 
doesn't always give great results.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

On Mon, 14 Aug 2000 10:55:41 -0500, Chris Huff wrote:
>In article <slr### [at] tealhhjpat>, 
>hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:
>
>> (what's "Kalotte" in English? - calotte seems to be some kind of hat)
>
>Well, what does it mean?

    intersection {
	sphere { ... }
	plane { ... }
    }

:-)


>> I think there is even a (low quality) macro for this, but it needs 
>> MegaPOV.
>
>Tesselating a sphere is pretty easy, and wouldn't require MegaPOV.

Yes. But even for such a simple CSG as in the example I gave (difference
of two spheres) it isn't that simple any more. There are already three
cases:
1) The spheres don't intersect at all (easy - just tesselate the first one)
2) The second is completely inside the first (also easy - tesselate both
   but invert the normals of the second).
3) Their surfaces intersect (a bit more complicated - you have to
    compute the circle where they intersect, then tesselate two partial
    spheres).

Now think of a CSG composed of an arbitrary number of objects. Coding
all possible combinations would be clearly infeasible. 

>I think the macro you are referring to is one which uses trace() to
>scan the surface of an object, it can tesselate almost any object, but
>doesn't always give great results.

Yup. Finding the best points for the triangles isn't trivial. I haven't
looked at the macro yet, but I'd guess that it uses a rather simple
algorithm.

	hp


-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

In article <slr### [at] tealhhjpat>, 
hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:

> >Well, what does it mean?
> 
>     intersection {
> 	sphere { ... }
> 	plane { ... }
>     }

Indenting from the right side? Interesting...
A half-sphere is a hemisphere...there may be a separate term for cases 
where the plane surface doesn't pass through the center of the sphere.


> Now think of a CSG composed of an arbitrary number of objects. Coding
> all possible combinations would be clearly infeasible. 

CSG is probably the biggest problem with tesselation...once you get past 
the memory use, that is. :-)

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Thomas Baier believes there are some people who are extending his POB SDK so
it can deal with POV Script 3.1, but he doesn't know who...Anyone heard
anything?

Neil

Post a reply to this message