 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] daylongraphics com>
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
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: OpenGL patch update (June 14/2003)
Date: 15 Jun 2003 03:17:34
Message: <3EEC1D8E.95C95974@gmx.de>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
