Chris Huff wrote:
> 
> In article <396353B7.B7CBD686@mitre.org>, xan### [at] mitreorg wrote:
> 
> > The Moray plugin handles volumetrics...
> 
> How does the method it uses compare to media methods 1, 2, and 3? I mean
> the algorithm itself, as well as the results.

Not being too up on how volumetrics are done in Mega-POV, I'll try to
relate the methods.  I use a very traditional ray marching algorithm. 
Samples are taken at fixed intervals along the ray.  There's some
attempt to limit the number of samples through: use of bounding box (if
any), minimum # of samples/ray, maximum # of samples/ray, opacity cutoff
level, light influences, etc..

I don't actually have a media, as such.  I have Hypertexture objects. 
Instead of being a texture/interior kind of thing, they are considered
objects.  These objects must supply a function that looks like this:

  Sample(Flt *coeffs, Color *density, Color *Ka_color,
         Color *Kd_color, Color *Ko_color)

[Either a C++ function or a Java function - it is supplied to the
renderer when the Hypertexture is created.]  This sampling function is
called for each Hypertexture that seems to overlap the ray as the ray
marcher moves forward along the ray.

POV-Ray uses a method that first finds a minimum set of samples along a
ray interval (actually a set of intervals).  It then (if method 1 or 2?)
performs a Monte Carlo integration along the ray interval(s), using the
initial samples as a starting point.  There is a notion of variance used
for the sampling that drives where new samples are taken.

The major difference in visual quality is that the random sampling
method used by POV-Ray tends to have a grainy look (until # of samples
gets high enough).  The method I chose will look smoother for low #'s of
samples, but be subject to a banding effect.  Given the emphasis on
animation of my plugin, I prefer the latter - I don't care for the look
of a random grain when animated.

In terms of speed, it's hard to say.  POV-Ray has made certain choices
of things to accelerate, I made different ones.  Choices of parameters
also have huge impacts to runtime.  I'm not exactly sure how to make a
fair comparison.

> 
> > Polyray still has features that the baseline POV-Ray doesn't
> > accomodate.  Some things that come to mind:
> ...snip...
> > Mega-POV seems to provide for most of the things that are in Polyray
> > that are missing from POV-Ray.  It's taken a while to get there though.
> 
> If I understand these correctly, the following are available in a POV
> version, though not necessarily in the official version or MegaPOV:
> 
> ...
>      - Multiple microfacet models
>         (MegaPOV has a blinn model alongside the phong and specular
> models, does that count?)
  Just add: Cook, Gaussian, and Reitz.

>      - Lens flares
>         (POV-Ray plugins exist for this for the official version)

As objects, which affects speed of rendering.  Given the nature of lens
flares (things happening within the series of elements making up a
lens), this is more properly handled as a post process.  I would guess
that the official version doesn't account for visibility of the light
when determining which flares to draw.

>      - Particle systems
>         (Check my web page...:-) For obvious reasons, I am very
> interested in the particle-system capabilities of PolyRay. I have never
> used it, was there ever a Mac or platform independant version?)

There was a Unix version.  I had a Mac version but never released it. 
From the quick reference for Polyray, particles were declared this way:

Particles:

   particle { [particle_declarations] }
   particle_sym
   particle_sym { [particle_declarations] }


Particle declarations:
   birth expression           // count particles born when exper is
non-zero
   death expression           // Dies when the expression is non-zero
   position vexper            // Starting position
   velocity vexper            // Starting velocity
   acceleration vexper        // Acceleration added every frame
   avoid expression           // Any non-null expression invokes avoid
   count fexper               // # of objects to create at birth
   object object_sym          // Previously defined object

   Runtime variables for particles:

   P   - Current location of the particle as a vector (same as <x, y,
z>)
   I   - Current velocity of the particle as a vector
   u   - Age of the particle (frame_time * elapsed frames since birth)


So, if you wanted to build a particle system that spewed particles
outward from a point, and then when they hit the ground, generate a
secondary set of particles (using a different wrapper object), it would
look like the script below (from Polyray sample scenes).  Note that
"asphere" and "bsphere" in this case are blue and red spheres
respectively.

// Secondary burst on the ground
if (frame == start_frame)
static define part2
particle {
   death ((I[1] < 0 && y < 0.1) ? 1 : 0)
   position P
   velocity <0, 1.5, 0> + brownian(<0, 0, 0>, <1, 0.5, 1>)
   acceleration gravity
   object "asphere"
   count 20
   }

// Star burst
if (frame == start_frame)
particle {
   death (y < 0.2 ? "part2" : 0)
   position <0, 5, 0>
   velocity 2*brownian(<0, 0, 0>, <1, 1, 1>)
   acceleration gravity
   object "bsphere"
   count 50
   }

Xander

Post a reply to this message