Since there appears to be no utility for converting from POV-Ray 3.1 scene
language to other formats, I have been thinking about how to solve it myself
and I have 99% of a solution. The remaining 1% is a function that returns
the referent of any identifier, no matter what type - string, float,
pigment, texture, array etc - as a text string. str(FLOAT_IDENTIFIER) does
this job for floats. I need stranytype(ANY_IDENTIFIER).

Since more and more organisations, especially those outside the media and
manufacturing spaces, are beginning to recognise the benefits of modelling,
visualisation, and prototyping, script-based modelling of the sort that
POV-Ray does excellently on its own, is going to be more and more important.
I'd love to contribute to a long and happy life for this fine application.

My guess is that, for C++ guru familiar with the POV-Ray source, this should
be pretty straightforward.

Any takers?

Neil

Post a reply to this message

> Since there appears to be no utility for converting from POV-Ray 3.1 scene
> language to other formats, I have been thinking about how to solve it myself
> and I have 99% of a solution. The remaining 1% is a function that returns
> the referent of any identifier, no matter what type - string, float,
> pigment, texture, array etc - as a text string. str(FLOAT_IDENTIFIER) does
> this job for floats. I need stranytype(ANY_IDENTIFIER).
> 
> Since more and more organisations, especially those outside the media and
> manufacturing spaces, are beginning to recognise the benefits of modelling,
> visualisation, and prototyping, script-based modelling of the sort that
> POV-Ray does excellently on its own, is going to be more and more important.
> I'd love to contribute to a long and happy life for this fine application.
> 
> My guess is that, for C++ guru familiar with the POV-Ray source, this should
> be pretty straightforward.

Well it should be fairly easy to convert about anything into a string...

But if you developped such an utility, why are you unable to create the
conversion yourself?
I mean, it would be fairly easy for you to do it since you know your code, and
it would be difficult for me to do it since I don't know your code at all...

Simon

Post a reply to this message

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++. I
can't see how to code the function from the scene language (although it did
give it some thought). There's no reason why, once I've proved the concept,
it could not *very* easily be coded in C++ and built in to a later release
of POV. 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. 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).

Are you familiar with the POV source and C++, by any chance?

Simon Lemieux <lem### [at] yahoocom> wrote in message
news:39928D21.350E781E@yahoo.com...
> > Since there appears to be no utility for converting from POV-Ray 3.1
scene
> > language to other formats, I have been thinking about how to solve it
myself
> > and I have 99% of a solution. The remaining 1% is a function that
returns
> > the referent of any identifier, no matter what type - string, float,
> > pigment, texture, array etc - as a text string. str(FLOAT_IDENTIFIER)
does
> > this job for floats. I need stranytype(ANY_IDENTIFIER).
> >
> > Since more and more organisations, especially those outside the media
and
> > manufacturing spaces, are beginning to recognise the benefits of
modelling,
> > visualisation, and prototyping, script-based modelling of the sort that
> > POV-Ray does excellently on its own, is going to be more and more
important.
> > I'd love to contribute to a long and happy life for this fine
application.
> >
> > My guess is that, for C++ guru familiar with the POV-Ray source, this
should
> > be pretty straightforward.
>
> Well it should be fairly easy to convert about anything into a string...
>
> But if you developped such an utility, why are you unable to create the
> conversion yourself?
> I mean, it would be fairly easy for you to do it since you know your code,
and
> it would be difficult for me to do it since I don't know your code at
all...
>
> Simon

Post a reply to this message

> 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++. I
> can't see how to code the function from the scene language (although it did
> give it some thought). There's no reason why, once I've proved the concept,
> it could not *very* easily be coded in C++ and built in to a later release
> of POV. 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. 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).
> 
> Are you familiar with the POV source and C++, by any chance?

I am familiar with C++ and POV script, but not POV's source...  Can't help you
with that... Sorry...

Simon

Post a reply to this message

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.


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


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


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

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