I've just released a new freeware utility program
that might interest you:
http://www.kfunigraz.ac.at/imawww/thaller/wolfgang/vop-intro.html

VOP is a program that parses POV-Ray scene
description files and renders them using OpenGL.
While the resulting 3D images are not as nice as
POV-Ray's, VOP is anywhere from five to two thousand
times faster (depending on situation and measurement
method).

As you can imagine, this can be very practical for
designing scenes and animations. The downside is that
it doesn't yet support the entire scene description
language - but I think it already supports more of it
than any other program besides POV-Ray itself.

There's a Windows compile available and I could probably
compile a version for RedHat Linux 7.1, too, if somebody
really wants it.

I'm looking forward to your feedback.

Cheers,

Wolfgang Thaller

Post a reply to this message

Yes please,  or just a makefile for *nix systems.

Wolfgang Thaller wrote:

> I could probably
> compile a version for RedHat Linux 7.1, too, if somebody
> really wants it.

Post a reply to this message

Daniel Matthews <dan### [at] 3-enet> wrote:
> Yes please,  or just a makefile for *nix systems.

A linux binary is now online.

----
Notes on the Linux version

The installation instructions in the manual have not yet been adapted
for Linux, all the things said about paths and environment variables
are basically the same for Linux.

VOP was compiled on my RedHat 7.1 box.
It needs a working version of OpenGL (tested with slightly outdated
nVIDIA XFree 4 drivers, and there's no reason why it shouldn't work
with Mesa) and a current version of GLU. AFAIK, Mesa's GLU library
misses some required features, but SGI's GLU library is Open Source,
works fine, and is available from Mesa's web page, too.

Other notable dependencies:
libc.so.6
libglut.so.3
libgmp.so.3
libncurses.so.5

Source code is available separately, but there's no proper Makefile
and you first have to install a compiler and some libraries for
an exotic programming language that even most computer specialists
have never heard of (Haskell - see www.haskell.org).

VOP's home page is at:
http://www.kfunigraz.ac.at/imawww/thaller/wolfgang/vop-intro.html

Enjoy!

Wolfgang Thaller

Post a reply to this message

Wolfgang Thaller wrote:
> 
> I've just released a new freeware utility program
> that might interest you:
> http://www.kfunigraz.ac.at/imawww/thaller/wolfgang/vop-intro.html
> 
> VOP is a program that parses POV-Ray scene
> description files and renders them using OpenGL.
> [...]

You should have mentioned that the subset of Povray syntax supported is
extremely limited right now, only few basic shapes, no light sources.  On
the other hand loops and macros seem to be supported.  At least it looks
like a good start.  

There are some things of course that will probably never be fully
available like all the patterns and functions like 'trace'.  Therefore i
think building a OpenGL render mode directly into Povray will probably be
a better approach.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> wrote:

> You should have mentioned that the subset of Povray syntax supported is
> extremely limited right now, only few basic shapes, no light sources.
I actually did, only I made it sound a bit better :-). Sorry if I made it
sound too good, but those are the object types that I use most often in
my scenes [except for plane, which is some problem, as OpenGL doesn't know
about infinite objects...].

> There are some things of course that will probably never be fully
> available like all the patterns and functions like 'trace'.
You're probably right concerning "trace", and I'm not sure if it is feasible
at all to try to emulate POV-Ray's texture support using OpenGL.
It's true that VOP will _never_ support the full POV-Ray language, but with
a few well-placed #ifdef(__VOP__)s...

> Therefore i
> think building a OpenGL render mode directly into Povray will probably be
> a better approach.

However, the approach used in VOP also has some very clear advantages:
When rendering animations, VOP can skip the parsing phase in most case.
It can recalculate most expressions in the pov file from an intermediate
representation that doesn't exit (and wouldn't be useful) in POV-Ray, thus
saving _lots_ of time after the first frame. I have a simple animated scene
that takes 70 seconds per frame to render in POV-Ray. I have to wait about 5
seconds until VOP shows the first frame (thats 14 times as fast), but after
that the animation runs at 28 frames per second (thats 1960 times as fast!).

For the far future, I'm dreaming of rendering and re-rendering the scene
_as you type it in_. (I don't know if I'll ever manage _that_, however).



Wolfgang

Post a reply to this message

Wolfgang Thaller wrote:
> 
> [...]
> You're probably right concerning "trace", and I'm not sure if it is feasible
> at all to try to emulate POV-Ray's texture support using OpenGL.
> It's true that VOP will _never_ support the full POV-Ray language, but with
> a few well-placed #ifdef(__VOP__)s...

patterns can be used for more than just textures, user defined functions
would be not even half as interesting as they are without pattern/pigment
functions.

> 
> > Therefore i
> > think building a OpenGL render mode directly into Povray will probably be
> > a better approach.
> 
> However, the approach used in VOP also has some very clear advantages:
> When rendering animations, VOP can skip the parsing phase in most case.
> It can recalculate most expressions in the pov file from an intermediate
> representation that doesn't exit (and wouldn't be useful) in POV-Ray, thus
> saving _lots_ of time after the first frame. I have a simple animated scene
> that takes 70 seconds per frame to render in POV-Ray. I have to wait about 5
> seconds until VOP shows the first frame (thats 14 times as fast), but after
> that the animation runs at 28 frames per second (thats 1960 times as fast!).

