[MUD-Dev] 3D engines for MUDs (was: The MLI Project)

[Miroslav Silovic]

Michael Hohensee <michael at sparta.mainstream.net> writes:

> Of course, the POVRAY renderer does take time to work, and wouldn't be
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is gross understatement. :) While 2-3 seconds are quite
acceptable for a game, 1-60 minutes are not.

> suitable for real-time graphics unless there is a way to have it
> lower the quality of the rendering to a point where it took a
> fraction of a second to finish.  If we're not desperate for
> real-time images, however, this seems to be the logical solution.

POVray is slow for the following reasons:

	1) bad acceleration algorithm. They can only use bounding boxes
	   but not octree or bsp tree. Unfortuantely this is also hard
	   to fix because POV uses unbounded primitives, and you can't
	   take those away because POV's CSGs won't work with patches
	   (not to mention backward compatibility)

	2) POV is a raytracer. It's very hard to speed up raytracing
	   past certain point - that's why games use zbuffering instead.
	   Note that the only places where you /need/ raytracing are
	   reflective/refractive surfaces (and even there, you could
	   cheat by using environment maps).

<ShamelessPlug>
Feel free to take the code from my renderer for both zbuffering and
/really/ accelerated raytracing. Gah, now I need to speed up the
bloody thing for scenes with fewer than 1,000 polygons (as raytracing
becomes the low overhead operation in the low-complexity case, when
procedural textures and image pre/postprocessing take over... 320x240
low-quality previews take 2-3 seconds with 10 objects, 10-20 with
1000, using raytracing, and with zbuffering everything gets faster. I
solved problems with quality loss with zbuffering and as a result, you
get exactly the same image).

(renderer: http://petra.zesoi.fer.hr/~silovic/sart, and I announced it
recently on Freshmeet site)
</ShamelessPlug>

	Miro

--
I refuse to use .sig