 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <396353B7.B7CBD686@mitre.org>, xan### [at] mitre org 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" wrote:
>
> 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. :-)
>
These are rather limited. What I would like to see in POV-Ray is build in
lens flare effects that completely automatically disappears behind objects
(without the user having to specify the objects), becomes dimmer behind
partly transparent objects, shows up correctly in reflections and
refractions, and maybe becomes smaller or dimmer when partly behind an
object (that would be for lens flares what area_lights are for
light_sources). And even with all this functionality, I bet it could be made
faster than the current include files.
Such lens effects cannot be made with include files, but would have to be
build in.
Greetings,
Rune
--
Updated June 12: http://rsj.mobilixnet.dk
3D images, include files, stereograms, tutorials,
The POV Desktop Theme, The POV-Ray Logo Contest,
music, 350+ raytracing jokes, and much more!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3965e71b@news.povray.org>, "Rune" <run### [at] inamecom>
wrote:
> These are rather limited. What I would like to see in POV-Ray is
> build in lens flare effects that completely automatically disappears
> behind objects (without the user having to specify the objects),
> becomes dimmer behind partly transparent objects, shows up correctly
> in reflections and refractions, and maybe becomes smaller or dimmer
> when partly behind an object (that would be for lens flares what
> area_lights are for light_sources). And even with all this
> functionality, I bet it could be made faster than the current include
> files.
>
> Such lens effects cannot be made with include files, but would have to be
> build in.
Perhaps a post_process filter would be useful...it could automatically
find the bright points and place lens flares, or it could ignore bright
points and take coordinates for placing flares.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Bruce L, you recently wrote in povray.general:
> So I suppose it would be far from the realm of reality to suggest/ask
> whether it would be possible for Moray to call POV to render the basic
> scene, but call PolyRay for the NURBS and SubDivs?
Hmmm. I think this might be technically possible for Xander to write
as a plugin, although it won't work 100%. There's the problem of
reflected rays and (as you mention) shadows. Apart from that, the
render plugin could make Polyray render something, remember the
resultant image (with alpha channel so you know where the object is,
then call POV with the same scene minus the object, capturing the
pixel output and then merge the first image with the one that POV-Ray
produced. Sounds like overkill to me, though<g>. Might as well make
the Polyray plugin render the whole scene.
- Lutz
email : lut### [at] stmuccom
Web : http://www.stmuc.com/moray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruce L wrote:
>
> ...
>
> So I suppose it would be far from the realm of reality to suggest/ask
> whether it would be possible for Moray to call POV to render the basic
> scene, but call PolyRay for the NURBS and SubDivs?
You can always do compositing, sometimes with quite nice results.
Esthetically, that just doesn't appeal to me. I'd rather add code to
POV-Ray (migration of code from Polyray to POV-Ray has happened before).
>
> So how exactly (or even in-excatly,) would one ask Moray to tell Polyray
> to render a NURBS or SubDiv?
You can't. In the long term, someone could write a plugin to provide
the appropriate editing capability, or Lutz could add the appropriate
editing to Moray. At that point you could call the appropriate API
functions in Polyray. Subdivision surfaces would be pretty easy to do
once Lutz adds polygon mesh editing to Moray. Just use the mesh as the
control hull of the Subdiv surface.
NURBS editing can be pretty nasty to implement. Just look at how
popular Rhino is, due in great part to the quality of it's NURBS
editing. For me, it would be much easier to add NURBS as an object type
to POV-Ray than to do any sort of modelling capability in a front end.
Xander
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
