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:
>
> > My solution is coded entirely in POV 3.1 scene language, because it's
> > quick to prototype, I hoped I might get all the way, and I don't know
> > any C++.
>
> You seem to be under the impression that POV is written in C++...it is
> written in plain old C, though a rewrite in C++ is planned for 4.0. And
> adding a function is usually quite easy...one of the easiest things to
> do.

Great, and apologies for C / C++ mistake. (D'Oh.)


> > 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,
and which weren't in POV3.0, but have started to appear in 3.1, such as
macros.

> > A function that would be useful in this regard, independent of my
> > requirement, is this 'makestr(ANY_IDENTIFIER)' function that works
> > like str(FLOAT_IDENTIFIER).
>
> The str() function converts a float to a string...how would you convert
> a shape to a string? Would you just have it return POV-Script
> representing the object? Or return the code that generated the object in
> the first place?

All I need is a function that returns the 'value' of an identifier as a
string that could be used to create a variable of identical value through a
declarative  statement, #declare, #local, $ or % - the text string used in
the original declarative should be perfect. :-) So the string will be
something like
"1.4"
"hello world"
"object { ... }"
"texture { ... }"
"pigment { ... }"

depending on variable type.

If this text is already (or could be) held in memory against the identifier,
the function should be straightforward to code - just write it out, no need
to even worry about types. I suggested it was a conversion function, but
that's incorrect.

> > Are you familiar with the POV source and C++, by any chance?
>
> I am familiar with both, not that they have much to do with each other
> at this point. :-)

Ok. (D'oh!)
If it wouldn't take too long, I think it might anyway be a valuable addition
to POV's functionality for debugging as the scene language gets more and
more sophisticated.

:-)

> 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

In article <3993ce85@news.povray.org>, "Neil Freebairn" 
<nei### [at] lineonenet> wrote:

> 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, and which weren't in POV3.0, but have started to appear 
> in 3.1, such as macros.

Ah, I see...I had seen that acronym before, but couldn't remember what 
it meant.
We have "functions"(macros, which do not behave like C macros, and 
iso-functions, which can only handle scalars and do not have 
conditionals), now we just need "pointers"(or "references", depending on 
your favorite language...not simply C pointers) and structs or 
classes(the objects could be used for this, just attach macros and 
variables to them).


> If this text is already (or could be) held in memory against the 
> identifier, the function should be straightforward to code - just 
> write it out, no need to even worry about types. I suggested it was a 
> conversion function, but that's incorrect.

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.


> Ok. (D'oh!)
> If it wouldn't take too long, I think it might anyway be a valuable 
> addition to POV's functionality for debugging as the scene language 
> gets more and more sophisticated.

-- 
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

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.

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.

I should probably talk to the author(s) of the parser. Can you tell me who
that is?

Neil

Post a reply to this message

In article <39942cce@news.povray.org>, "Neil Freebairn" 
<nei### [at] lineonenet> 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 think the scene file is broken into tokens first, however, I really 
don't understand the POV parser. This could make recovering the string a 
bit more difficult, though probably not impossible.


> 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.


> I should probably talk to the author(s) of the parser. Can you tell me 
> who that is?

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.

-- 
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

Chris Huff 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.

Most of the current authors however do monitor this group so if
they have anything to contribute, or if you pique their interest,
they will generally jump in and say something.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

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