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