MUD-Dev
mailing list archive
[ Other Periods
| Other mailing lists
| Search
]
Date:
[ Previous
| Next
]
Thread:
[ Previous
| Next
]
Index:
[ Author
| Date
| Thread
]
Re: [MUD-Dev] 3D engines for MUDs (was: The MLI Project)
Miroslav Silovic wrote:
>
> Michael Hohensee <michael#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.
>
Heh, only if you want the highest quality in your image. I'm talking
about images which take 4-10 seconds to display. Every .pov file that I
ever saw could be traced in under 10 seconds if you wanted a little
80x80 (or thereabouts) image.
> > 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>
Heh, ok, I'll look it over. :)
--
Michael Hohensee michael#mainstream,net
http://www.geocities.com/SiliconValley/Heights/9025/
Finger me for my PGP Public Key, or use:
http://sparta.mainstream.net/michael/pgpkey.txt
- Thread context:
- Re: [MUD-Dev] 3D engines for MUDs (was: The MLI Project), (continued)
- Re: [MUD-Dev] 3D engines for MUDs (was: The MLI Project),
Michael Hohensee michael#mainstream,net, Thu 19 Mar 1998, 23:30 GMT
- Re: [MUD-Dev] 3D engines for MUDs (was: The MLI Project),
Michael Hohensee michael#sparta,mainstream.net, Thu 19 Mar 1998, 23:42 GMT
- Re: [MUD-Dev] 3D engines for MUDs (was: The MLI Project),
Miroslav Silovic silovic#zesoi,fer.hr, Fri 20 Mar 1998, 09:01 GMT
- 3D engines for MUDs,
Niklas Elmqvist d97elm#dtek,chalmers.se, Fri 20 Mar 1998, 11:30 GMT
- Re: [MUD-Dev] 3D engines for MUDs (was: The MLI Project),
Michael Hohensee michael#mainstream,net, Fri 20 Mar 1998, 13:26 GMT
- Re: [MUD-Dev] 3D engines for MUDs (was: The MLI Project),
Michael Hohensee michael#mainstream,net, Fri 20 Mar 1998, 21:15 GMT
- Re: [MUD-Dev] 3D engines for MUDs (was: The MLI Project),
Michael Hohensee michael#sparta,mainstream.net, Fri 20 Mar 1998, 21:47 GMT
- Position sorting,
Adam Wiggins nightfall#user1,inficad.com, Sun 22 Feb 1998, 13:17 GMT
[ Other Periods
| Other mailing lists
| Search
]