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

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

On Mon, 14 Aug 2000 22:49:46 +0200, Peter J. Holzer wrote:
>>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).

Or, you tesselate both spheres, ensure no triangles intersect, and perform 
the CSG operation on the resulting meshes.  If you can depend on the 
surfaces to be well-behaved, there are even shortcuts that can be taken to 
avoid testing insideness for every single vertex.

CSG is not the difficult thing to tesselate.  Things like julia objects
and infinite polys and other implicit objects are.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Or, you tesselate both spheres, ensure no triangles intersect, and perform 
: the CSG operation on the resulting meshes.

  But that would require more memory than necessary.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 21 Aug 2000 06:01:18 -0400, Warp wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: Or, you tesselate both spheres, ensure no triangles intersect, and perform 
>: the CSG operation on the resulting meshes.
>
>  But that would require more memory than necessary.

Depends on your definition of "necessary."  As I see it, the other path leads
to certain ruin.  Is it better to use lots of memory and succeed or to use
little memory and fail?

Besides, when did we start worrying about memory consumption?

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Depends on your definition of "necessary."

  Well, suppose that we have two meshes consisting of 1 million triangles
each and we make an intersection of them. In the intersection only 10
triangles are visible.
  We can:
  a) Calculate a mesh which is the resulting intersection. This mesh would
take something like 15-20 triangles.
  b) Leave the meshes be and use just regular CSG intersection.

  In the case a) we need memory for 15-20 triangles. In case b) we need
memory for 2 million triangles (1999990 of them not affecting the scene
in any way (except slowing the render)).

: Besides, when did we start worrying about memory consumption?

  It is an important issue. I think that's the reason why copying a mesh
has been optimized to take as less memory as possible :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 22 Aug 2000 05:28:40 -0400, Warp wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: Depends on your definition of "necessary."
>
>  Well, suppose that we have two meshes consisting of 1 million triangles
>each and we make an intersection of them. In the intersection only 10
>triangles are visible.
>  We can:
>  a) Calculate a mesh which is the resulting intersection. This mesh would
>take something like 15-20 triangles.
>  b) Leave the meshes be and use just regular CSG intersection.
>
>  In the case a) we need memory for 15-20 triangles. In case b) we need
>memory for 2 million triangles (1999990 of them not affecting the scene
>in any way (except slowing the render)).

Perhaps you misunderstood.  I was not talking about using regular CSG 
intersection (that would be of no use in exporting something other software
could use, after all.)  I was talking about computing the intersection of
two arbitrary but well-behaved meshes.  That is a solvable problem, and
there may even be a paper out there from someone who's solved it and/or 
optimized it.  I have solved it myself, though I've never implemented or
published the solution.  (The margins of this post, etc...)  Once you know
how to compute the intersection of two meshes, you have CSG licked.

The memory usage in this case would be that of 2 million triangles, but the
exported data would contain only the 15-20 (or 10, whatever) in the result.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message