I'm sure the parsing behavior of Povray will change in future versions,
megapov already contains some approaches for this (Persistence of
Variables, Persistence of Scenes), and even with current official Povray
small and efficient scenes can render very fast, up to 10-15 fps (the POV
parser is probably much faster than your one).

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> I'm sure the parsing behavior of Povray will change in future versions,
> megapov already contains some approaches for this (Persistence of
> Variables, Persistence of Scenes), and even with current official Povray
> small and efficient scenes can render very fast, up to 10-15 fps (the POV
> parser is probably much faster than your one).

It may well be that future versions of POV-Ray may be better suited to
the task. However, I think it isn't right now, and it certainly wasn't
when I started my project about one and a half years ago (I didn't work
on it full-time, of course!).
I chose not to write VOP as a part of POV-Ray for several reasons, one of
which I have already explained. Another reason is that it would be much
harder to maintain the code if it was part of POV-Ray. If someone changed
part of POV-Rays internal architecture to optimize something, I'd have
to immediately adapt my program. If I stopped working on my code, It would
be gone within a year.
The third reason is that I simply did not want to write the program in C,
which is a prerequisite for integrating it with POV-Ray.
So, please, give my program a chance - don't criticise it for not being
something that it was never intended to be.

Yours sincerely,

Wolfgang Thaller

Post a reply to this message

On Mon, 4 Mar 2002 14:54:22 +0100, "Wolfgang Thaller"
<wol### [at] gmxnet> wrote:
> I chose not to write VOP as a part of POV-Ray for several reasons, one of
> which I have already explained. Another reason is that it would be much
> harder to maintain the code if it was part of POV-Ray. If someone changed
> part of POV-Rays internal architecture to optimize something, I'd have
> to immediately adapt my program.

Unnecessarily.
Have you studied sources of POV-Ray ?  You probably did. All objects have
unified list of methods. It shoudn't be very difficult to add new method :
triangle representation. Such method can return tesselated geometry for basic
shapes like sphere, box, triangle... or just bounding_box for advanced shapes
like isosurface, parametric, sphere_sweep. Note - you maintain separated code
this way for opengl preview  and object triangulation and it is independent of
other optimizations. This way you don't have to write parser at all - just use
builded one and in apriopriate time just call OpenGL - preview. Perhaps such
preview could be called after parsing but before rendering with additional
question - "do you want real trace ?". It's not new idea - iirc it was
mentioned in p.u.p by Chris Huff year ot two ago.

ABX

Post a reply to this message

> Have you studied sources of POV-Ray ?  You probably did. All objects [...]
I'm aware of that, and I thought about it.

To summarize, my reasons for writing VOP as a separate program were the
following (and I do consider them to be good reasons):

1) "Smart Reparsing". If you change a variable in POV-Ray, the whole input
has to be reparsed. I wanted to avoid that, so I could not have used the
POV-Ray parser as is. Indeed I think it is very hard to make the POV-Ray
parser do that. It's hard enough to make it work in a specially designed
parser, and even there there's lots of work left for me to do.

2) Choice of Implementation Language.
I did not want to write the program in C, but in Haskell (www.haskell.org),
which is a modern, very high level programming language ("a non-strict
purely functional programming language") that I happen to like very
much.

I'm not saying that nobody should write an OpenGL renderer for POV-Ray.
I'm only saying that an OpenGL render integrated into POV would have
both advantages and disatvantages over my approach, at least for the
first few years of its life. I think it is my choice which of those
basic designs I devote my time to.

BTW, has anyone already tried out the program?
Discussions about design decisions taken one and a half years ago are nice,
but I'm desperately waiting for feedback on the program _itself_.


Cheers,

Wolfgang

Post a reply to this message

Wolfgang Thaller wrote:
> 
> I chose not to write VOP as a part of POV-Ray for several reasons, one of
> which I have already explained. Another reason is that it would be much
> harder to maintain the code if it was part of POV-Ray. If someone changed
> part of POV-Rays internal architecture to optimize something, I'd have
> to immediately adapt my program. If I stopped working on my code, It would
> be gone within a year.

That's not necessarily true, to a large extend Povray profits from patches
written by the users and if a patch is no more maintained by the original
author this does not mean it will be dying, best example is probably the
glow patch which was originally written for Povray 2.2 and quite lately
adapted to Povray 3.1 by Chris Huff.

> The third reason is that I simply did not want to write the program in C,
> which is a prerequisite for integrating it with POV-Ray.
> So, please, give my program a chance - don't criticise it for not being
> something that it was never intended to be.

I did not meant to criticize your work, i was merely stating my opinions
what things could be improved, as you already said there are also good
arguments for implementing it as a POV patch, but if you prefer a
different way you are free to do so.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message