 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been looking around at different raytracers lately (I *love*
PovRay, of coarse), and PolyRay has caught my attention. It seems like
a fairly complete package, and even supports Nurbs; but, the latest
version (1.8a) seems to have been released 5+ years ago. Is it no
longer being developed/maintained? How does it compare with PovRay (no
flames please)? Thanks for your time and help.
Jordan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jordan" <cel### [at] voyageur ca> wrote in message
news:395### [at] hotmailcom...
| I've been looking around at different raytracers lately (I *love*
| PovRay, of coarse), and PolyRay has caught my attention. It seems like
| a fairly complete package, and even supports Nurbs; but, the latest
| version (1.8a) seems to have been released 5+ years ago. Is it no
| longer being developed/maintained? How does it compare with PovRay (no
| flames please)? Thanks for your time and help.
That was the last version I guess. Nothing else ever seemed to surface. I
used Polyray before finding POV-Ray way back in 1993 or '94, about the time
1.8 was first around I think.
Alexander Enzmann seemed to have joined up with the POV-Team, I don't know the
specifics, and left Polyray to gather some dust. Except I think many people
still use it so that's not a completely accurate statement.
Polyray 1.7, 1.8 and POV-Ray 1.0, 2.0 are, or were, very similar in the way
the syntax was done. Very comparable in 1994-96 I'd say but thereafter
POV-Ray has been pretty unbeatable because of feature additions like
atmosphere and halo first then media (kind of volumetric things).
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 1 Jul 2000 23:05:06 -0500 "Bob Hughes"
<per### [at] aolcom?subject=PoV-News:> wrote:
>Alexander Enzmann seemed to have joined up with the POV-Team, I don't know the
>specifics, and left Polyray to gather some dust. Except I think many people
>still use it so that's not a completely accurate statement.
Hi, Bob and Jordan. Xander is currently active on the POV-Team but he
was also a member many years ago, too.
For those working from the Windows 9x platform, Xander has recently
written a Polyray plug-in for the modeler Moray.
http://www.stmuc.com/moray
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Hughes wrote:
>
> "Jordan" <cel### [at] voyageurca> wrote in message
> news:395### [at] hotmailcom...
> | I've been looking around at different raytracers lately (I *love*
> | PovRay, of coarse), and PolyRay has caught my attention. It seems like
> | a fairly complete package, and even supports Nurbs; but, the latest
> | version (1.8a) seems to have been released 5+ years ago. Is it no
> | longer being developed/maintained? How does it compare with PovRay (no
> | flames please)? Thanks for your time and help.
[As mentioned in email as well.] Polyray as a separate application
really isn't being supported any more. The source is available if
people really want to play with it, but I've pretty much rewritten the
entire thing as a library (which can be seen as a plugin for Moray).
>
> That was the last version I guess. Nothing else ever seemed to surface. I
> used Polyray before finding POV-Ray way back in 1993 or '94, about the time
> 1.8 was first around I think.
> Alexander Enzmann seemed to have joined up with the POV-Team, I don't know the
> specifics, and left Polyray to gather some dust.
Was with the POV-Ray team before there was a Polyray or a POV-Ray...
Except I think many people
> still use it so that's not a completely accurate statement.
> Polyray 1.7, 1.8 and POV-Ray 1.0, 2.0 are, or were, very similar in the way
> the syntax was done.
For a very simple reason - I was using (and writing patches for) DKB at
the time I started Polyray. I happened to choose lex/yacc for the
parser rather than build a recursive descent parser like DKB or POV-Ray.
Very comparable in 1994-96 I'd say but thereafter
> POV-Ray has been pretty unbeatable because of feature additions like
> atmosphere and halo first then media (kind of volumetric things).
The Moray plugin handles volumetrics...
Polyray still has features that the baseline POV-Ray doesn't
accomodate. Some things that come to mind:
- Depth maps for lights
- Direct output of zbuffer values
- General functions to describe object shapes
[Both implicit and parametric]
- Displacement surfaces
- General functions for texture components
- General functions for light colors
- Multiple microfacet models
- NURBS (untrimmed)
- Point, line, and spline drawing into image
- Lens flares
- Particle systems
- U/V coordinates for texturing
- Environment mapping
- Scanline/ZBuffer rendering modes
- Static (cross frame) variables
- And others I can't remember...
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.
Xander
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
> 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:
- Direct output of zbuffer values
(MegaPOV, as a post_process filter)
- General functions to describe object shapes
[Both implicit and parametric]
(MegaPOV, as in the isosurface and parametric shapes)
- General functions for texture components
(MegaPOV, isosurface funtions can be used as patterns, which is
close to this. There is also someone working on a shader patch)
- Multiple microfacet models
(MegaPOV has a blinn model alongside the phong and specular
models, does that count?)
- Lens flares
(POV-Ray plugins exist for this for the official version)
- 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?)
- U/V coordinates for texturing
(MegaPOV...)
- Static (cross frame) variables
(MegaPOV has persistent variables too.)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh hey, that was the main reason I didn't continue with Polyray, it had more
features than I could handle at the time. I'm still trying to catch up.
Good to hear all that direct from the horses mouth. So few people know any
program better than the author. I had convinced myself that Mr. Enzmann had
been coaxed into joining the POV-Team because of Polyray's
existence/reputation.
Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39647B53.CC2D4732@mitre.org>, xan### [at] mitreorg wrote:
> 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..
This sounds similar to MegaPOV method 2 media. It takes evenly spaced
samples, and produces images without the graininess of the official
version(called method 1 in MegaPOV), but has problems with banding and
jagged edges. There is a method 3 which performs supersampling at areas
where the samples vary by more than a threshold level, this kind lacks
most of the artifacts of method 2 and is nearly as fast.
> > - Multiple microfacet models
> > (MegaPOV has a blinn model alongside the phong and specular
> > models, does that count?)
> Just add: Cook, Gaussian, and Reitz.
Do you know of any online papers about these?
> > - 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.
There are two lens flare includes which I know of, and at least one of
them can do "hiding" of a lens flare behind an object. However, though I
have installed both of these "plugins", I have never actually used them,
so I don't really know what I am talking about. :-)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruce L wrote:
>
> > [As mentioned in email as well.] Polyray as a separate application
> > really isn't being supported any more. The source is available if
> > people really want to play with it, but I've pretty much rewritten the
> > entire thing as a library (which can be seen as a plugin for Moray).
>
> Is this plugin/dll available/allowed to be called from other programs
> besides Moray? I realize you built it specifically for Moray, and had
> some input into the related SDK, but was just wondering how specific it
> was. Could you just dump a set of triangles and textures to it? Or
> perhaps even just the name of the main scene description file?
Yes - in fact I built most of it before using it as part of a Moray
plugin. The animation plugin actually consists of two major pieces, the
Moray scene interface and animation manager, plus the rendering
library. Essentially what happens when it it used to render from Moray
is that all the textures and objects get created by calling an API to
the renderer DLL (with callbacks as appropriate).
I have a few sample applications that use the rendering DLL: An NFF
renderer (uses Haines' nff scene files from SPD), a simple object viewer
for a couple of mesh based formats (3ds, obj, 3dm), and a simple
particle system program. Like many programmers, I haven't done a whole
lot of documenting of how to use the interface to the library, it sorta
has to be learned from the examples.
If you want to give it a try, just email me directly.
As far as just dumping triangles into the renderer - yes. That's really
pretty easy to do. I have a sample program that builds a mesh to
represent a piece of cloth (and then have it drape on some objects) and
then modify the vertices as the simulation steps forward. In that
particular program, the objects that the cloth gets draped on are
created as standard prims like boxes and the renderer is used to
tesselate them. Once I have all the triangles for the scene, the actual
application does the collision detection between the cloth & scene (the
particle system sample is similar).
>
> I have been considering adding some raytracing interface options to my
> own DMesh object modeller, (ie: spawning PovRay or BMRT,) but additional
> options would be welcome if I'm not stepping on any toes. It's a simple
> organic mesh modeller, not a full scene modeller like Moray, so the only
> real 3D objects are uv-mapped triangles.
I don't really see why not. I'm pretty sure that the OpenGL & Direct3D
support are turned off in the Moray plugin, but could be turned back on
for a little better speed. I don't have a hardware 3D accelerator, so I
don't know just how much improvement you would see. You could use
OpenGL or D3D directly, but you might find using the higher level API
functions of the DLL a bit easier.
> ... (Although if it could handle
> subdivision surfaces, that would be a pretty big bonus <g>) If I
> remember correctly, PolyRay also supported NURBS. Do these exist in the
> plugin/dll version?
The NURBS support in the renderer is actually much better than in
Polyray v1.8. I have added adaptive tesselation and support for trim
curves. I've used Rhino files to do some testing and have had pretty
good success. The biggest problems are for patches that have
significant pinching (e.g., the poles in a sphere that is represented by
a single NURBS patch).
There is code for Loop style subdivision surfaces (that's the kind with
triangular pieces). I haven't really done much with it, so all you can
do is hand in the starting mesh and tell it how many steps to subdivide
before rendering. In the long run I wan't to do adaptive subdivision on
it as well (it's harder than for a u/v type surface like a patch).
Xander
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
>
> In article <39647B53.CC2D4732@mitre.org>, xan### [at] mitreorg wrote:
>
> ...
> > > - Multiple microfacet models
> > > (MegaPOV has a blinn model alongside the phong and specular
> > > models, does that count?)
> > Just add: Cook, Gaussian, and Reitz.
>
> Do you know of any online papers about these?
I used the info in the book, "Illumination and Color in Computer
Generated Imagery" by Hall. Don't know if the bits and pieces are
online.
Xander
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
