As far as I understood, your biggest concern is a speed of conversion
from a some-complex-object to a mesh. I do believe that it will not be a
bottleneck in most cases providing we are not going to recreate our scene
with a PovRay quality. Exact "approximation" of sphere has infinite number
of triangles ;-). We don't need _that_ in a preview mode.

Years ago I was surprised that bezier-based approximation working with
1-pixel precision draws circles virtually identical to ones produced be
"real" math formula. A number of lines produced by bezier was relatively
low. And a raw speed is incomparable (bezier is faster)! So far I didn't
see any real life examples, which don't benefit from an approximation.
Of course some quality can be lost.

If new version of PovRay could parse a file on the fly or in the background,
the same techniques can be applied: as you change the file it can convert
only changed parts. You don't need to convert a PovRay file to some other
graphics primitives every time. You can store this information in a
persistent "cache" file specific to the driver (OpenGL, D3D or whatever
you have). How to support it up-to-date? You already said about lookup
tables and there are zillions of other possible solutions for external-data-
to-internal-cache problem.

If we look at really simplistic cases like the Turok game, we will see that
all 3D accelerators outperform any known software-based renderers (i.e.,
see excellent Tom's Hardware Guide @ http://www.tomshardware.com/
for some numbers and pics). Speaking for myself, I do try to use some
obscure visual effects and unusual shapes in my scenes which are not
possible to recreate with Voodoo2 :-) but usually my geometry is not
more complex than some complex scenes in the Quake II or the Turok.
I wish I was able to render at their speed!

...And MMX can help too. :-) ...And multiprocessing is very helpful. :-)

Cheers,

Eugene

Tristan Wibberley wrote in message
<01bd36e9$46e16b60$181657a8@W_tristan.gb.tandem.com>...
>A quick preview of geometry will not be any more efficient without big
>complicated geometry (maths side of things) acceleration hardware. OpenGL
>and Direct3D require Meshes, and it can take a while to come up with a mesh
>for small objects compared to rendering them with low quality flags (we are
>talking two light sources - ambient and a directional source, only ambient
>and diffuse shading on objects - no shadows - no reflection or refraction).
>
>You can render a high resolution image in under a second. How long will it
>take to parse a complex scene into meshes for rendering with OpenGL?
>
>A new version of povray for windows could parse a .pov file when it is
>opened, and preview, then as you change the file, look up in a table made
>at parse time for what object you are editing, then re-render. A preview
>window could even have a text box for clock value, and a drop down for you
>to select declared objects names from any open file (eg if you are editing
>an inc that calculates rand numbers for transformations, you could have
>selected an object declared in another file that uses these random
>numbers).
>
>--
>Tristan Wibberley
>
>(Remove the '.NO_LUNCHEON_MEAT' from my
>email address to reply.)
>
>
>Eugene Lazutkin <eug### [at] carnac-graphicscom> wrote in article
><34b66582.0@news.povray.org>...
>| I am talking about preview mode to test geometry, placements, sizes and
>| so on (see my original post). I am aware that it is not possible to
>recreate
>| the exact picture with OpenGL or Direct3D. But we can approximate :-).
>| We can simulate complex shapes with basic ones.
>|
>| Sometimes I need rather crude picture but I can't use small previews
>| because my picture consists of a number of small objects. In this case
>| what I need is _raw speed_.
>|
>| I know about future convergence between OpenGL and DirectX and I
>| welcome it. But they will be distinct at least for 5 more years: first
>| commercial version of low-level API is scheduled on Y2K and it will
>| need some polish (you can trust me on that :-) ) and don't forget about
>| legacy UNIX systems which will support good old OpenGL for their
>| lifetime :-).
>|
>| Eugene
>|
>| Jon S. Berndt wrote in message <34A50D56.A31FDCF9@hal-pc.org>...
>| >Eugene Lazutkin wrote:
>| >
>| >> I agree with you 100%. OpenGL can help a lot when someone debugs a
>| >> geometrically complex scene (placements, geometry, sizes) when it is
>| >> not practical to use small previews. It may not help to test lights
>| >> and
>| >> textures but anyway it will be _very_ useful piece of functionality.
>| >>
>| >> My wish list for future versions of POV-Ray:
>| >>
>| >> General: OpenGL preview and multiprocessor capabilities.
>| >> Windows-specific: (possibly) Direct3D preview, full MMX support.
>| >>
>| >> Reasons: I see OpenGL and DirectX as the only reasonable way to
>| >> support
>| >> platform-specific hardware- (and software-) assisted acceleration. All
>| >> new
>| >> processors are MMX-capable and it is a crime not to use accelerating
>| >> facilities for computing power-hungry apps :-). Now when memory prices
>| >> are
>| >> going down and Intel processors are dirt cheap, it is practical and
>| >> inexpensive
>| >> to have a dual processor computer under NT or whatever you like. There
>| >> is
>| >> a number of multiprocessor UNIX computers out there. A lot of people
>| >> buy
>| >> dual-processor motherboards counting on future upgrades by adding
>| >> second
>| >> CPU. I believe it should be supported eventually.
>| >>
>| >> Eugene
>| >
>| >Note that as far as I know OpenGL has no good way to do CSG - and some
>| >other correspondences between OpenGL and POV language do not relate.
>| >Also, as for OpenGL and DirectX, Microsoft and SGI have just announced
>| >they will work together with their two respective technologies to merge
>| >them into a better standard for 3D on the PC. Read their release at
>| >microsoft.com or opengl.org or sgi.com. The people I have talked with,
>| >and myself, think this is a great move.
>| >
>| >OpenGL previews would most likely be limited to basic shapes, in my
>| >opinion.
>| >
>| >jon
>| >
>|
>|
>|

Post a reply to this message