>   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

An idea:

  Clicking and dragging on the preview window, perhaps with some hotkey
pressed (as to not to interfere with the partial preview selection)
could rotate the OpenGL camera around the look_at point. This way you
could quickly view the wireframe of the object/scene from different
sides without having to edit the scene file itself. Perhaps with another
hotkey the camera distance from the look_at could be modified.
  If you have ever used Moray, you'll know what I'm after.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

3eedaaf7@news.povray.org...
>   An idea:
>
>   Clicking and dragging on the preview window, perhaps with some hotkey
> pressed (as to not to interfere with the partial preview selection)
> could rotate the OpenGL camera around the look_at point.

I wholly second this idea. To be honest, I still don't see the point of an
OpenGL preview as it is. My tests with the patch resulted in a totally
useless and very black tangle of wireframe lines... But a shadowed view (not
wireframe) with quick color and the ability to walk through the scene would
certainly be a big plus. Add the ability to zoom/pan and to jump back to the
main camera position(s), like in a VRML browser, and this will actually help
scene design. Of course, once this gets done, people will start asking for
the ability to move things around, and then to scale them, and then Ray will
end up creating a modeller!

G.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Ray Gardener wrote:
> 
> Camera problems have been fixed.
> Any POV-Ray perspective camera should work now,
> except those with inverted vectors such as rad_def_test.pov,
> which will appear flipped horizontally.

That will diminish the usability of your patch quite a lot - various
sample scenes from the official distribution (particularly most i made
:-)) work this way - same applies for scenes generated by Moray AFAIK.

I agree with Gilles that the use of a quick preview is not very
significant without 'interactive' features - those would be difficult (but
not impossible) to implement in a portable way of course.  If it's just
the static preview it does not matter much if it takes 0.1 seconds or 1
second - this can be achieved with raytracing as well when you reduce
quality of the result.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

>... Of course, once this gets done, people will start asking for
> the ability to move things around, and then to scale them, and then Ray
will
> end up creating a modeller!

Yeah... yeah. That'd be neat.

For objects that are explicitly instanced, an
extra object member var could store which file and line
created it. Then double-clicking the displayed object would
scroll the .pov file to that point in the editor.

I also like that idea of raytracing single objects.
Click an object, hit a key, and it tells the raytracer
to render the region bounding the object's screen projection.
Or better still, raytraces just the object itself.

Ray

Post a reply to this message

Gilles Tran <tra### [at] inapginrafr> wrote:
> I wholly second this idea. To be honest, I still don't see the point of an
> OpenGL preview as it is. My tests with the patch resulted in a totally
> useless and very black tangle of wireframe lines...

  I said "wireframe" but was really talking about any type of OpenGL
preview, be it wireframe or shaded triangles or whatever.
  And besides, a wireframed still image may look very cluttered, but
when the camera is moved, it helps visualizing objects a lot.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

3eee1a65@news.povray.org...
>   I said "wireframe" but was really talking about any type of OpenGL
> preview, be it wireframe or shaded triangles or whatever.
>   And besides, a wireframed still image may look very cluttered, but
> when the camera is moved, it helps visualizing objects a lot.

My experience with wireframe / shaded triangles in Rhino is mostly that
wireframe is a real time modeling tool, but that when you really want to
know where your objects are, the only good way is the shaded OpenGL preview.
When you've got a lot of stuff on screen, which is after all the point of
making whole scenes, the wireframe are useless. In the scenes I've tested,
the screen was simply black with wireframe lines, and I don't think that
moving the camera would have helped seeing anything. It only starts to make
sense if you can organise objects by layers and turn them on and off easily,
but eventually, it's the shaded preview that tells you if you're on the
right track or not.

G.


--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

> ... In the scenes I've tested,
> the screen was simply black with wireframe lines, and I don't think that
> moving the camera would have helped seeing anything.

The point is well taken. The OpenGL stuff for me
is more about potential than specific uses.
The wireframing stuff (even the whole preview stuff)
may be a bust, but I have a feeling that there's
other things worth enabling (even if I'm not sure
what those things are right now).

It might wind up purely as a debugging aid for
adding primitives, for all I know, because it's
good at showing an object's bounding box -- you
can see if the bbox is too large or too small,
if it's transforming right, etc.

Ray

Post a reply to this message

Here are some images that show the results of implementing
the recursive CSG scanline drawing algorithm mentioned a
few days ago:

http://www.daylongraphics.com/other/povray/patches/index.htm#csg


Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com

Post a reply to this message

OpenGL perspective camera accuracy just about perfect; OpenGL output
 registers with raytraced imagery almost pixel-for-pixel. If you
render something like scenes/advanced/newltpot/teapot2.pov it
feels like watching a 3D modeler go into raytracing; the
register is spot on.

Solid scanline rendering mode available too (spheres only for now).

http://www.daylongraphics.com/other/povray/patches/index.htm


Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com

Post a reply to this message