It should be possible to convert a POV csg to a mesh with Ron Parker's
Superpatch.  I am working on it right now, but you may be able to roll
your own faster.  The basic idea is to use object_bounds to put a box
around the object, then iterate around that box using trace() to pick
off points of the object, then use any suitable triangulating algo on
the point set.  If the object is complex, you may want to use additional
planes at other angles, using the bounding box to ensure that you are
far enough away.

Jerry Anning
cle### [at] dholcom

Post a reply to this message

Remco de Korte <rem### [at] xs4allnl> wrote:
: I'm afraid I'm asking for the impossible, but is there some way you can convert
: a POV-object (CSG, blob) to a mesh? In theory I think it should be possible,
: perhaps the pvengine does something like this

  It's lamentably common that people do not distinguish between how raytracing
and scanline rendering work. Since scanline rendering is much more popular
(thanx to programs like 3DStudio), many people think that _every_ rendering
program work like those, ie. that they just make a triangle mesh with each
object and scanline-render them.
  This can be clearly seen when people ask questions like "will povray
rendering speed increase if I buy a 3D-card?" or with statements like
"actually a sphere is a polygon mesh with very small phong-shaded triangles"
which I once had to correct.
  Since many people have always worked with scanline-renderers and are very
accustomed to them, they think that every renderer work the same way.

  In povray, and I think that in every raytracer, spheres are spheres, not
polygon meshes. They are true mathematical, perfect spheres. And this applies
to almost every primitive (except for primitives like bezier patch or
heightfield).
  CSG's are mathematically calculated, not approximated with polygons.

-- 
                                                           - Warp. -

Post a reply to this message

Nieminen Mika wrote:
> 
> Remco de Korte <rem### [at] xs4allnl> wrote:
> : I'm afraid I'm asking for the impossible, but is there some way you can convert
> : a POV-object (CSG, blob) to a mesh? In theory I think it should be possible,
> : perhaps the pvengine does something like this
> 
>   It's lamentably common that people do not distinguish between how raytracing
> and scanline rendering work. Since scanline rendering is much more popular
> (thanx to programs like 3DStudio), many people think that _every_ rendering
> program work like those, ie. that they just make a triangle mesh with each
> object and scanline-render them.
>   This can be clearly seen when people ask questions like "will povray
> rendering speed increase if I buy a 3D-card?" or with statements like
> "actually a sphere is a polygon mesh with very small phong-shaded triangles"
> which I once had to correct.
>   Since many people have always worked with scanline-renderers and are very
> accustomed to them, they think that every renderer work the same way.
> 
>   In povray, and I think that in every raytracer, spheres are spheres, not
> polygon meshes. They are true mathematical, perfect spheres. And this applies
> to almost every primitive (except for primitives like bezier patch or
> heightfield).
>   CSG's are mathematically calculated, not approximated with polygons.
> 
> --
>                                                            - Warp. -

So, what do you want to say by this? How does this answer my question?
I've never used any of your 'scanline-renderers', I'm just trying to figure out
some things. I have a POV-model consisting of some spheres and blobs and all and
I want to do some warping or morphing on this. For that I'd like to have it in a
mesh-form, because they are easy to morph. 
I think you're making some unjustified assumptions.

Remco

Post a reply to this message

This is a good idea, but it will probably not work perfectly, because of
multiple intersections with trace (how do you ensure that you'll get all
of them?).  Also, you will run into problems with sharp edges getting
rounded because a sample ray doesn't hit them directly.

I know that Polyray (another very good ray-tracer) has the ability to
convert primatives into wireframe (in fact, it also does scan-line
rendering).  I think that this would be a very good thing to add to
POV-Ray, since it would facilitate non-linear transformations (among
other things).

-Nathan Kopp

Jerry Anning wrote:
> 
> It should be possible to convert a POV csg to a mesh with Ron Parker's
> Superpatch.  I am working on it right now, but you may be able to roll
> your own faster.  The basic idea is to use object_bounds to put a box
> around the object, then iterate around that box using trace() to pick
> off points of the object, then use any suitable triangulating algo on
> the point set.  If the object is complex, you may want to use additional
> planes at other angles, using the bounding box to ensure that you are
> far enough away.
> 
> Jerry Anning
> cle### [at] dholcom

