A WinPOV pvengine.exe build containing an OpenGL wireframe preview patch
has been made and is available at
http://www.daylongraphics.com/other/povgl/povglbin.zip

Source code available at
http://www.daylongraphics.com/other/povgl/povgl.zip


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

Post a reply to this message

Tried it ......  liked it

:)

Post a reply to this message

Triangles, polygons, cones, and heightfields
now have specific tesselators.

http://www.daylongraphics.com/other/povgl/

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

Post a reply to this message

On Wed, 11 Jun 2003 01:56:47 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:
> Triangles, polygons, cones, and heightfields
> now have specific tesselators.
> http://www.daylongraphics.com/other/povgl/

While polygons and cones issues I understand, can you elaborate what kind of
specific tesselators you applied to triangles and heightfields ? Aren't they
already tesselated ? Or do you mean "tesselators" as extraction of already
available data ?

ABX

Post a reply to this message

> While polygons and cones issues I understand, can you elaborate what kind
of
> specific tesselators you applied to triangles and heightfields ? Aren't
they
> already tesselated ? Or do you mean "tesselators" as extraction of already
> available data ?

I suppose a better term would be "vertex extraction"
but most of the time, the process is similar to tesselation.

Triangles definitely don't get tesselated since their
vertices pass directly through to the wireframer.

Heightfields are a regular grid of elevations
bounded in some 3D box, so a tesselation pass
has to occur to extract vertices. In fact, there
are many tesselations possible for a heightfield,
depending on LOD and inter-cell elevation interpolation.
I will likely have to copy Leveller's auto-LOD
tesselator as well, so that distant parts of an HF
show fewer wireframe lines -- a dense HF right now
shows up as mostly as a black blob. The current
tesselator connects each HF pixel quartet with
four lines.

If a displacement shader was used, then any primitive,
even a triangle, would need tesselation (but there'd
be little reason for a wireframe preview to show
displacement shader effects, except maybe to
examine a single primitive during shader development).

Ray

Post a reply to this message

Lathe, mesh, and plane objects now preview
using specific wireframing methods. I believe
I've also patched all primitives now, so
there shouldn't be any more crashing/freezing.

Non-linear spline lathe objects wireframe crudely;
instead of tesselating the spline between segment points,
I just connect the points directly.

Plane objects draw using a light gray color
to avoid competing with other objects.

Source: http://www.daylongraphics.com/other/povray/patches/povgl.zip
Binary: http://www.daylongraphics.com/other/povray/patches/povglbin.zip

The website for the patch has also been moved, to
http://www.daylongraphics.com/other/povray/patches

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

Post a reply to this message

Ray Gardener wrote:
> 
> Lathe, mesh, and plane objects now preview
> using specific wireframing methods. I believe
> I've also patched all primitives now, so
> there shouldn't be any more crashing/freezing.

I could not yet get any scene to render correctly with it.  Geometry seems
correct to some extent but the view is messed.  See for example
'rad_def_test.pov' in the official sample scenes.

You should add a copy of the POV-Ray licence to all packages.

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

> I could not yet get any scene to render correctly with it.  Geometry seems
> correct to some extent but the view is messed.  See for example
> 'rad_def_test.pov' in the official sample scenes.

Yeah, that file's camera is a tough one for the
wireframer to handle. Anything that uses "look_at",
actually, is likely to be off. I have to keep
working on the camera support.


> You should add a copy of the POV-Ray licence to all packages.

Can do.

Ray

Post a reply to this message

In article <3eebc386$1@news.povray.org>,
 "Ray Gardener" <ray### [at] daylongraphicscom> wrote:

> Plane objects draw using a light gray color
> to avoid competing with other objects.

Have you considered using quick_color to define the color for OpenGL 
drawing?

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <3eec2be7@news.povray.org>,
 "Ray Gardener" <ray### [at] daylongraphicscom> wrote:

> Yeah, that file's camera is a tough one for the
> wireframer to handle. Anything that uses "look_at",
> actually, is likely to be off. I have to keep
> working on the camera support.

You should be able to translate any perspective or orthographic camera 
pretty directly into OpenGL...what are you doing that makes it so hard? 
Just let the existing code parse the camera, and use the values it comes 
up with.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

>
> > Plane objects draw using a light gray color
> > to avoid competing with other objects.
>
> Have you considered using quick_color to define the color for OpenGL
> drawing?


That'd be an option, certainly, especially when
doing solid OpenGL drawing. I wouldn't want to
force it because sometimes you need a constant color
for wireframes, e.g., when making mask overlays.

Ray

Post a reply to this message

>
> > Yeah, that file's camera is a tough one for the
> > wireframer to handle. Anything that uses "look_at",
> > actually, is likely to be off. I have to keep
> > working on the camera support.
>
> You should be able to translate any perspective or orthographic camera
> pretty directly into OpenGL...what are you doing that makes it so hard?
> Just let the existing code parse the camera, and use the values it comes
> up with.

I'm calling gluPerspective() and gluLookAt().
I haven't had time to get into explicitly
setting up the OpenGL projection and modelview
matrices.

But that's the charm of open source -- if it
bothers you so much, and it's so simple to
you what the solution is, then you don't have to wait
for me to "enter the matrix." :)

Ray

Post a reply to this message

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.

Bezier patch had a missing default wireframe method; fixed
(doesn't make it draw nicely, but stops crashing).

Source: http://www.daylongraphics.com/other/povray/patches/povgl.zip
Binary: http://www.daylongraphics.com/other/povray/patches/povglbin.zip

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

Post a reply to this message

Ray Gardener <ray### [at] daylongraphicscom> wrote:
> Camera problems have been fixed.

  Does it also work when using transformations in the camera?
  That is, something like this:

camera
{ angle 35
  translate -z*10
  rotate <35, -40>
}

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

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

>   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

"Warp" <war### [at] tagpovrayorg> a écrit dans le message de news:
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

"Warp" <war### [at] tagpovrayorg> a écrit dans le message de news:
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