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