> 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