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


Grüße,
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

"W³odzimierz ABX Skiba" <abx### [at] babilonorg> wrote:

> 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

Wolfgang Thaller wrote:

> 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

Thanks, nice work.

Post a reply to this message

Wolfgang Thaller wrote in message <3c834262$1@news.povray.org>...
>and I'm not sure if it is feasible
>at all to try to emulate POV-Ray's texture support using OpenGL.

You could easily add support for the quick_color portion of POV-Ray pigments

--
Mark

Post a reply to this message

"Wolfgang Thaller" <wol### [at] gmxnet> wrote in message
news:3c838737@news.povray.org...
>
> BTW, has anyone already tried out the program?
> I'm desperately waiting for feedback on the program _itself_.

As far as I can see, there is no support for arrays.
Is it true? And if so, is there any chance to get them somehow?

I think previewer for animations will be very useful.

Atb,

Gleb

Post a reply to this message

Wolfgang Thaller wrote in message <3c82b64c$1@news.povray.org>...
>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).

I just realized -- if you were to add a file output mode to VOP, you'd have
a program that can convert POV-Ray scenes to other file formats.

--
Mark

Post a reply to this message

"Gleb" <gk1### [at] sotonacuk> wrote:
> As far as I can see, there is no support for arrays.
> Is it true? And if so, is there any chance to get them somehow?

Yes, I have to admit, no arrays yet. It should be no big problem to
implement them. For big arrays, there might be problems with memory usage -
as VOP tries to save _time_ by not executing a POV-Ray script line by line,
it may waste some "space" (i.e., memory) by having to keep multiple copies
of a variable around - maybe some special optimisation would be necessary
for big arrays.
How do you use arrays in your scenes? I realize they can be useful, but I
never needed them for my own scenes.

"Mark Wagner" <mar### [at] gtenet> wrote:
> I just realized -- if you were to add a file output mode to VOP, you'd
have
> a program that can convert POV-Ray scenes to other file formats.

Yes, that should be possible. I have already thought of that, but I had no
particular interest in any particular file format. All that's needed is an
exact specification of a file format and a viewer program to try it out.
Just like VOP itself, the converter would support no textures, however.
Is there any particular file format that you think I should put on my "TODO"
list?


Cheers,

Wolfgang Thaller

Post a reply to this message

Wolfgang Thaller wrote in message <3c9270cb@news.povray.org>...
>"Mark Wagner" <mar### [at] gtenet> wrote:
>> I just realized -- if you were to add a file output mode to VOP, you'd
>have
>> a program that can convert POV-Ray scenes to other file formats.
>
>Yes, that should be possible. I have already thought of that, but I had no
>particular interest in any particular file format. All that's needed is an
>exact specification of a file format and a viewer program to try it out.
>Just like VOP itself, the converter would support no textures, however.
>Is there any particular file format that you think I should put on my
"TODO"
>list?

Since VOP doesn't support textures, I'd recommend the Alias Wavefront .OBJ
format.  It's a very straightforward format to write, if all you're doing is
writing untextured triangles.  The complete format specification can be
found at http://www.wotsit.org/download.asp?f=w_obj

--
Mark Wagner

Post a reply to this message

Mark Wagner wrote:
> Since VOP doesn't support textures, I'd recommend the Alias Wavefront .OBJ
> format.  It's a very straightforward format to write, if all you're doing
is
> writing untextured triangles.  The complete format specification can be
> found at http://www.wotsit.org/download.asp?f=w_obj

Thanks! I'm already working on it.
Can anyone recommend a good (and free) OBJ viewer (win,mac or linux/x86)?
The ones that I found are mostly crap - they support only half of the OBJ
format, and they don't do surface shading well (I can't tell if I'm
outputting the normal vectors correctly).

Cheers,

Wolfgang Thaller

Post a reply to this message

"Wolfgang Thaller" <wol### [at] gmxnet> wrote in message
news:3c9270cb@news.povray.org...
> "Gleb" <gk1### [at] sotonacuk> wrote:
> For big arrays, there might be problems with memory usage -
> How do you use arrays in your scenes? I realize they can be useful, but I
> never needed them for my own scenes.

Arrays are useful in most cases, the obvious is to use them for storing
points data, which is closely related to splines.
I consider, that VOP doesn't have splines either(does it?), but one can
somehow implement them with the help of arrays.
As far as VOP is oriented to animation, splines(arrays at least) will be a
great plus.

Gleb

Post a reply to this message

"Gleb" <gk1### [at] sotonacuk> wrote:

> [...] that VOP doesn't have splines either(does it?) [...]
> As far as VOP is oriented to animation, splines(arrays at least) will be a
> great plus.

You're right, the _published_ version of VOP doesn't have them yet. I've
been working on them.
So far, I've got linear splines and cubic (catmull-rom) splines. I don't
know the mathematical formulas for the quadratic splines, and I'm not sure
about the "natural" splines. I have implemented catmull-rom splines, but now
that I've seen them in action, I don't like them (my camera, animated using
a spline, did a strange looping and sudden speed changes). [OT: What kind of
splines would you use for a "fly-through" style animation?]

I'll upload an updated version in the next few days.

Cheers,

Wolfgang

Post a reply to this message

"Wolfgang Thaller" <wol### [at] gmxnet> wrote in message
news:3c98dcac$1@news.povray.org...
> a spline, did a strange looping and sudden speed changes). [OT: What kind
of
> splines would you use for a "fly-through" style animation?]

Imho for smooth movements the natural cubic splines would be the best.

Regards,

Gleb

Post a reply to this message