Post a reply to this message

On Sun, 25 Oct 1998 00:09:36 -0400, Nathan Kopp <Nat### [at] Koppcom>
wrote:

>This is a good idea, but it will probably not work perfectly, because of
>multiple intersections with trace (how do you ensure that you'll get all
>of them?).  Also, you will run into problems with sharp edges getting
>rounded because a sample ray doesn't hit them directly.

I guess you trace again after you find the first intersection,
starting just past the first intersection.  But I'd rather watch my
grass grow than actually do such a thing.  There's also the issue of
how you determine which points are on the same surface once you've
found your cloud of intersection points.  And, of course, the limits
to any sampling scheme: the rounded edges you mention, plus aliasing.

Post a reply to this message

Nieminen Mika wrote:

/.../
>   Since many people have always worked with scanline-renderers and are very
> accustomed to them, they think that every renderer work the same way.
> 
>   In povray, and I think that in every raytracer, spheres are spheres, not
> polygon meshes. They are true mathematical, perfect spheres. And this applies
> to almost every primitive (except for primitives like bezier patch or
> heightfield).
>   CSG's are mathematically calculated, not approximated with polygons.
> 
> --
>                                                            - Warp. -

Correct me if I'm wrong, but is the fact that most POV primitives are
mathematical and 'perfect', an advantage - and yet a weakness?
As far as I know, things like non-linear transformations and true
displacement mapping require objects to be converted to triangles. These
things cannot be done in POV (except height_fields, which are true
displacements and consist of triangles).
I know that BMRT, a very good Renderman-compliant raytracer, can do true 
displacement mapping on objects - therefore albeit it is a raytracer, it
probably _does_  convert primitives into triangles for this purpose.

Margus

Post a reply to this message

This system of using the trace function could have another use, though:
distribution of light sources over the surface of an object, to simulate a true
area light source of arbitrary shape. In this case, neither aliasing, edge
rounding and other problems matter: you only need the point cloud.
I have entertained thoughts of writing a macro to do this, but I have neither
the time nor the expertise to hope for much success. I would rather have sb.
else do the hard work ;)

Margus

Ronald L. Parker wrote:
> 
> On Sun, 25 Oct 1998 00:09:36 -0400, Nathan Kopp <Nat### [at] Koppcom>
> wrote:
> 
> >This is a good idea, but it will probably not work perfectly, because of
> >multiple intersections with trace (how do you ensure that you'll get all
> >of them?).  Also, you will run into problems with sharp edges getting
> >rounded because a sample ray doesn't hit them directly.
> 
> I guess you trace again after you find the first intersection,
> starting just past the first intersection.  But I'd rather watch my
> grass grow than actually do such a thing.  There's also the issue of
> how you determine which points are on the same surface once you've
> found your cloud of intersection points.  And, of course, the limits
> to any sampling scheme: the rounded edges you mention, plus aliasing.

Post a reply to this message

Margus Ramst <mar### [at] peakeduee> wrote:
: Correct me if I'm wrong, but is the fact that most POV primitives are
: mathematical and 'perfect', an advantage - and yet a weakness?

  Both.
  Advantages:
  - The primitives are perfect. You can zoom the primitive as
    big as you want, and the surface will always be perfect.
  - It doesn't consume memory. A mathematical sphere consumes a few bytes
    of memory, while a good sphere made with a polygon mesh consumes huge
    amounts of it (probably several kilobytes or more). You can have a million
    spheres (or other primitives) without running out of memory.
  - In many cases it's faster. For example, raytracing a sphere is extremely
    fast, while raytracing a big polygon mesh is rather slow.
  Disadvantages:
  - You mentioned some of them. Non-linear transformations are not easy to
    make, and they are quite slow in many cases. UV-mapping is hard to apply
    to a mathematical object, etc.

  In some cases it doesn't make sense to convert a primitive to a mesh (for
example with bounding objects).

-- 
                                                           - Warp. -

