This question may have been asked, and if so, I'm sorry, but does this animation
plugin support media/fog?

Alexander Enzmann wrote:

> 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



--
Given a lever long enough, one can move the world with little force
      MJ Engh

Post a reply to this message