Re: [Algorithms] Terrain performance comparrisons

[Trent P. <tr...@po...>]

I worked a lot with Mark D. on developing a "teaching" version of ROAM 2.0
during the time I spent writing the book last year. As complex as ROAM 2.0
can be to implement, the results are more than worthwhile. A simple
unoptimized demo was able to display such detail in a seemingly
randomly-generated mesh, that it had my jaw on the floor. Having a terrain
engine that can push an incredible amount of triangles per second doesn't
mean shit unless those triangles are being placed in such a way that they
actually DO add visible quality to the end-render of a terrain mesh. When
you say CLOD may be "useless" due to the amazing amount of triangles a card
can push per second, just think about WHERE a CLOD engine puts all those
triangles. I can show you a nice flat quad that consists of millions of
triangles, but does that mean the visual quality of the quad changes? No.

Basically, I'm backing up what Lucas stated. "LOD [or CLOD] is not about
quantity, it's about quality." Your average CLOD terrain algorithm does a
nice job of making sure that triangles that aren't being seen, aren't
wasting any CPU/GPU power. However, your best CLOD algos make sure that if a
triangle isn't being seen (or isn't adding any amount of visual quality to
something that is being seen), then that triangle can be placed on that hill
the player is ascending, or that mountain-range to-be ascended. That is why
CLOD was used in the past, and is still useful today.

That said, sometimes an uber-kickass CLOD algorithm just is NOT needed for
some games. As Charles mentioned, Asheron's Call 2 could have a much better
terrain engine, but it's still playable, and pretty, in its current form, so
I don't much care that they decided to put their resources to work
elsewhere. Terrain is purely a case-dependant thing. Games like TreadMarks
need the best terrain algorithm the programmer can code up. Games like
Asheron's Call, while based around terrain, don't need an incredibly
realistic engine; just something good enough to get the job done.
---
Trent Polack
tr...@po...
www.polycat.net
----- Original Message ----- 
From: "Lucas Ackerman" <ack...@ll...>
To: <gda...@li...>
Sent: Tuesday, July 29, 2003 5:25 PM
Subject: Re: [Algorithms] Terrain performance comparrisons


> Jonathan Blow wrote:
>
> >Let's look at this in a slightly different way: most graphics LOD
algorithms
> >are focused on decreasing the number of triangles/sec needed to display
> >the scene.  But triangles/sec is the single most abundant,
> >uncontended-for resource in all of game development.  So WTF are
> >we putting all this energy there?
> >
> >
> >
> LOD is not about quantity, it's about quality.  Quantity can increase
> with hardware speed and software efficiency, but quality improves by
> increasing the intellignece with which you allocate your limited
> quantity.  If triangles/sec were the fundamental measure of game
> quality, LOD would be pointless.
>
> Decreasing the quantity of triangles required to display part of a scene
> without decreasing the quality is only half of the equation.  The other
> half is to increase the quantity used to display the parts of the scene
> that will contribute most to the quality.
>
> It is also possible, of course, to use the flexibility in quality as a
> means to put more stuff in a given scene, or to look at a scene in ways
> you couldn't before.
>
> The reason a lot of time and energy goes into LOD is that it's not an
> easy problem to solve all aspects of in a way that satisfies all people.
>
> -Lucas
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
>
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
>
>