![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a632dad@news.povray.org>, "David C" <dav### [at] sat net>
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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <chrishuff-AECD5C.12452115012001@news.povray.org>, "Chris Huff"
<chr### [at] mac com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a6353dd$1@news.povray.org>, "David C" <dav### [at] sat net>
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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a635d70@news.povray.org>, Ken Cecka
<cec### [at] alumni washington edu> 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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <chrishuff-C2A809.16204115012001@news.povray.org>, "Chris Huff"
<chr### [at] mac com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <chrishuff-2E3292.16145515012001@news.povray.org>, "Chris Huff"
<chr### [at] mac com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3a63a683$1@news.povray.org>, "David C" <dav### [at] sat net>
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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <chrishuff-752B67.20502515012001@news.povray.org>, "Chris Huff"
<chr### [at] mac com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |