>   Does it also work when using transformations in the camera?
>   That is, something like this:
>
> camera
> { angle 35
>   translate -z*10
>   rotate <35, -40>
> }

Yes, you can do that now. The "Angle" member of the CAMERA struct
is totally ignored now, and the gluPerspective FOV is computed
strictly from the camera's vectors (the vectors are also the
only thing POV's perspective camera uses, so we have closer
behavioral parity now). I also defaulted the OpenGL camera
using a POV cam minted with Create_Camera(), so a scene without
a camera should render okay too.


>   Moreover, a matrix transformation can be applied to the camera, which
> can shear the camera.
>   It's possible and easy to apply these same transformations in OpenGL
> as well (even the skewing ones).

These are not supported yet. Eventually I will compose
the OpenGL projection matrix directly, since it is the
more elegant solution. One remaining issue is that
the OGL projection is always off by a few pixels,
moreso for objects farther away from the line of sight
(i.e., the center of the render window), and I'm
guessing it's a loss-of-precision problem stemming
from OGL having to concatonate the projection matrix
with the modelview matrix for each object. OGL is also
working with a unit-length frustrum depth, while POV's is
much larger, so using a different Z divide might be
necessary. But I don't know if that will cause depth buffer
problems, because OGL depths are supposed to be normalized.

But for a preview, it's getting good. I've tried a lot
of the sample POV scenes, and only a handful have
inversion problems; of the rest, all one has to do
is make sure the camera is declared before other objects,
and that's that (usually about 10-30% of the scenes
need that done). In the future, I'll probably wireframe
after parsing instead of during, since that will lift
the make-the-camera-first requirement, and make it easier
to turn the wireframe into a quality setting and use
it to make wireframed animations. I was also thinking
that solid OGL would be a quality step one higher,
so overall the quality levels would be

   OGL wireframe
   OGL solid ambient
   OGL solid w/ lighting
   Raytraced quality levels 0, 1, etc.

What would be really nice is if a wireframe animation is only
moving the camera, then I could persist the object tree in
memory across frames, which will make frames #2 and above
render ultra fast since they can skip the parsing. In fact,
some scenes would wireframe in realtime, so you could
have an .ini file actually "play" a wireframe (or even OGL solid)
movie right on the spot from within WinPOV. Sweet!


Other news:

bicubic/bezier patches tesselate better,
box and disc primitives tesselate, and non-union CSG
groups will recurse towards leaf nodes to call their
specific wireframers (untested). Union CSGs were already
"flattened" into leaf nodes by the parser. A good example
is teapot.pov (but you have to move the camera statement
behind the #include "teapot.inc" line).

allobjects.ini also renders without stopping, so I
think all the primitives have wireframe methods now.

The patches are ID'd with build timestamps when
WinPOV starts up, in the Messages pane, to make
identifying them easier.

Ray

Post a reply to this message