🚀 go-pugleaf

Jonathan Blow <j...@bolt-action.com> wrote in article
<56rk4i$h...@scam.XCF.Berkeley.EDU>...
> Anyway, the lesson is: do your homework before you go shouting
> about something revolutionary and new that will change the world,
> because otherwise you'll find that it already exists (see the
> current thread about "A NEW SORTING ALGORITHM!!!" in c.g.algorithms.)

Hmmm, give him some slack though.  He didn't use all uppercase and he
didn't throw a lot of exclamation marks in.

> Also, you should tone down the rhetoric on your web page about
> what polygons can and cannot do.  I have seen many typical
> _Quake_ scenes that exceed your demo model in complexity, and
> yet run at 20fps on my Pentium 133.  Quake uses polygons.
> My game, _Standoff_, does outdoor scenes of equivalent complexity,
> and it also runs at a resonable frame rate (though it's not quite
> done yet, so feel free to take that with a grain of epsom).  It
> also uses polygons.

Again, basically true, but I can also envision things that his engine could
do that the Quake engine would completely balk at doing, such as a nicely
contoured cave wall.  I'm not entering into a debate about polygons vs.
voxels here, but there are limitations to both.  For example, you'll notice
his dataset was over 4 megabytes in size.  ;)  I'm not an expert on voxels
or anything, but I'm assuming the slowdown when his engine displayed the
sky or ground was do to the penalty involved in having no intersection with
a voxel.  In an occluded environment I actually think it would be pretty
fast.  Granted, at this point I pretty much assume anything I do has
already been done by someone, but it is interesting just to see works by
other people who have taken vastly different approaches, even if they have
been done before in other forms.
     In short, it may not be entirely new, but I liked it.  Keep
experimenting!
-- 
sba...@mail.sonyinteractive.com
Shawn L. Baird (Scarrow)