Florian Fischer wrote:
> 
> Hi!
> 
> > Yes, it is possible to get it working with POV-Ray.  However, it is
> > quite difficult.  Given the current structure of both Moray and POV-Ray,
> > this requires writing a GUI-extension DLL for POV-Ray and a whold bunch
> > of code within the Moray plugin to establish the connection.
> So I guess it's not possible for plugins just to call the 'render'
> function in moray? Would be very easy, then. Perhaps something to do for
> Lutz.

Well, it's possible, but it gets complicated when you want to know when
the render is done.  Currently Moray doesn't pass that info along.  Also
to package up the image, I need to know either where the output file
went, or get access to a buffer that has the image.

So the approach I'm taking is to have Moray start the render, then by
using POV-Ray GUI-extensions, I capture the pixels as they are
generated.  Since my implementation is based on shared memory, there is
very little impact to POV-Ray performance (and I don't have to read a
file when POV-Ray finishes).

The drawback is that you really can't safely have multiple copies of
POV-Ray for windows running at the same time.  This has more to do with
deficiencies in POV-Ray's GUI-extension interface that with Moray
(another long story).

> 
> I'd also like rendering animations using povray as - alas! - Xander's
> anim plugin isn't very fast. This is especially important in animations!
> I've experienced that Povray renders the same scene, using similar
> settings (no antialiasing tricks!), up to four times as fast.

As far as speed differences go, it really depends on what you are
doing.  I made a NFF renderer front end for Polyray2.DLL and ran some
timing tests on SPD scenes.  Here's what I got (on a 200MHz Pentium) for
512x512, no aa, all times in seconds.  POV-Ray is 3.1e, VC++ build, GUI
priority "lowest", Render priority "highest", no display during
rendering.

          Balls(3)    Gears(3)   Tetra(6)
Polyray     63          231        11
POV-Ray     63          407        23

These are geometry heavy scenes with solid color pigments.  Gears is the
standout here, it has a great deal of refraction/reflection/shadow
recursion that has to be accounted for.  It may be that Polyray is doing
something a little different in terms of recursion depth and adaptive
bailout checks.  Tetra is a pyramidal sponge shape - since it uses no
reflection/refraction, it is a direct test of bounding hierarchy quality
and triangle intersection speed.

Moving to a couple of other scenes, here are two from Moray's web site
(also at 512x512, no aa):

           FT747         Babylon 5
Polyray     100            362
POV-Ray     106            106

The first scene, FT747 is a radio that uses CSG (especially on the big
knob) and fairly simple textures.  The other scene, Babylon 5, makes
heavy use of solid noise textures (notably "granite" based ones) - this
is what causes the huge difference in speed.  When I change the star
sphere to an image map (the Hipparcos one from JPL - 2880x1440) and the
planet texture to a map of venus (1440x720), I get these timings for
Babylon 5: Polyray: 52, POV-Ray: 59.

So it is apparent that using solid noise functions is going to present a
runtime hit.  While I'm sure that purists (I was one once) will prefer
that technique, it is slower.  another thing in favor of image maps is
that it is possible to exploit hardware acceleration...

> 
> > You would also have to be very careful not to do any modification of the
> > scene while the animation is being generated (you wouldn't be able to
> > generate multiple renders/animations at the same time like you do with
> > Polyray).  There's no way for me to lock down the scene from edits.
> Well, I don't see any solution either. But this actually only a short
> time, until all the hundreds of pov scripts have been generated. (I
> think you could just export the scene a hundred times with the
> appropriate object position and then render them. Like a batch process.)

No - I'm not going to generate (possibly hundreds) of POV-Ray data
files.  I find that approach very unesthetic.  I'm attaching to POV-Ray
as a GUI extension and getting the output image direct.

I considered the multiple file output thing.  It just seems that as you
get to more and more complex scenes, the output files get to be a bit
larger than you might desire.  Scene files larger than output images are
pretty common.

> 
> > Over time I will probably get this done - it's just that it is a bigger
> > task than it might appear.
> I hope it's coming fast!

Next beta.  Seems to be working - still cleaning things up.

> 
> I'm not missing many features in your plugin, it's few which cannot be
> done but can be by Povray. But I saw that your plugin was created from
> Polyray. Now, Polyray has even got features that Povray misses - e.g.
> spherical heightfields or area-lights. What about a plugin for them?

POV-Ray has area lights.

The problem with spherical hf's and POV-Ray is that it seems I'd have to
generate a really big mesh.

Xander

Post a reply to this message