I am wondering about adding an OpenGL preview for animations. I have three
questions.

- Would it be legal to distribute since OpenGL would be doing the
rendering and povray would only be doing the parsing?
- Is it being done already?
- Is it somthing that the povray comunity would be interested in using?
(besides me)

I am thinking of just using it for very fast test renders, using quick
colors instead of real textures and simple lights so you can see how the
objects look and how the camera moves. You could then tweak it very
finely for animations since the edit/render/view cycle would be shorter.

Post a reply to this message

In article <3a632dad@news.povray.org>, "David C" <dav### [at] satnet> 
wrote:

> I am wondering about adding an OpenGL preview for animations. I have three
> questions.

This would probably be harder than you think...the code for setting up 
OpenGL would be platform dependant, and you would have to use something 
like Warp's tesselation patch, because most objects are rendered 
directly, not tesselated.


> - Would it be legal to distribute since OpenGL would be doing the
> rendering and povray would only be doing the parsing?

I don't think there would be a problem, as long as the version you are 
distributing consists of everything in the official version of POV 
*plus* optional OpenGL rendering. (You couldn't release a version that 
only does OpenGL previews.) I'm not sure though, I will check with the 
POV-Team.


> - Is it being done already?

If so, nobody has said anything about it. I doubt it, for the reasons I 
mentioned above.


> - Is it somthing that the povray comunity would be interested in using?
> (besides me)

Almost definitely.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <chrishuff-AECD5C.12452115012001@news.povray.org>, "Chris Huff"
<chr### [at] maccom> wrote:

> This would probably be harder than you think...the code for setting up 
> OpenGL would be platform dependant, and you would have to use something
> like Warp's tesselation patch, because most objects are rendered 
> directly, not tesselated.

I know about how the objects are rendered. I was thinking of using the
glut library so that it would be platform independent. I really havn't
put too much thought into this. It's just a really neat idea I had that I
may or may not write.

Post a reply to this message

David,

Have you thought much about how you would handle CSG?  I don't know 
anything about Warp's tesselation patch that Chris referred to, but CSG can 
be a show-stopper.  Finding an algorithm to generate meshes for arbitrary 
CSG combinations is difficult.  Usually you end up with a tradeoff between 
speed and accuracy.  For a static OpenGL display, the algorithm doesn't 
need to be particularly fast since you only calculate the mesh once, and 
then are free to explore your scene with a mobile camera (fun!).  If you 
want animation, you need to be able to quickly recalculate CSG meshes 
(consider a scene with a difference of two spheres, where one of the 
spheres slides from left to right during the animation).

I've actually written a lot of code to solve this exact problem (since I 
figured almost any other primitive POV uses will be easy to tesselate), and 
have pretty well given up on it, although I still fiddle with it from time 
to time.  There are some fundamental problems in the approach I was taking 
that I haven't seen a way to solve yet.  I can go into more detail on what 
I've tried and some of my conclusions if you're interested.

Ken

David C wrote:

> I am wondering about adding an OpenGL preview for animations. I have three
> questions.
> 
> - Would it be legal to distribute since OpenGL would be doing the
> rendering and povray would only be doing the parsing?
> - Is it being done already?
> - Is it somthing that the povray comunity would be interested in using?
> (besides me)
> 
> I am thinking of just using it for very fast test renders, using quick
> colors instead of real textures and simple lights so you can see how the
> objects look and how the camera moves. You could then tweak it very
> finely for animations since the edit/render/view cycle would be shorter.
>

Post a reply to this message

In article <3a6353dd$1@news.povray.org>, "David C" <dav### [at] satnet> 
wrote:

> I know about how the objects are rendered. I was thinking of using the
> glut library so that it would be platform independent. I really havn't
> put too much thought into this. It's just a really neat idea I had that I
> may or may not write.

Hmm...if you use the GLUT library, you gain platform independance (you 
will only need to recompile for most platforms), but it kind of limits 
you...I don't think you can combine GLUT with platform-dependant 
interfaces, and GLUT was mainly designed for tests and demos. Maybe a 
GLUT interface, but make sure you keep the GLUT-dependant code well 
separated and provide plenty of ways to use other platform-specific 
interfaces instead.
And GLUT still won't help you render many POV primitives...julia 
fractals, for instance.

And what extent of previewing were you thinking of? An immediate preview 
of each frame and writing those results to the output file, or rendering 
all frames (without displaying) and displaying them all at once? For 
stills, a way to move camera and lights around without reparsing the 
file? (that last one could be really platform/GLUT dependant...)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <3a635d70@news.povray.org>, Ken Cecka 
<cec### [at] alumniwashingtonedu> wrote:

