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

Hi!

> 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).

Well, it's well known that this doesn't even work with Moray, without
using your anim plugin! - Why would Moray make you set 'Keep single
instance' during installation. - Thus, that's no problem for me. I've
never seen any advantage in running multiple instances of POV-Ray. Renders
just don't become faster. ;-)

> > 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 may tell you what scene I used: it's just the object 'Starship Voyager'
which you can get in the objects library. I'd like to make it fly...

> 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...

Sorry, but what are solid noise functions? Some examples, please.
And why is POV-Ray faster in rendering them?
I'm not very current in raytracing math.

> 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.

Well, if you solved the problem that the scene may no longer be edited
during rendering... I just thought of it as a stopgap measure.

> > I hope it's coming fast!
> 
> Next beta.  Seems to be working - still cleaning things up.

Oh, thanks! That's really fast!

> 
> >
> > 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.

That's not what I meant. I thought of features that are supported by
polyray (and probably your anim plugin, too) but not by Moray. It's not
necessary that you export the spherical heightfields created in this
manner to Povray. It's enough if your plugin can do them.

Florian

Post a reply to this message

> Well, it's well known that this doesn't even work with Moray, without
> using your anim plugin! - Why would Moray make you set 'Keep single
> instance' during installation. - Thus, that's no problem for me. I've
> never seen any advantage in running multiple instances of POV-Ray. Renders
> just don't become faster.

It come in handy when you want to render more than one thing at once, in my
case I have a 800x600 AA RAD mega CSG detail image i am rendering, looks
like taking close to 36 hours to render (will post when finished :)

and by enabling multiple instances I can still mess about with other scenes
while i leave the main one going in the BG.

Rick

Post a reply to this message

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

Hi!

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

I know that it supports "volumes", Xander's name for media.
I don't know if it supports fog, but I think so.
BTW, Xander is just making it possible to render animations via POV-Ray.
Just wait, it's fastly becoming better and better.

Florian

Post a reply to this message

Then, as they say, we will be cooking with Gas.
Rick

Florian Fischer <flo### [at] gmxde> wrote in message
news:372A910E.B463064B@gmx.de...
> Hi!
>
> > This question may have been asked, and if so, I'm sorry, but does
> > this animation
> > plugin support media/fog?
>
> I know that it supports "volumes", Xander's name for media.
> I don't know if it supports fog, but I think so.
> BTW, Xander is just making it possible to render animations via POV-Ray.
> Just wait, it's fastly becoming better and better.
>
> Florian
>

Post a reply to this message

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

The proper answer is mostly no.   While I've got a pretty good ability
to render media with my renderer, there's no animation for it.  I
haven't gotten around to doing fog yet (my renderer does it differently
than POV-Ray and I've got to do some coding to get something that looks
the same).

One problem is that there currently aren't any events coming through the
Moray plugin interface that tell me hard to tell just what/when to set
keys.

A secondary problem (mostly mine) is that I can only keyframe things
that have names.  Moray doesn't require a name for all material elements
(again, like media).

A third problem is what do do if two things point to the same material. 
If I set the keys based on how one object wants to use the material, it
will affect any other object using it.  This looks like a relatively
minor problem.


What I'm thinking of is that when a key gets set for an object, walking
down it's attributes and seeing if there's a material in there.  If so,
then I'll set keys for the entire material and any named pieces of it. 
Then if you want to keyframe media, you will need to give the pieces of
the media names (like you would if you wanted atmosphere).


All this kind of has to wait until Lutz and I resolve some pretty nasty
crashes associated with how I want to control POV-Ray...

Xander

Post a reply to this message