Re: [Algorithms] Terrain performance comparisons

[Lucas A. <ack...@ll...>]

Jonathan Blow wrote:

>LUCAS Ackerman wrote:
>
>  
>
>>LOD is not about quantity, it's about quality.
>>    
>>
>
>Scene quality is not just about number of triangles.  
>
I'm pretty sure I just said that, but yeah.

>As Thatcher
>mentioned, shaders are very important for the user experience.
>An LOD algorithm that's truly about quality will care a lot about
>shaders, and will provide some answer regarding how to combine 
>shaders in the distance (so we can render efficiently), without
>popping.  
>  
>

Shaders are another problem, but I agree that it's another requirement 
dimension that will impact the relative usefulness of different 
approaches.  It's an open problem for future LOD schemes to address. 
 Also touching on this is the lack of base-mesh or arbitrary topology 
simplification for extreme views.

This also kind of ties in with the observation that triangles aren't a 
perfect graphics primitive.

>
>About the quantity issue...
>
>  
>
>>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.
>>    
>>
>
>I must confess I still don't understand the point you're trying to make here.
>"Quantity", when it comes to triangle meshes, is all about achieving
>quality.  Right?  The whole point I want to render 100 million triangles
>per second is so that the scene looks better than it does at 1 million.
>  
>

Okay, I'll try again.  Lets look at it this way: higher quantity allows 
higher quality, but you don't get to pick the quantity!  It's an 
independant variable.  There's just so many triangles/sec a given 
hardware configuration can push, period.  The quality knob is the one 
you can turn.

>Yes, intelligently allocating those triangles is a good idea.  But it's not
>like we live in a world where the only choices are CLOD or NO LOD.
>We have VIPM, we have static meshes.  We have other stuff like
>geomipmapping.  All of these things do the task of intelligently
>allocating triangles; they just have differing costs and benefits.  When
>putting together a game, you want the most benefit at the least cost.
>  
>

I'd like to suggest that there are benefit/cost peaks that aren't being 
explored because they don't fit in the traditional view of what game 
engines can support.

>None of my comments, by the way, applies to ROAM 2, since I know 
>nothing about ROAM 2.  From what Mark has mentioned, it's chunking 
>and it handles arbitrary 3D topologies, which makes it different enough
>from ROAM 1 that no assumptions really carry across.
>  
>

Erm, just to be clear, Mark's PVA hierarchies stuff is not part of ROAM 
2.  It works on a 3d analogy to ROAM, with a tetrahedron-based volume 
hierarchy, and topology-independant VIPM per-node.  It still falls in 
the ROAM family of algorithms, as the optimizing principles and such are 
the same, but the (non-surface-oriented) problem domain necessitates 
totally different data structures and so forth.

FWIW, what we call ROAM implimentaions apply to surface hierarchies 
(ROAM 2 included - though it can do other things within chunks).

There isn't a real 2.0 paper yet, but Mark's ROAM 2 info page is here:
http://www.cognigraph.com/ROAM_homepage/ROAM2/

>Lucas wrote:
>
>  
>
>>IMHO, the big win for CLOD is scalability
>>    
>>
>
>and Adam Paul Coates wrote:
>
>  
>
>>even better, a nice CLOD algorithm can scale
>>with hardware -- fast users get lots of detail, slow users still get good
>>detail, but can trade it for visibility. 
>>    
>>
>
>Yes, CLOD can scale, but it is not necessary for scaling.  VIPM
>scales (you adjust the sliders to a different point!)  Static mesh 
>algorithms scale (you just pick higher-res static meshes!)
>
>   -Jonathan.
>  
>

Again, I think we really have different requirements in mind.  Scaling 
with hardware is one thing, adapting to arbitrary scales of view is 
another, and demanding continuity across scales is yet another.  Terrain 
being the (effectively solved) special case doesn't help either, as it 
becomes the ubiquitous "me too" result.

I do have an example that I can't yet support (since it's not ready for 
public consumption), which is the visibility algorithm we're working on. 
 It really lives and dies by the connectivity and per-element 
adaptivity.  The result is that it works great for multires geometry, 
being very adaptive and robust, but also fundamentally requires it.

-Lucas