> Have you thought much about how you would handle CSG?  I don't know 
> anything about Warp's tesselation patch that Chris referred to, but 
> CSG can be a show-stopper.  Finding an algorithm to generate meshes 
> for arbitrary CSG combinations is difficult.  Usually you end up with 
> a tradeoff between speed and accuracy. 

Warp's code uses the marching tetrahedrons algorithm and can handle any 
arbitrary shape, including CSG. There is a speed/accuracy/memory 
tradeoff...and the meshes aren't as optimized as they could if you made 
them yourself, but it works, and OpenGL would just be a preview, so you 
wouldn't even need very high quality meshes.


> For a static OpenGL display, the algorithm doesn't need to be 
> particularly fast since you only calculate the mesh once, and then 
> are free to explore your scene with a mobile camera (fun!).

I'm not clear on whether he is working on that kind of interactive 
display or simply using OpenGL for extremely fast preview images.

 
> If you want animation, you need to be able to quickly recalculate CSG 
> meshes (consider a scene with a difference of two spheres, where one 
> of the spheres slides from left to right during the animation).

Or just compute all the images and play back the results. Or just do 
things the way POV does them now, only using OpenGL to do the rendering 
instead of the raytracing engine.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <chrishuff-C2A809.16204115012001@news.povray.org>, "Chris Huff"
<chr### [at] maccom> wrote:
> 
> 
> Or just compute all the images and play back the results. Or just do 
> things the way POV does them now, only using OpenGL to do the rendering 
> instead of the raytracing engine.

I was originally thinking of just using opengl as a relatively superfast
way to render animations exactly how povray does it so you can see how
they look. I personally can't see many practical reasons you would need to move
around in the world other than the camera defined in the pov file.

Post a reply to this message

In article <chrishuff-2E3292.16145515012001@news.povray.org>, "Chris Huff"
<chr### [at] maccom> wrote:

> 
> 
> And what extent of previewing were you thinking of? An immediate preview
>  of each frame and writing those results to the output file, or
> rendering  all frames (without displaying) and displaying them all at
> once? For  stills, a way to move camera and lights around without
> reparsing the  file? (that last one could be really platform/GLUT
> dependant...)
> 
 I have thought about some of these things too. I might have a framerate
problem if I tried to render the animation in real time. There is no fps
option in povray as well, so I wouldn't know the user's desired
framerate. I think definitely that each frame should be rendered and
written to a file. I'm not sure about real time previewing. There is also
the matter of how to get the frame from opengl to a file. I know some
libraries support offscreen rendering, but that again would be platform
dependent. Ah well. Maybe I should play with opengl and get comfortable
with it for a few weeks first.

Post a reply to this message

In article <3a63a683$1@news.povray.org>, "David C" <dav### [at] satnet> 
wrote:

> I was originally thinking of just using opengl as a relatively 
> superfast way to render animations exactly how povray does it so you 
> can see how they look. I personally can't see many practical reasons 
> you would need to move around in the world other than the camera 
> defined in the pov file.

That should be easier to write and keep platform independant, too. And 
more likely to get working right...
How do you plan on doing different camera types? As far as I know, 
OpenGL only does perspective and orthographic projection. You might have 
to issue a warning when another type is used and use perspective 
projection in those cases...that shouldn't be a problem for quick 
preview renders.

Practical reasons: it could make it easier to get camera position/angle 
and general lighting right, but it really would be the job of a 
third-party modeller.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <chrishuff-752B67.20502515012001@news.povray.org>, "Chris Huff"
<chr### [at] maccom> wrote:

> That should be easier to write and keep platform independant, too. And 
> more likely to get working right... How do you plan on doing different
> camera types? As far as I know,  OpenGL only does perspective and
> orthographic projection. You might have  to issue a warning when another
> type is used and use perspective  projection in those cases...that
> shouldn't be a problem for quick  preview renders.

Well I wasn't thinking of fully supporting all of povray's stuff like
some of the different light types that don't have a native equivelent in
opengl. And then, there's transparency, reflections, refractions,
povray's function-textures, media, imagemaps, and maybe a few more
I havn't thought of.

> Practical reasons: it could make it easier to get camera position/angle 
> and general lighting right, but it really would be the job of a 
> third-party modeller.

In order to get camera position and angle, there would need to be a way
to output the current values that the camera has which would make opengl
rendering even more different than povray raytracing. I think, if I do
actually start building it, that I'd try to mimic the behavior of native
rendering as much as possible. For me, this is all just talk so far. I'd
love to do it, but I'm not sure I will.

Post a reply to this message