Post a reply to this message

Margus Ramst wrote:
> 
> This system of using the trace function could have another use, though:
> distribution of light sources over the surface of an object, to simulate a true
> area light source of arbitrary shape. In this case, neither aliasing, edge
> rounding and other problems matter: you only need the point cloud.
> I have entertained thoughts of writing a macro to do this, but I have neither
> the time nor the expertise to hope for much success. I would rather have sb.
> else do the hard work ;)
> 
> Margus
> 
> Ronald L. Parker wrote:
> >
> > On Sun, 25 Oct 1998 00:09:36 -0400, Nathan Kopp <Nat### [at] Koppcom>
> > wrote:
> >
> > >This is a good idea, but it will probably not work perfectly, because of
> > >multiple intersections with trace (how do you ensure that you'll get all
> > >of them?).  Also, you will run into problems with sharp edges getting
> > >rounded because a sample ray doesn't hit them directly.
> >
> > I guess you trace again after you find the first intersection,
> > starting just past the first intersection.  But I'd rather watch my
> > grass grow than actually do such a thing.  There's also the issue of
> > how you determine which points are on the same surface once you've
> > found your cloud of intersection points.  And, of course, the limits
> > to any sampling scheme: the rounded edges you mention, plus aliasing.

There are pretty good solutions in the literature for the same surface
determination and concave surface problems (e.g. Marching Triangles)
and  rounding and aliasing can be controlled to a reasonable extent. 
They affect all triangulation, even mechanical, of course.  The speed
thing is the big drawback.  A pov patch would really be the way to go,
as for wrapped height fields, but this idea may help in some cases until
such is available.  As to the light idea, it sounds interesting.  I
don't think it would give the soft shadows of a true area light, though.
(Maybe something could be done with clever use of falloff and
judiciously placed shadowless fills?)  Just a random thought.

On another topic, given the frequency of requests for such, why has no
one coded a true parallel (Sun) light patch?  I haven't studied the POV
lighting code, but it doesn't seem too hard in principle.  Is there some
integration or functional hassle I am unaware of?  Or how about a Sky
light?  That would be a nonlocal light coming from the surround. 
Imagine the sky_sphere as one big true area light.  This would be good
for simulating sky or star light among other things.  For some purposes,
that would be more realistic than just using global ambient.

Jerry Anning
cle### [at] dholcom

Post a reply to this message

Nieminen Mika <war### [at] assaricctutfi> wrote in article
<3635e08e.0@news.povray.org>...
> Margus Ramst <mar### [at] peakeduee> wrote:
> : Correct me if I'm wrong, but is the fact that most POV primitives are
> : mathematical and 'perfect', an advantage - and yet a weakness?
> 
>   Both.
>   Advantages:
>...
>   - It doesn't consume memory. A mathematical sphere consumes a few bytes
>     of memory,...

Except of course the transforms & textures consume hundreds of bytes.  A
decent image map is many thousands of bytes.

>...

>   Disadvantages:
>   - You mentioned some of them. Non-linear transformations are not easy
to
>     make, and they are quite slow in many cases. UV-mapping is hard to
apply
>     to a mathematical object, etc.

Yes, nonlinear transformations are typically very time consuming if you are
using a raytracing approach.  Not difficult - bend the ray (e.g., use ray
marching and alter the direction component at each step using the inverse
of the transform).  POV-Ray essentially has this (think media).

Determining u/v coordinates is trivial for almost all of the primitives
(most notably the ones that are topologically similar to a rectangle like:
sphere, cone, torus, HF's, Bezier patches, ...).  POV-Ray just doesn't
happen to support it.
> 
>   In some cases it doesn't make sense to convert a primitive to a mesh
(for
> example with bounding objects).
> 

Getting back to the original question - how to get a mesh from a CSG.  This
is actually a valuable bit of software for those companies that have it. 
Accurately doing polygonal CSG involves many special cases and strange
boundary cases.  Getting a mesh for a blob is easy - use marching cubes (or
some similar algorithm, perhaps using continuation to make it go faster)
and dump the triangles.

Xander

Post a reply to this message